Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm taking a Database course and I'm a bit confused with the different types of graphical representations terminology of a database design. Are Data Model, Crows Foot Notation, Crows Foot Model, ERD & ERM all the same. Where do they differ?

My understanding is as follows:

-Crows Foot Notation - Graphically illustrate the relationship (ex. zero or many, one or many, one and only one, zero or one)between two or more entities.
-Crows Foot Model - Is this the same as Crow's Foot Notation?
-ERD - Illustrate each entities name, attributes and keys. Do I need to display the dataypes as well? Does this also consist of the Crows Foot notation?
-ERM - Is this the same as ERD.
-Data Model - I assume this is very general. Would this consist of an illustration of the entities and its name and arrows pointing to the entities it relates to?

share|improve this question

There are basically just two things here:

  1. Your data model, which is the structure of your entities, attributes and relationships.

  2. The graphical representation of your data model.

Your data model may be high level (entities/relationships only) or lower level (add in attributes with details of data types) and it may be logical or physical. It all depends on what stage of your design process you're at. The point of a data model is to record your database design, which is just an expression of your business requirements for persisting data.

Crows foot and ERD etc. are just graphical conventions for showing your data model pictorially. The great thing about standards is that there's so many to choose from, and this is also true of graphical conventions. Read this wiki article for a sampling.

Which conventions you choose may depend on what you need to communicate about your model, or it might just depend on what conventions make sense to you.

Don't get too wound up about all the different terminology. It's all just your database design and how you choose to record and communicate it.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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