CIS106: Introduction to Computing (part B)

Maureen Korda,

10 Feb 2000

An information system should minimise redundancy

Week 4 and ensure the integrity of the data. We can use ER
modelling to help achieve this.
Normalization and
Entity-Relationship Diagrams Slide 2
Diagramming
Chen also introduced a diagramming technique
(ERD) which made the ER approach very popular
Why are diagrams so incredibly helpful in system
Lecture 2 design?
Entity Relationship Analysis
 Communication with the user/non-technical
people
Slide 1  `A diagram says 1000 words'
Introduction  More degrees of freedom than text
The Entity Relationship model is an information
model.  Easy to learn
Entity Relationship modelling is:  Easy to be informal
 a top down approach to system design Why might diagramming techniques be harmful?
 a technique for dening the information needs
of an organisation.
 a means for identifying
{ the things of importance (entities)
{ the properties of those things (attributes)
{ the way those things interact (relation-
ships).
It was introduced by Peter Chen [2]
Note
Top down - start at a high level (real world ap-
 Easy to be informal
Note
Perhaps the relational model does not provide a very
clear understanding of what the data really means.
The notion of extended or semantic modelling (as
in ER modelling) aims to more clearly convey the
meaning of the data.
The aim of the ER model is to capture real-world
data requirements in a simple and meaningful way
that is understandable by both the end user and the
database designer.
At the simple level of the ER model a diagramming
proach) and nish with a concrete database design.
Entity relationship modelling is often called Seman-
tic modelling. Semantics are meaning (what does
the information mean?).
The model aims to allow for simplicity and read-
ability. It is a model that is independent of stor-
age and access methods. It is primarily intended for
databases, but is also used more widely. It forms
technique is used to communicate with end users
about their data requirements. An ER diagram de-
scribes the entities, attributes and relationships that
occur in the system.
By using diagrams, some quite complex semantics
can be understood without resorting to lengthy nar-
rative explanations.
The diagrams can be used for database design and for
part of SSADM (Structured Systems Analysis De- design verication. The diagrammatic schema will
sign Methodology), CASE (Computer-aided Systems ultimately be transformed into normalised relations
Engineering) tools and many other techniques. (tables).

1
Requirements from a database may depend on the
user - this leads to the possibility of multiple views of
the data (each user may have a dierent view of the
data, according to what queries he makes). An ER
diagram for each view can be designed, then views
(ER diagrams) can be consolidated into a global view
(one big diagram).
Relationships between entities that are revealed us-
Entity Name
The name must represent a type or class of thing -
not an instance.
e.g. Given an entity Airport, the type is Airport and
an instance might be Heathrow, Stanstead, etc.
Entity Rules
 Any thing can only be represented by one entity.
ing the diagramming technique can be transformed  Entities must be uniquely identiable. i.e.
into tables, as can the associated entities. each instance of an entity must be distinctly
Functional Dependencies can be derived from the identiable from all other instances of that en-
diagrams. FD's are the dependencies that exist tity type.
amongst the keys of entities. FD's also exist between
key and non-key attributes within entities.
Once dependencies are identied, normalisation is
used to remove redundancies to the highest degree. Slide 7
Data integrity must be maintained (by specifying ac- Entity Summary
tions required for foreign keys). Entities have
The ER model is used in most CASE tools and
SSADM.  type (name)
 instances or occurrences
Slide 3  identity
Basic Concepts
Introduced using an example: see the accompanying Weak Entity: an entity whose existence depends on
gures for tickets and
ights. another entity's existence. e.g. entity Employee,
weak entity Job-history.
Note
Slide 4 ER diagramming: the entity construct is repre-
Summary of Basic Concepts sented by a (softbox) rectangle, with the entity name
written inside. The rst letter is capitalised (some-
 Entities times all are). A weak entity is represented by a dou-
 Relationships ble rectangle. An entity that is not weak is 'strong'
or 'regular'.
 Attributes
Slide 8
Slide 5 2. Attributes
Detailed Description of Basic Concepts `An attribute is the smallest discrete com-
1. Entities ponent of the system information that is
`An entity is something of signicance to meaningful'
the system about which information is to (Goodland and Slater [3])
be held'
(Goodland and Slater [3]) `An attribute is any detail that serves to
qualify, identify, classify, quantify or ex-
`An entity is a thing or object of signif- press the state of an entity.
icance, whether real or imagined, about
which information needs to be known or (Richard Barker [1])
held' An attribute can be almost anything, but in data
processing an attribute is always text or number.
(Richard Barker [1])
Slide 9
Slide 6
Attribute Rules
2
  An attribute must describe the entity with
which it is associated.
 Don't use the entity name as part of the at-
tribute name
 Relationships can have attributes
 Remove attributes that are not dependent on
the Key - they probably require a separate re-
lated entity.
Summary: So attributes are just characteristics
about entities that provide descriptive detail about
them. A particular occurrence of an attribute within
an entity is often called an attribute 'value'.
Key/Unique Identier: An attribute or composi- ER Diagrams: attributes are not always explic-
tion of attributes and/or relationships that uniquely itly represented. Sometimes they are simply writ-
identies each instance of an entity. (e.g. chassis
number is a Key for entity Car)
Sometimes called properties, (logical) data
items/elements
Slide 10
Example: Attributes and Key
Entity Attributes are similar to their name-sake in
the relational model:
Example: Patient (name, DoB, Gender, : : :)
Ward (Capacity, Name, : : :)
Drug (supplier, cost, : : :)
The Entity Key is simply a (chosen) `candidate key'
in the Relational Model: the key can be used to iden-
tify occurrences of entities
: : : so the concept is identical to the Primary Key of
the Relational Model
Example: Patient: id, name-address, NI no.
Ward: id, name
Drug: id, name-supplier, EU-code
Slide 11
Further Attribute Rules for Normalisation
ten beside the entity, or inside the entity rectangle.
Another attribute construct is an ellipse with the
attribute name written inside. Each ellipse is con-
nected to the entity it describes with an attachment
line.
Attributes can be shown to be simple or composite.
But a composite attribute will be normalised even-
tually. A multi-valued attribute is a repeating at-
tribute. Such an attribute will have to be reduced
to 1NF eventually. A multi-valued attribute that is
represented as an ellipse is shown with a double at-
tachment line.
Slide 12
Example: Attributes and Key
Example: Patient (name, DoB, Gender, : : :)
Ward (Capacity, Name, : : :)
Drug (supplier, cost, : : :)
This is simply a (chosen) `candidate key' in the Re-
lational Model
: : : so the concept is identical to the Primary Key of
the Relational Model
The key can be used to identify occurrences of enti-
ties
Example: Patient: id, name-address, NI no.
There are some rules that help to rene the choice Ward: id, name
of attributes associated with an entity to a useful Drug: id, name-supplier, EU-code
and concise set. These rules re
ect the process of
normalisation Note
Note An attribute can be either an key (identier) or a
non-key (descriptor).
 An entity cannot eventually have any repeated ER Diagrams: Key attributes can be underlined
attributes (1NF). If repeated attributes are re- to show their status.
quired, then a new entity must be created for
them at some time.
Slide 13
 Attribute or Entity ? An attribute becomes an 4. Relationships
entity when it is a thing in its own right with
relationships and attributes of its own `A relationship is an association between
two entities that is important to the sys-
 Remove attributes that are dependent on only tem.'
part of the Key (2NF) - they will probably re-
quire a related entity. (Goodland and Slater [3])

3
Example: there is a relationship between patients in a relationship of type relationship name with
and drugs representing the fact that a given patient  
receives certain drugs. exactly one
A relationship has a type and an instance one or more
Relationships are between entities not attributes Entity B
(as in the relational model) Reverse this to complete the reading
These dene the access routes (navigation) through Example:
the system Each and every Patient must be treated by exactly
Note: A relationship is also an entity one GP.
| in the relational model this might be Q. Is that true?
a table of foreign keys Each GP may treat one or more patients.
Q. Is that true?
Note Slide 16
The entities that are involved in a given
relationship are sometimes said to be participants in
that relationship. Note: if R is mandatory then R 1 need not be
ER Diagrams: A relationship is represented as a if R is optional then R 1 need not be
labelled line between two entities. A relationship
can be recursive where the labelled line is a loop
that joins an entity to itself. Compare with relations in mathematics:
A relationship or labelled line can be adorned with
just one label: such a label should be interpreted mandatory relation  Total
appropriately depending on the direction of reading. optional relation  Partial (non-total)
Altenatively, a relationship can be labelled at each many-to-one relation  Function (Relation)
end of the line to give a more explicit description of one-to-one relation  One-to-one function
the situation (since the meaning of the relationship
is dierent depending on the direction).
The ER model is mathematical relations
Slide 14 : : : with pictures
4.1 Degree of a Relationship
many-to-many: Drug-to-Patient
one-to-many: GP-to-Patient
one-to-one: Person-to-Phone number Slide 17
ER Diagram Summary
Entities: rectangles
Also relationship may be: Attributes: (often not drawn) ellipses connected to
entities (with lines)
 optional "may be" (there exists at least one pair Relationships: Labelled lines
of unrelated entities) : : : nothing more than a graph of a (set of) rela-
tions
 mandatory "must be" (there does not exist a The degree and optional/mandatory nature are used
pair of unrelated entities) to annotate the graph.
The degree is written at each end of the relationship
Example: Mandatory: Patient-to-GP line
optional: Person-to-Phone no.
either: numerically
or using a `crow's foot' for the `many-end'
: : : which is better?
Slide 15 Optional and mandatory relations are drawn with
A helpful sentence ?
Each and every Entity A either: a circle and perpendicular
  stroke respectively
must be or a solid line and dashed line respectively
may be (each is a half-line)

4
 Slide 22
Slide 18 Identify entities
A Slight Improvement
We could use a set of numbers at each end of the  Patient
relation line to indicate the possible degrees of a re-
lation  Doctor
>; <; >=; <=;  Ward
. . . are all valid to use in degree notation.  Drug
This has the advantage of bringing the properties op-  Assistant
tional and mandatory and the degree of the relation
under one notational framework
e.g. >= 0 implies optional
Slide 23
Notice how the decision about the degree of a rela-
Slide 19 tionship helps clarify the situation:-
Many to Many
Optional many to manys are common in early stages.  Identies ambiguities
They are a sign that the relationship is not well un-
derstood.  Raises questions
Usually resolved to two one-to-manys with an addi-  Forces identication of assumptions
tional entity.
Usually automatically happens.
May simply be a two-way list that cannot be re-
solved. Slide 24
Resolution normally involves introduction of a link Questions
entity Asking questions helps us to make decisions about
Examples: Patient-Drug might use Prescription the design: both the required entities and their at-
Items-Orders might use Invoice tributes.
Tickets-Flights might use Boarding Pass 1. Which doctors work in which wards?
Borrowers-Books might use Copy
2. How many patients does Dr X treat?
3. Which rank is Dr X?
Slide 20 4. Which assistants can a patient expect to see?
Relations and Tables 5. When was a patient admitted?
Once the diagrams are well formed, we can make ta-
bles. Each entity is a table. We must now normalise 6. Which drugs are being used?
the tables - BCNF if possible. This requires using
our old friend functional dependency analysis. 7. Which patients take a specic drug?

Slide 21
Another Example Slide 25
Model a component of a hospital system:- Summary
Patients are treated in a single ward by the doctors ERD brings out issues:-
assigned to them. Usually each patient will be as-
signed a single doctor, but in rare cases they will  Many-to-Manys
have two.
Healthcare assistants also attend to the patients, a  Ambiguities
number of these are associated with each ward.  Entities and their relationships
Initially the system will be concerned solely with
drug treatment. Each patient is required to take a  What data needs to be stored
variety of drugs a certain number of times per day
and for varying lengths of time.  The Degree of a relationship

5
References
[1] Richard Barker. Case Method Entity Relation-
ship Modelling. Addison Wesley, 1989.
[2] Peter Pin-Shan Chen. The Entity-Relationship
Model | toward a unied view of data. ACM
Transactions on database systems, 1, March
1976.
[3] Mike Goodland and Caroline Slater. SSADM |
A practical approach (version 4). McGraw{Hill,
1995.