Company logo of Crocus Information LtdCrocus Information Ltd

Business Requirements Analysis consultancy to blue chip companies

Requirements Analysis and Specification: logical data structure diagramming notation

Logical Data Structure example showing the notation

diagramming notation slide map | dataflow diagramming notation

Logical Data Structure with examples

The partial LDS above is taken from the Acme Fashion feasibility study and will serve as reference in describing the notation.

Entities

entity symbolWhat 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:

Entity Some data items
Customer
  • Name
  • Address
  • Credit Limit
Product
  • Product Code
  • Short Name
  • Full Name
  • Normal Supplier Code
  • Alternative 1 Supplier Code
  • Min Stock Holding Level
Sales Order
  • Sales Order Reference
  • CustomerCode
  • Date order raised
  • Raised by
  • Order discount given

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

relationship symbolThe 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 without 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 visual structure and then they'll be much easier to read.

dead crow alert!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

many to many resolvedUnless 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.

Entity Some data items
Sales Order Line
  • Product Code
  • Sales Order Reference
  • Qty Ordered
  • Product discount given

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.

Go to Top

Related

In action and in theory

You might like to look at the Acme Fashion Supplies case study that these examples were taken from or the Requirements Analysis and Specification briefing study where they're described.

Test Yourself

When you've worked through the materials, you can see how well you've got on by testing yourself with these: