# How do I read ERD Notation (crow's feet) to convert to Natural Language?

Background

I am attempting to insure I understand how to read ERD (Entity Relationship Diagram) notation so I can convert it to a natural language explanation.

I'm trying to insure I can explain a method of converting what I see in the diagram to natural language.

Let's use the following diagram: (Please don't get too caught up on the correctness of the actual entities, they are just for our example.)

Natural Language Sentence Examples

Would this be a correct way of talking about the relationship from Company to Address.

A company has 1 to many addresses. (shipping, billing, etc).

This indicates that the company must have at least one address, right?

Does that match the notation I have in the diagram?

Company to Connection

Each company has zero to many Connections.

Is that correct? Is that how I read that double-bar on the Company side?

How Are the Two Company-side Connectors Any Different?

Do the two company-side connectors indicate anything different at all?
Can you explain that?

General Help For Natural Language Translation?

Do you have a logical method with steps you could provide for examining each relationship and converting to natural language?

For example, with Company to Connection.

1. Where do I start reading?

2. How do I remember (or explain) that the crows foot on Connection indicates the number of Connections a Company has and not vice versa?

Thanks

• Side-note. If the goal is natural language sentences it should perhaps be something like `A company has 1 or more addresses` Commented Jun 22, 2018 at 11:16

I'd like to answer this more definitively now using the following image (from https://www.lucidchart.com/pages/ER-diagram-symbols-and-meaning)

Using the definitions of these symbols you can see that the following things are true about my originally posted diagram.

• A company has 1 to many addresses. (shipping, billing, etc).
• A company has 0 to many connections
• A connection has one (and only one) company
• An address has one company - this should probably contain the double line connector to show that it is one and only one.

My final question was:

Do you have a logical method with steps you could provide for examining each relationship and converting to natural language?

1. Place a finger on the entity you are starting with. For example, place a finger on Company.
2. Now say, "Company has..." and choose the related entity you want to talk about. For example, choose connection.
3. Look at the relation symbol that touches the Connection entity (it is the empty circle with three lines (legs)) which indicates zero to many.
4. Continue saying "...zero to many connections".

The final sentence would be,

"Company has zero to many Connections."

That is how you transform symbols on Entity Relationship Diagrams into natural language.

• Please also consider: [1] Relationships (in an ERD) should work BOTH ways (if they don't, one may end up modelling redundant relationships). E.g. looking at your original diagram: Company -< Connection, also consider that each Connection MAY (not 'must') be associated with a company, i.e. a connection can exist without a company. Is this a valid business rule (in the scenario)? [2] Whenever possible, use a verb that is more descriptive than "has". E.g. Company -< Product: it makes a difference whether you say "delivers" or "manufactures", as it tells you what the company (actually) does. Commented Jun 2, 2017 at 6:55
• Actually, on the company to connection thing you may be reading it backwards. The original diagram actually indicates that the company has 0 to many connections but a connection has one (and only one) company -- that's the two dashed line on the company side. Only if the company side of the diagram would have had the zero or one symbol would what you said be true. Commented Jun 1, 2018 at 12:04

From this link: archive.org mirror (original url is broken) 1

Cardinality and Modality are the indicators of the business rules around a relationship. Cardinality refers to the maximum number of times an instance in one entity can be associated with instances in the related entity. Modality refers to the minimum number of times an instance in one entity can be associated with an instance in the related entity. Cardinality can be 1 or Many and the symbol is placed on the outside ends of the relationship line, closest to the entity, Modality can be 1 or 0 and the symbol is placed on the inside, next to the cardinality symbol. For a cardinality of 1 a straight line is drawn. For a cardinality of Many a foot with three toes is drawn. For a modality of 1 a straight line is drawn. For a modality of 0 a circle is drawn. zero or more [b4] 1 or more [b5] 1 and only 1 (exactly 1) [b6] zero or 1 [b7] Cardinality and modality are indicated at both ends of the relationship line. Once this has been done, the relationships are read as being 1 to 1 (1:1), 1 to many (1:M), or many to many (M:M).

[1] Original link:`http://web.simmons.edu/~benoit/lis458/CrowsFootNotation.pdf`

To properly explain any modeling notation you need to understand it. There are many resources out there - here's one relevant site to get you started. It's far too widely documented and expansive a topic to cover in a stack exchange answer. If you're looking to write truly technical explanations of each relationship, the model documentation will easily get you there.

Do you have a logical method with steps you could provide for examining each relationship and converting to natural language?

As with any writing your audience should drive your writing focus and style. Are you writing a technical document? If so, who specifically for? Most database professionals will just go to the diagram. If you're writing for business users then focus on their process and let that guide your structure and word choice. For example, if the model describes how to record a company's address the most familiar place to start with is the company. Colloquially we discuss a company's address, not an address's company.

Start by explaining that: `"A company has at least one, and possibly many, addresses."`
You will have to loop back to explain things that we typically don't think about in casual conversation. You can continue by explaining that `"We only store connection types that relate to a company (it's not a long list of arbitrary or potential connection types) and each connection type has only one company."`
A lot of professionals will go through this kind of exercise as a test to see if their model makes sense. What they may start asking is: `"Does a company have a connection type, or does it make more sense that a company's relationship with it's multiple addresses have connection types?"` Which should lead them to re-structure with a lookup table and a description such as: `"A company has one or more addresses of different types."`