I'm currently taking a class for database design, and we're using the ER diagram style designed by Peter Chen. I have a couple of problems with this style:

  • Keys in relationships don't seem realistic. In practice, synthetic keys like "orderid" seem to be used in almost all tables, including association tables, but the Chen style diagrams heavily favor (table1key, table2key) compound keys.
  • There is no notation for datatype.
  • The diamond shape for associations is horrible, and produces a cluttered diagram.

In general, it just seems hard to capture some relationships with the Chen system.

What ERD style, if any, do you use? What has been the most popular in your workplaces? What tools have you used, or do you use, to create these diagrams?


I'm not sure of the names of the diagrams, but generally know what you're talking about.

At the Tech School I first went to and the CIS dept of the University in the business school (where I took one DB class) we used crows foot notation, which makes a lot more sense to me.

In the CS dept, I was taught by a very experienced DB prof who used the diamonds for his ER diagrams - but he didn't care if we used some other notation for our assignments (we didn't do a lot of diagramming in that class, not nearly as much as in the CIS class at least)

In practice, having a number next to the diamond is well and good, but totally pointless. What you prefer probably comes down to who first taught you. I'd reckon if you say ES Queue Ell you probably use crows foot ER diagrams. If you say Sequel, you probably use the diamonds. And if you just call it a database, you probably don't use diagrams.

Also, datatypes aren't supposed to be captured at this level of database design. In my CIS classes at least, once we got to that point, we'd write the table structure out in a text file. Then it's just 2 steps away from an SQL create statement.

MS Visio can turn your diagrams into databases (and vice versa) so that method of diagramming ought to capture the info you want, although I've found it to be fairly cumbersome to use and I much prefer to just use Dia.

  • "I'd reckon if you say ES Queue Ell you probably use crows foot ER diagrams. If you say Sequel, you probably use the diamonds." based on what justification? Just curious where this statement derived. – Chris Feb 3 '11 at 14:56
  • "Sequel" was the original name, so older DB folks tend to use "the diamonds," i.e. Chen's diagrams, which are older. "SQL" is generally how younger people pronounce it, and they use a newer style of diagram. – asthasr Feb 3 '11 at 14:58
  • @Chris, that portion of the statement is pure speculation, but it seems like the older crowd is more likely to say Sequel and use hokey diagrams. – Peter Turner Feb 3 '11 at 15:10
  • No problem with speculation, I thought that was the case... curious where it derived from which syrion seemed to clarify. Thanks! – Chris Feb 3 '11 at 15:18
  • I've used Crow's Feet, but liked UML notation better (ERD on Wiki). Also, if it helps, look at class diagrams too. – KM. Feb 3 '11 at 16:05

I'm an "oldie" (started using "ess-queue-ell" before the '89 standard) and I use the crows-foot notation. However, using natural (multi-part) keys is a design decision, it's not dictated by the notation (maybe your prof is mixing "notation" with "process" in class?).

Is your class discussing the difference between logical and physical DB designs? Logical designs are aimed at capturing the domain at a high level, while physical designs model the structure of the actual database (including data types and constraints). Logical databases are rarely normalized beyond 3NF, while physical ERDs are normalized until you get the performance right ;).

  • 2
    +1 When I finally decided to bone up on data modeling, the difference between the logical and physical models was the single most important thing I learned. Without the distinction, you design in terms of tables and skip much of the important thinking. – grossvogel Feb 3 '11 at 17:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.