with regard to Database Modeling

[johnseito]

I think the hardest part of the database modeling process is creating the sample data that logically make sense.
At least that is from my experience, I think the schema, and ER diagram could easily be tweak but creating a sample data
that logically works for the relational database with all the tables involved is the most time consuming and most difficult of the
whole process.


Anyone agree?

And could you advise on how I can created a sample data that logically make sense in the relational database?

[orange]

see http://www.rogersaccesslibrary.com/T...lationship.zip

for some videos that may help
see this older post https://www.accessforums.net/forms/e...-35220.html#13

No, I don't agree with

the hardest part of the database modeling process is creating the sample data that logically make sense.

I think the difficult part is to clearly identify the business rules. Or, in different words, fully determining WHAT is involved/is being asked. Many of the requests for assistance on this and other forums seem to revolve around miscommunication. Often, people are trying to build forms or reports without ever having created a data model; have not heard of Normalization; have not designed tables... Their first question is typically an issue with Access syntax - with little or no description of their environment, their business or some context to help the reader with the question.

[johnseito]

Ok, thanks for the links and videos, so much stuff to read and watch but is good. :-)

I think the difficult part is to clearly identify the business rules. Or, in different words, fully determining WHAT is involved/is being asked.

Ok you may be right about that, but I think that because of not really knowing what is being asked for, and business rule, it makes it much harder to create
a sample data (also hard to design the database too) that make senses. From what I found is some schema and requirement are easier to understand
and for these creating the sample data is easier, the ones with the requirement that are more complex, creating the data sample for this is much harder because it has a
lot of attribute and entities that is hard to make sense of.

I also think that it would be easier to normalized the data if we already have sample data to work with instead of just having the business requirement, and attributes of the
business rules and requirement, and have to create our own entities, design and attributes and then thinking of the sample data for these entities and attributes that logically makes
sense for the business requirement/database.

[ssanfu]

I've found that most of the time, a database is created to replace a paper process. The paper process usually has a lot of extra items/steps that have developed over time and are not necessary now or that have been changed.

So we are back to the business rules orange talked about; business rules that are fundamental to creating a database, even if it is just for personal use.

Because most of the dBs are based on or replacing a paper process, won't you have ready made sample data from historical data?

And with the business rules written down, you can try and control project creep. (I did say TRY).

[johnseito]

Because most of the dBs are based on or replacing a paper process, won't you have ready made sample data from historical data?

In most cases this is true.

But when you just have ideas, or when a business is in it's initial start up phase, it doesn't have any data or accurate data to back up it's idea
and you would have to created your own data by visualizing it and making it up.

So you are only require to model a database by hypothetical means and this would be harder, at least that is what I think.