Logical Data Structure Diagram notation

Entities

What is an entity? It's the posh word for 'thing'. Of course, there's more to it than that in its meaning on an LDS (aka ER - Entity / Relationship - Diagram).

Here goes... an entity is a thing in which the business is interested and forms a logical grouping of characteristics (i.e. data items or attributes) that describe the nature of the thing. This is still very woolly, but that's what happens when you're trying to give a generic description.

Some examples should help:

See how the data items logically group and the group is the entity? It's kind of a circular reference, I know, but there you go...

Note:If you come across the term 'entity occurrence', don't get confused between it and an entity. Think of an entity as a template, with each different type of entity having its own specific template. An occurrence is a template filled in with specific values.

1 to Many (1:M) Relationships

The LDS is constructed by diagramming the entities and the direct relationships between them. For example, a customer places orders.

When drawing a relationship line, the "crow's foot" is placed at the "many" end. As a by the way, the entity at the "one" end is often called the "master" and the entity at the "many" end, the "detail". So you'll come across terms like "master / detail" relationship.

At each end of the relationship line, you write a brief description of the relationship. The description at the "one" end always follows the pattern "each {master entity name} may {verb clause} zero, one or more {detail entity name}. If a detail cannot exist with a master, then "may" becomes "must" and the "zero" is excluded. Examples:

"Each Customer may place zero, one or more Sales Orders". If you can't become a customer unless you place your first order, it will be "each Customer must place one or more Sales Orders".

Then you do the same from the detail end of the relationship: "each {detail entity name} must {verb clause} by one and only one {master entity name}". Examples:

"Each Sales Order must come from one and only one Customer". Sometimes a detail doesn't have to have a master. When this happens, the relationship phrase becomes "each {detail entity name} may {verb clause} by one and only one {master entity name}.

When drawing an LDS, always place the masters above the details. This means that your diagrams will have structure and then they'll be much easier to read.

Another way of putting this is "no dead crows"! In complex LDSs you may need to go against this but do your best not to. Remember, a diagram is to communicate and visual clues will make things much easier.

Many to Many (M:M) Relationships

Unless you are drawing a very high level LDS, it's best not to include M:M relationships. They can hide dragons and in doing the analysis to resolve them, you'll end up with a more robust model.

For example, the resolution to the M:M relationship between Product and Sales Order is shown. This M:M is "each product may be sold on many sales orders", and "each sales order may record the sale of many products". As you can see, there is an obvious entity that resolves this, the Sales Order Line. Each sales order line records how many of a particular type of product are sold on that order.

One final note, some LDS notations allow for additional symbols on the relationship line at both the one and the many ends to indicate optionality / number.

More specifically, these additions are used to distinguish between "zero, one or more" or "one or more" at the many end, and "zero or one" or just "one" at the one end.