What is a <fill in the blank> model?

[agredell]

The original topic is locked, but I REALLY wanted to comment!

Our biggest hurdle in any modeling endeavor, IMHO, is Language and Definition of Terms. What YOU call DATA MODEL sounds like LOGICAL MODEL according to the terms that I use; and others probably use something else.

Has some "expert" created definitions that might be acceptable to all?

The list I've found the most useful in general is (from Bill Smith, http://www.williamgsmith.com/index.html):

CONCEPTUAL: working with the business, define the Nouns that the business has an interest in, and wants to store information about. Define the relationships between the entities. Normalized and Generalized extensively to allow maximum flexibility and minimal coding of business rules where possible.

LOGICAL: Principally, the addition of individual data elements to the Conceptual model, along with full normalization of the model.

PHYSICAL: adding the storage constraints, index requirements, distribution, security requirements, and all other "things" that must be determined before actually creating and implementing the design.

Regardless of your opinion of these definitions, how can we ALL agree on such terminology? I will do it at my shop, but that won't help when I talk with other modelers or DBA's at other shops. I am getting pretty frustrated by this lack of agreement!!!

[alf-admin]

Agredell,

I tried to explain a little here:

http://www.databasedesign-resource.com/business-rules.html

As for your link, I tried to read it, but dark blue text on a black background isn't actually easy to read, nor is it a very user-friendly design. I hope his DBs are better designed than his website
_________________
All the best,
Alf
Forum Admin
Light travels faster than sound: That's why so many people appear bright until you hear them speak...
www.databasedesign-resource.com
The Database Normalization eBook

[Mel]

While I agree with the definitions provided for conceptual, logical and physical models, I disagree that a conceptual model should be referred to as a "conceptual database model", because a conceptual model is not a model of a database at all, it's a representation of how business data relates (or should relate) to other business data, and may (more often than not) vary considerably from an actual database implementation.

For a logical model I would say the same thing, since the definition of a logical model is basically a conceptual model with tables and references instead of entities and relationships (and maybe some normalisation, etc depending on what type of system you are designing for), but not tied to a particular database platform.

To that end, I guess you could call a "physical data model" a "physical database model", although I've always used to former and I'm still not 100% convinced on that one either.
_________________
Mel

[agredell]

Thanks for the replies, Alf and Mel.

I think I see where our differences in definitions lie. We use the same words (conceptual, logical, physical) in different phases of the development of a database. The big difference is the use (or exclusion) of the word "database" in the middle. At the Conceptual level, I don't really think that there's a substantial difference. From my viewpoint, the only significant difference is the inclusion of attributes at that level (I would exclude them). The Entities and the business rules (along with the relationships between the entities) should be agreed upon before proceeding to Logical modeling, which identifies and normalizes the attributes.

I tried your glossary, Alf, but you do not have any entries for Conceptual Database Model, nor the others.

I will also suggest a small modification to the definition of a Data Model:
"A data model is not necessarily the model (conceptual/logical/physical) of your future or existing database...". From my experience, the closer you can keep your conceptual model, and logical model, to the implemented database, the simpler time you will have forever changing any code, and will have to impelement fewer database changes. One of the statements Bill made as an instructor was something like "every action has consequences somewhere else"; so, as a DBA, if you introduce an index, you benefit read access at the cost of insert or update access. That's not a bad thing, mind you, but you have to examine the consequences and do it with your eyes wide open to the possibility of it costing more than it's worth. This probably applies more to denormalization than to any other topic in the database world.

BTW, Alf, Bill Smith's web page looks like turquoise on navy blue to me, still not the friendliest, but readable.

BTW2 Alf, great job on the forum; this kind of discourse is fun and profitable, keeps you thinking!!!

[alf-admin]

agredell,

Thanks for kind words, I only hope that many DB people join in,

I can see where you're all gettting at: I have just recently tried a new modeling tool (Open Source) and it illustrates perfectly the differences (unconsiously ): I'll be posting on the differencies tomorrow (give me some slack ). I believe it will be fun

And I agree with both you and Mel; it's important to understand the basics. Just remember: A data model is a generic concept for your database design; A database model (whatever stage) is your database-to-be, based on a certain data model (and as far as I know, there's only one complete data model ).

Final word, since you mentioned the forum: It was a bit of a task to get up this forum with the intention of being friendly and helpful; Now I just hope that many people will use it, without being focused on products, but rather on the real tasks, regardless of any product... And that implies being able to reason and think.

And I must add that I got some great people volunteering to moderate these forums in order to get them going: Can't tell, really, how thankful I am for that

As for thinking: One of my big slogans is THINK no matter what "authorities" are trying to tell (sell) you We are, believe it or not, being pushed by market forces, and it's saddening. Read this in order to understand how the market is undermining your thinking and reasoning:

http://www.databasedesign-resource.com/flat-relational-tables.html

Now, coming back to the THINK slogan: It was actually CEO Watson of IBM who thought it up in the 1940's. Having said that, he was also one of the guys predicting that Europe would need maximum 5-6 big computers, in order to cover all computing power needs for the years to come...

My PC is laughing.

[agredell]

(Did you ever see a big sign posted in a workplace with the following on it?

THIMK!
Just a little variation that was pretty humorous, I think back in the late '60's or early '70's...)

I think (there's that word again!) that a lot of miscommunication comes from a lack of empathy, that is, understanding what someone else's role in a given task or project is. That's why I want to make some ABSOLUTE definitions that all can agree on, whether one likes them 100% or not, if one can live with them, our efficiency will increase greatly due to a reductions in communications difficulty.

F'rinstance, at my shop, I'm doing (trying to do) the "abstract" data modeling for the shop, along with the DBA role (my long-time background) for our Data Mart / Data Warehouse environment. I must remember to name which hat I'm wearing when I make a comment like the one I did about the index. That example should not (as you rightly pointed out) be made anywhere in conceptual modeling, although the identification of a likely need for one certaintly can, such as users mentioning that they'd like to be able to search on something that's not the unique key. But the determination of whether it should or should not be implemented is pretty much strictly a physical requirement...as is denormalization...

I look forward to your comments on the modeling tool...have a great day!

[jracicot]

I have just one comment on the definitions. The conceptual model doesn't need to be normalized. Many to many relationships can exist and generally are truly representative of the realities of business.

[alf-admin]

jracicot,

Absolutely. That's the place where they belong. Later we will create junction entities.
_________________
All the best,
Alf
Forum Admin
Light travels faster than sound: That's why so many people appear bright until you hear them speak...
www.databasedesign-resource.com
The Database Normalization eBook

[rdoggy]

go back to the www.williamgsmith.com website, he describes data modeling best.