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

Question

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

Company to Address

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

Answer 1

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.

Answer 2

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

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

Answer 3

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.

As for your process questions:

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.

Where do I start reading?

If you're following the process/colloquial suggestion, start with company and logically explore its relationships. In the example there are two meaningful tables that are related to, and further describe, a 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."

This describes the relationships and what our data rules are. It also doesn't seem to make much sense, so were this not an example schema, I'd suggest someone either take a look at the design, or think real hard about their business processes! This is one of the reasons that you will find additional information related to language-to-model conversion and thinking in ERD documentation.

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."