Académique Documents
Professionnel Documents
Culture Documents
The LDM
In SSADM the vehicle for analysing the logical structure
of an organisations information is the Logical Data Model
(LDM).
A Logical Data Model is a way of graphically representing
what that information is really all about, how it relates to
other information and business concepts, and how
business rules are applied to its use in the system.
The LDM is possibly the most important and ultimately
the most rigorous product of an entire SSADM project.
Logical Data Models consist of two parts:
a diagram called the Logical Data Structure (LDS);
a set of associated textual descriptions that explain each part of
the diagram.
Entities
Any object or concept about which a system needs to
hold information is known as an Entity Type (or entity for
short).
To be a valid entity we must wish to hold information on
more than one occurrence of it. Entity occurrences are
real world instances of an entity type.
For example the entity type Supplier will have
occurrences such as:
Supplier No
3621
2327
Supplier Name
Bella Sonic
Supplier Address
Entities (continued)
The symbol for an entity in an LDS is a round cornered
rectangle containing the entitys name (which must be
unique):
Supplier
unique name
Attributes
Each item of information (or data) that we hold
about an entity is known as an attribute or data
item.
Examples of attributes for Supplier might be
supplier number, supplier name, supplier address,
and supplier telephone no.
The detail of an entitys attributes is not formally
included on the LDS itself. This is held in separate
textual descriptions, which will be discussed later.
Relationships
Entities do not exist in isolation, but are related to other
entities.
In physical data structures these relationships are
signified by physical links such as pointers or placement
in the same file or document.
In logical models relationships represent business
associations or rules and not physical links.
Any entities that are related are linked by a line on the
LDS.
The line is labelled with the name of the relationship, and
is named in both directions.
supplier for
Supplier
?
placed with
Purchase
Order
Degree
The number of occurrences of each entity type participating in a
given relationship is denoted by the degree or cardinality of that
relationship, and illustrated on the LDS by adding crows feet to the
relationships line.
A
m:n
1:m
1:1
Optionality
Each relationship is further annotated to show if it must
exist for all occurrences of the participating entity types.
If there can be occurrences of one entity that are not
related to at least one occurrence of the other, then the
relationship is said to be optional for that entity.
The relationship line is then converted to a dashed line at
its optional end (which could mean both ends if both
entities are optional participants).
Supplier
supplier for
placed with
Purchase
Order
Identifying Entities
To identify entities in the current environment we can
begin by looking at our physical data stores to find out
exactly what it is that they hold information about.
If we take the customer order file and discuss it with
users, we find that it not only contains details of each
individual order, but of the customers themselves,
i.e. customer address, customer telephone number etc., and so
encompasses at least two entities, namely Customer and
Customer Order.
Supplier
Purchase Order
Customer
Product
Stock
Customer Order
Verification
Once the list has been drawn up we should verify it with
key users during preliminary scoping interviews.
The key questions to ask of each entity are:
Are any of the candidates merely attributes of another entity?
Do any of the candidates represent a subset of occurrences of
another entity?
Do all of the entities have a unique identifier?
Adding Relationships
We now examine each entity to see if it is directly related,
in a way that is of interest to the system, to any of the
other entities.
The best way to do this is in discussion with users, either
taking each entity in turn, or starting with a key entity and
moving around the LDS network as the relationships
are identified.
Having identified where we think relationships exist, we
now consider their degree, optionality and names.
We do this by identifying the business rules that apply to
each entity pairing.
The basic process is the same for all pairings, so we will
look at just one example.
Stock - Delivery
We first consider the relationship from the
Stock perspective:
Each Stock occurrence will consist of a quantity of a
single product, all of which was delivered on the
same delivery.
If within the depot we have a quantity of a given
product, some of which was delivered in one delivery
and some in another, then we will have more than
one Stock.
This is an example of one of ZigZags business rules,
and one that will continue in the new system.
Delivery
Stock
Delivery
Stock
Delivery
delivery
of
delivered
by
Stock
Overview LDS
Supplier
supplier
for
supplier of
Despatch
despatch
of
Delivered
by
placed
with
Purchase
Order
ordered
by
despatched
in
supplied by
ordered by
Product
customer
order for
order for
results in
held as
holding of
result of
delivered by
Delivery
Stock
delivery of
Customer
orderer of
ordered by
Customer
Order
Drilling Down.
The overview LDS provides us with a good basis for
building a more complete model of current data.
We begin the process of creating a detailed model by
looking at this model and discussing it with users to
check our understanding of the scope of current data and
to uncover lower level entities which can be added
immediately.
Product
Type
Product
Depot
Zone
Supplier
Invoice
Delivery
Master
Detail
Supplier
Product
Stock
Keys
We should be able to select at least one identifier for each
entity type,
i.e. an attribute that enables each occurrence of an entity to be
uniquely identified,
e.g. for Customer we could use customer number.
Foreign Keys
If we have a relationship between two entities we need to
be able to associate the occurrences at one end with the
related occurrences at the other.
In a relational model (such as the LDM) we do this by
including the primary key of the master in the set of
attributes of the detail.
The copy of the masters primary key in the detail entity is
known as a foreign key.
Key Navigation
Supplier attributes:
Supplier No. (Primary Key), e.g 271
Supplier Address etc.
Supplier
supplier for
placed with
Purchase
Order
Notation
Supplier:
Delivery Address:
2327
Depot 1
Bella Sonic
Harrow Way
Harrow
Unit 5
HA4 3NB
4/3/01
NE3 7AJ
Qty
Your
Product
Ref
Our
Produc
t
Description
Format
Unit
Price
Ref
100
BJB001
884690
CD
6.99
500
3485VHS/3
993201
BV
0.53
If we look at a sample
purchase order of
ZigZag, we will
discover that details
of quantities and
products are held in
individual purchase
order lines.
Purchase
Order
Product
contains
ordered by
order for
contained in
Purchase
Order
Item
Link Entities
Link Entities
To make these associations we would have to set up lists
of foreign keys in both entities, of arbitrary length.
Significant maintenance overhead
Navigation around the model very difficult
Against the rules of relational data modelling
Pigs Ear
substitute for
Product
sub with
substituted by
sub by
Product
Substitute
Product
sub of
sub for
Purchase
Order
Invoice
Item
Purchase
Order
Item
Supplier
Invoice
Purchase
Order
Purchase
Order
Item
Purchase
Order
Purchase
Order
Item
Purchase
Order
Supplier
Invoice
Purchase
Order
Item
Customer
Customer
Order
Customer
Order
Item
Is this
relationship
Redundant?
Purchase
Order
Is this
relationship
Redundant?
Supplier
Invoice
Purchase
Order
Item
Product
Type
Supplier
Depot
Zone
Depot Zone
Allocation
Product
Substitute
Product
Purchase
Order
Despatch
Supplier
Invoice
Customer
Order
Purchase
Order
Item
Customer
Order
Item
Stock
Customer
PURCHASE ORDER
Purchase Order Number
*Supplier Number
Suppliers Delivery Reference
Purchase Order Date
Purchase Order Status
Delivery Date
Delivery Start Time
Delivery End Time
SUPPLIER
Supplier Number
Supplier Name
Supplier Address
Supplier Tel. No.
Supplier Contact Name
SUPPLIER INVOICE
*Purchase Order Number
Suppliers Invoice Number
Invoice Date
STOCK
Stock Id
*Purchase Order Number
*Product Number
*Zone Code
Quantity Stocked
Quantity Stocked
Quantity Reserved
DEPOT ZONE ALLOCATION
*Depot Zone Number
*Product Type Code
Purchase Order
Description
Attribute
Primary
Key
Yes
Foreign
Key
Mandatory/
Optional
M
Supplier Number
Yes
Delivery Date
must/may be
either
Link Phrase
/or
Entity Name
/one or more
must be
placed with
Supplier
may
result in
one or more
Supplier
Invoice
must
contain
one or more
P.O. Item
Entity Volumes:
Max.
15000
Min.
6000
Average
10000
User
Access
P.O. Clerk
Despatch Scheduler
Read
Purchaser
Read, Create
Small Projects
Entity Name
Short Description or
Comments (optional)
Min
Volume
Max
Volume
Ave
Volume
Growth
Rate
Supplier
Product
Depot Zone
400
10000
26
750
100000
40
500
25000
32
5%
25%
20%
1500
90000
16000
420000
10000
200000
15%
25%
Purchase Order
Purchase Order
Item
Attribute Name
Short Description or
Comments (optional)
Domain
Length
Purchase Order
Number
Purchase Order
Date
Purchase Order
Status
Automatically
generated by system
Date order placed
Integer
DDMMYYYY
P(Provisional) V(Placed)
C(Confirmed) D(Delivered)
Entity Description Table and Data Catalogue Table for Small Projects
Product
Type
Product
Depot Zone
Allocation
Depot Zone
Product Type
Supplier
Depot Zone
Allocation
Product
Substitute
Product
Purchase Order
Customer
Despatch
Supplier
Invoice
Customer Order
Purchase
Order
Item
Customer
Order
Item
Stock