Entity-relationship diagrams are a useful tool for designing databases. They show the entities involved, their attributes, and the relationships between them. You need to define these elements to properly understand the structure of the database before building it.
A method often used to create an entity-relationship diagram is crow’s foot notation. Introduced in the 1970s, the distinctive arrows used in crow’s foot notation have also been called inverted arrows, chicken feet, or just forks.
Crow’s foot notation uses some unique shapes and symbols to represent the elements in a database.
An entity is a real-world thing (person, place, object - whatever you can name in your database can be an entity) represented in crow’s foot notation by a rectangle with a name in a box on top. An entity is always singular.
Entities have attributes that describe them. These attributes get listed underneath the name in the rest of the rectangle. An entity can have one or lots of attributes. One of those attributes will be its key attribute, or identifier, which uniquely identifies that entity. The identifier is shown with an asterisk next to its name.
So our player entity is represented by a rectangle with the word player inside it.
The entities depicted in the diagram have relationships that describe how they interact. Relationships between entities are represented by a line with a verb written on the line.
Relationship lines in crow’s foot notation have two indicators to describe the cardinality and the modality of the relationship. Cardinality tells you the maximum number of times that an instance of an entity can be associated with instances of the other entity. Modality tells you the minimum number of times that the instance can be associated with instances of the other entity. Note that most of the time you can just use the word cardinality.
These indicators are shown on both ends of the relationship line so that you can see how the entities relate to each other.
You can see from this line just where the name “crow’s foot” came from...
Zero or many
A zero or many relationship means that it is optional. There might not be any connection between the entities, or there might be one or more.
One or many
The “one” indicates that this is not an optional relationship, although there might be more than one.
One and only one
No more than one relationship is possible between instances.
Zero or one
Another optional relationship, with a maximum of one.
Crow’s foot notation isn’t the only way to draw an entity-relationship diagram. An alternative and earlier approach, Chen notation, takes a different approach to represent entities and their relationships: entities are rectangles, their attributes are ovals and relationships are diamonds.
Chen notation uses symbols on the lines between relationships and entities to show cardinality:
Some critics of Chen notation argue that its diagrams take up more space than crow’s foot and that the symbols for relationships are less intuitive.
Let’s map out an online store to show how crow’s foot notation works. For our example, we’re going to simplify the store and only represent four entities: customer, order, product, and discount code.
You can see from the diagram that each entity has a number of attributes and that the unique identifier is marked with an asterisk.
Now let’s start mapping out the relationships. We can start with customer and order.
The relationship line shows that a customer can have zero or many orders, while an order can be associated with one and only one customer. The verb used for the relationship can be “places”, as in the customer places an order.
Moving on to product and order, a product can be associated with zero or many orders, while an order must have one or many products (you can’t have an order without ordering something!). For product and order, we can use the verb “is added to” to describe how a product is added to an order.
Next up is discount code. We want to encourage our customers to order products, so sometimes we’ll send out a seasonal discount code by email. We could send out specific codes tied to a specific customer, but for our example we’ll go with the same short alphanumerical code for everyone.
We don’t need to connect customer to discount code, because they just input the code when they order and it will update the total cost of the order. There doesn’t need to be a persistent relationship between customer and discount code.
Orders and discount codes have a zero or one relationship: a customer might not input a discount code, but if they do, they can only use one at a time. Going back down the line the other way, an order might not have any discount code associated with it, but if it does, it can only have one. A discount code is “applied to” an order.
A real entity-relationship diagram drawn using crow’s foot notation will be much more complex than our example. But you can see how crow’s foot notation makes it easy to see at a glance how the database will function. You can probably even start imagining the other parts of our online shop and how they might relate to each other.
Crow’s foot notation works best when you need to seriously start building your database. When you have to be very clear on how entities relate to each other, you will appreciate the level of detail encapsulated by the relationship lines in an entity-relationship diagram (ERD) created using crow’s foot notation. But when you’re just starting to develop your project, you can rely on simpler approaches to the ERD. The first step in communicating your ideas is to roughly sketch out the entities, attributes, and relationships. At that stage, it’s usually a good idea to work fast and not worry too much about the details.
Gleek doesn’t support crow’s foot notation, but we do enable you to create plenty of other diagrams. Our diagramming tools are for the developer who wants to rapidly create an informal ER diagram at the conceptual level or a quick context diagram to work out how your product relates to external entities. If you need to discuss your ideas in a meeting or collaborate on the early stages of designing a database, try Gleek’s keyboard-friendly approach to diagrams.