Data Modeling Notation

I want to learn more about the various DataModeling notations out there. Consider this a PromptingStatement.

Sam's Doc - 12/12/1994

IDEF1X is a data modeling language [http://www.idef.com/idef1x.html] that appears to be in common use. Notations as distinct from languages, then.

Other notations I've come across:

• Martin
• Finkelstein
• E-R-A
• Ross
• UnifiedModelingLanguage
• Entity-Relationship diagrams

Most graphical notations for databases are in the form of directed graphs with nodes rectangles and the ends of edges annotated with cardinality and reference information. Rectangles are named for the relations they represent. Rectangles contain lists of attributes, sometimes annotated with type. Edges signal cardinality in different ways depending on the notation, from crow's feet to explicit numbering. Many DataModel diagrams resemble UnifiedModelingLanguage class diagrams with methods elided.

A common text notation is a table with no outside borders and with the relation in the first row and attributes in columns of the second row. It is tricky to indicate integrity constraints between relations except as phrases in some constraint language.

Another textual notation is the data definition language of the DBMS you are using. This has the disadvantage that you are modeling the database in a physical realm instead of a logical one. It is usually better to design the logical database first, then move to the physical. If you start with the physical notation, you are tempted to skip the logical. Design decisions dealing with the problem domain tend to get confused with design decisions about the solution domain.

Graphical notations tend to make for better architectural presentations.

Can anyone help fill in the blanks and/or recommend?

---

I like a simple approach, as seen in CampusExample. The table name, column name, and comments. Types and lengths just clutter one's view most of the time. (The phrase "table:" is not really needed either.) Give the type only if it is not self-explanatory. A variation is simply tables that have column name, type, key notes (primary key, foreign key, etc.), and description. A spreadsheet can be used to make such. ER diagrams don't work well when there are too many columns or too many tables. And, they are hard to print if they don't fit on a regular sheet of paper. A simplified ER diagram that only shows keys and table descriptions can be helpful, but time-consuming to create. -- top