location: home->briefing studies->requirements analysis & specification

a crocus information Briefing Study - Page updated 12 Jan 2007

logical-data-modelling.jpg
logical data modelling
| bookmark | |
Index page [<< First] [< Previous] [Next >] [Last >>]
slide 14 of 25

Logical Data Modelling (LDM)

In principle, a logical data model consists of a diagram (a Logical Data Structure diagram or an Entity Relationship Diagram) showing business entities, and their inter-relationships, names of the relationships and the cardinality i.e. each customer can place one or more orders, an order can be placed by one and only one customer - these are the relationship descriptions when viewed from both ends. You can also read from them that the cardinality is one customer, many orders. You have a think about an Order-line entity and its relationship and cardinality with Order and Product.

(If you need to, see a description of the notation used in LDS diagrams here...)

In addition to the diagram, you will have each entity listed, with its unique identifying key and the business attributes that make it up. For example, one of my entities is Order, its unique identifying key is a combination of the customer's key and an order number. The Order entity has attributes such as Date-order-placed, Email-address to be used for delivery and a Notes attribute for any special instructions or notes from the customer appearing on an order.

You will also record the current and expected volumes against each entity and the expected growth rate. For example, you might get a rough average of five order lines on each order. Record that against the Order-line entity. Using the expected number of orders per period work out how many order lines per period that is and record that too.

Cross validation with other techniques

If you are following these Briefing Study slides in sequence, you should be able to see some immediate cross-validation checks with the DFM:

  • Do all the entities appear in datastores?
    If not, is a dataflow missing? Is an I/O Description missing something? If so, some aspect of a process has been missed, or indeed even a whole process.
  • Also remember to consider static or reference data.
    At this point it's quite common to notice that processes have been overlooked in the DFM to cover creation, modification and deletion.
  • If you have needed, because of the project landscape, to go to the lengths of describing all the attributes on each dataflow:
    • do all the identified business attributes on the LDM appear on at least one I/O Description?
    • If not, where do they come from?
  • And, vice-versa, are all business attributes on the I/O dataflows accounted for in the entities on the LDM?
Google
| bookmark | |
Index page [<< First] [< Previous] [Next >] [Last >>]
slide 14 of 25
bright-idea Related information from sponsors:

| Home | Privacy | Diagramming Notation Explained | Analysis Example Documents |
| Business Analysis CV | ACME Fashion Supplies Feasibility Study |