Introduction to Database Systems
Winter term 2013/2014
Melanie Herschel
melanie.herschel@lri.fr
Université Paris Sud, LRI
1
Chapter 2
The Entity-Relationship Model
• After completing this chapter, you should be able to:
‣ Motivate and explain the three phases
of database design,
‣ Evaluate the significance of the
Entity-Relationship Model (ER model)
for DB design,
‣ Enumerate the basic constructs of the
ER model,
1.
2.
3.
4.
5.
Introduction
ER-Modeling
Relational model(ing)
Relational algebra
SQL
‣ Develop ER diagrams (schemas in the
ER model) for a given application.
2
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Ncis_ER_diagram.gif 1631×1448 pixels
Chapter 2
The ER-Model
• Database Design Overview
• Basic ER Constructs
• Cardinalities
• Keys, Weak Entities
• Design Principles
3
4/18/10 12:07 PM
Database Design
• Overall goal of DBMS usage: Efficiently develop programs to
support given real-world tasks.
• These programs need to store data persistently.
• To develop these programs, apply proven methods of software
engineering—specialized to support data-intensive programs.
Database design
• Database design is the process of developing a database
schema for a given application.
• Database design is a subtask of the overall software
engineering effort.
4
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Database Design
•The specification of programs and data is intertwined:
‣ The schema should contain the data needed by the programs.
‣ Programs are often easy to develop once the structure of the
data to be manipulated has been specified.
•Data, however, is an independent resource:
‣ Typically, additional programs will be developed later based on
the collected data.
‣ Also, ad-hoc queries will be posed against the DB.
5
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Database Design
•During DB design, a formal model of the relevant aspects of the
real world (“mini world”, “domain of discourse”) must be built.
• Once the DB is up and running, questions will be posed against the
DB. Knowledge of these questions beforehand is important input to
the DB design process and helps to identify the relevant parts of
the real world.
•In some sense, the real world is the measure of correctness for
the DB schema: the possible DB states should correspond to the
states of the real world.
6
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Database Design
•DB design is not easy for a variety of reasons:
‣ Expertise: The designer must become an expert for the
application domain or needs to talk to such experts. Depending
on the domain, these experts might not be used to give a
complete and formal account of their field.
‣ Flexibility: The real world typically permits exceptions and
corner cases. Does the DB schema need to reflect these?
‣ Size: Database schemas may become huge (in terms of number
of relations, attributes, constraints).
•Due to this complexity, DB design is a multi-step process.
7
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Database Design
Three phases of DB design
Conceptual
Database Design
Produces the initial model of the mini world in a
conceptual data model (e.g., in the ER model).
Logical
Database Design
Transforms the conceptual schema into the data model
supported by the DBMS (e.g., the relational model).
Physical
Database Design
Design indexes, table distribution, buffer size, etc. to
maximize performance of the final system (subject of
“DBSII - Implementation of database systems”).
8
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Database Design
Why multiple design phases?
• Partition the problem, attack one sub-problem after the other.
For example, during conceptual design there is no need to worry
about performance aspects or limitations of the specific SQL
dialect of the RDBMSs.
• DBMS features do not influence the conceptual design and only
partially influence the logical design.
➡ Thus, the conceptual design work is not invalidated if a different
DBMS is used later on.
9
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
The
ER Model
Das
Entity-Relationship-Modell
•Proposed by Peter Chen (1976), today at Louisiana State University.
Nach
Peter
P. Chen
1976
•The ER
model
comes
with a graphical notation which helps to
The entity-relationship
model
? towards
a unified
view of data.
establish
quick overviews of
database
application
schemas.
ACM TODS
•Such ER diagrams are also a great way to communicate schemas
to non-expert/future DB users.
Standardmodell in der frühen Entwurfsphase
10
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Felix Naumann | Datenbanksysteme I | Sommer 2009
Example
ER schema in graphical notation
Actor
Firstname
(1, m)
Lastname
DOB
stars_in
(1, n)
Movie
Title
Year
Director
•This mini world talks about actors and movies.
•Actors star in movies.
•Actors have a firstname, a lastname, and a date of birth (DOB)
•Movies have a title, a year, and a director.
11
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Example
A possible state of this mini world
Actor
Movie
Star Wars
title
Harrison firstname
year
1977
director
Ford
Lucas
lastname
DOB
title
13.7.1942
Raiders of the
Lost Ark
year
director
1981
Spielberg
12
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
The ER Model
•The Entity-Relationship Model is often referred to as a semantic
data model, because it more closely resembles real world scenarios
than, e.g., the relational model.
‣ In the ER model, we model the concept of “Actor”.
In the relational model we deal with names and dates of birth.
‣ In the ER model, there is a distinction between entities (objects)
and relationships between such entities.
In the relational model, both concepts are represented by
relations.
•There are no “ER Model DBMS”.
Instead, we will describe a translation of ER model concepts into
the relational model.
13
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Ncis_ER_diagram.gif 1631×1448 pixels
4/18/10 12:07 PM
Chapter 2
The ER-Model
• Database Design Overview
• Basic ER Constructs
• Cardinalities
• Keys, Weak Entities
• Design Principles
14
Basic ER Model Concepts
Entity
• An entity is an object in the mini world about which information is
to be stored. Examples: actors, movies, studios, awards.
http://www.meds-sdmm.dfo-mpo.gc.ca/MEDS/Prog_Nat/NCIS/Definition/Ncis_ER_diagram.gif
Page 1 of 1
• Note: entities do not have to correspond to objects of physical
existence. Entities may also represent conceptual objects like, e.g.,
vacation.
•The mini world that has to be modeled can contain only a finite
number of objects.
•It must be possible to distinguish entities from each other, i.e.,
objects must have some identity.
Examples: entity book identified by ISBN number, entity vacation
identified by travel agency booking number.
15
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Basic ER Model Concepts
Attribute
• An attribute is a property or feature of an entity (or relationship,
see below).
Example: the title of this movie entity is “Star Wars”.
• The value of an attribute is an element of a data type like string,
integer, date.
• These values have a printable representation (which entities have
not).
16
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Basic ER Model Concepts
Relationship
•A relationship represents a relation—not in the strict relational
model sense—between pairs of entities (a binary relationship).
Example: Ford (an entity) stars in (a relationship) the movie “Star
Wars” (an entity).
•“Relationship” is often used as an abbreviation for “Relationship
type” (see next slide).
17
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Basic ER Model Concepts
Entity and Relationship Type
Entity Type:
A set of similar entities (similar with respect to the information
which has to be stored about them), i.e., entities which have the
same attributes.
Example: All actors vs. all directors.
Relationship Type:
A set of similar relationships, i.e., relationships which have the
same attributes.
Example: X stars in movie Y.
18
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
ER Diagrams
Basic Graphical Syntax
•Entity type E
E
•Attribute A of entity type E
A
E
•Binary relationship R between entity types E1 and E2
R
E1
E2
19
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
ER Diagrams
Recursive Relationships
•Relationships may also exist between entities of the same type
(“recursive relationship”)
Recursive relationship
Original
Movie
is_sequel
Sequel
• In this case, role names have to be attached to the connecting
edges.
In the ER model, role names may be attached to any kind of
relationship for documentation purposes.
20
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
ER Diagrams
Attributes of Relationships
•Relationships may have attributes, too:
Relationship attributes
Actor
stars_in
Movie
Role
This models the fact that a role is stored for every pair of actor X
and Movie Y such that X starred in Y.
21
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
ER Diagrams
Graphical Syntax
• An ER diagram contains boxes, diamonds, ovals, plus
interconnecting lines.
• Boxes, diamonds, and ovals are each labelled by a string.
• Box labels are unique in the entire diagram.
• Oval labels are unique for a single box or diamond.
• Diamond labels are unique for a pair of connected boxes.
• Interconnecting lines are only allowed between
box—diamond, box—oval, diamond—oval.
• A diamond has exactly two connecting lines to boxes. There may
be any number of connections to ovals.
• An oval has exactly one connecting line.
22
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
ER Example
Modeling a mini world: define an ER diagram
• Information about movies is to be stored.
• For each movie, the title, release date, genre, and homepage URI are
relevant.
• Movies may be granted awards (e.g., Oscars, Palme d’Or, ...)
• Relevant award information are the name, the category, and the year of
the award.
• Each movie is produced by a studio (of a given name and address).
23
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
ER Schemas: Semantics
Definition
A DB state I interprets the symbols in the ER schema by defining
• A finite set I(E) for every entity type E,
• A mapping I(A):I(E) → val(D) for every attribute A of an entity
type E, where D is the data type of A and val(D) is the domain
of D,
• A relation I(R) ⊆ I(E1) × I(E2) for every relationship R between
entity types E1 and E2.
• A mapping I(A):I(R) → val(D) for every attribute A of relationship
R (D is the data type of A).
24
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
ER Schemas: Semantics
Example state corresponding to ER schema
stars_in
Actor
Firstname
Lastname
Movie
DOB
Title
Year
Director
•I(Actor) = {JD,HBC}
•I(Firstname) = f1 with f1(JD) = “Jonny” and f1(HBC) = “Helena Bonham”
•I(Lastname) = f2 with f2(JD) = “Depp” and f2(HBC) = “Carter”
•I(DOB) = f3 with f3(JD) = “09.06.1963” and f3(HBC) = “26.05.1966”
•I(Movie) = {CB,ST, PC}
•I(Title) = g1 with g1(CB) = “A Corpse Bride”, g1(ST) = “Sweeney Todd”,
and g1(PC) = “Pirates of the Caribbean”
•
•I(Year) = g2 with g2(CB) = 2003, g2(ST) = 2007, and g2(PC) = 2006
•I(Director) = g3 with g3(CB) = “Tim Burton”, g3(ST) = “Tim Burton”, g3(PC) = “Gore Verbinski”
25
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
ER Schemas: Semantics
Example state corresponding to ER schema (cont.)
• I(stars_in) = {(JD, CB), (JD, ST), (JD,PC), (HBC,CB), (HBC,ST) }
Actor
Movie
JD
HBC
CB
x
x
ST
x
x
PC
x
• Note: A relationship is interpreted by a set of entity pairs and
thus is unique for two given entities.
26
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
ER Schemas: Semantics
Consequences of the ER semantics
Cinema
shows
Movie
Time
• Consider the above ER diagram.
• Suppose a cinema shows the same movie twice a day (at 3pm and
6pm).
• Can this information be stored in the given schema?
27
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
From n-ary Relationships to Binary Relationships
• We have seen that an ER model represents binary relationships
only.
• However, in the real world, a relationship may relate more than two
entities to each other.
An n-ary relationship
has_contract_with
Actor
Movie
Studio
28
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
From n-ary Relationships to Binary Relationships
• To transform an n-ary relationship to a binary relationship, we
1.Create a new association entity type.
2.Introduce a relationship between the new entity type and the old
entity types.
3.If there is an entity with multiple roles, create a relationship
type per role.
4.Attributes of the old relationship type are appended to the new
entity type.
29
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
From n-ary Relationships to Binary Relationships
An n-ary relationship
has_contract_with
Actor
Contracting studio
Actor
signed_contract
Movie
Producing studio
Studio
Contract
is_contracting_studio
is_subject_of
Movie
is_producing_studio
Studio
30
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
From n-ary Relationships to Binary Relationships
Modeling that a cinema shows the same movie twice a day
shows
Cinema
Movie
Time
31
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
IS-A: A Special Type of Relationship
• Subclass
‣ Special case of the (super)class
‣ Less entities fall into the subclass (compared to the entities
falling in the superclass)
‣ More (specific) attributes
‣ Possibly more relationships to other entities.
• The ER model allows to specify a subclass in the form of an IS-A
relationship
‣ Represented as a triangle
‣ Tip is showing to the superclass
‣ The relationship implicitly is a 1:1 relationship (and is not
explicitly represented)
32
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
IS-A: A Special Type of Relationship
Subclasses to movies
Subclasses of movies are
• Animation movies
‣ One additional attribute
• Crime movies
‣ One additional relationship
Title
Year
Genre
Length
Movie
Actor
is_voice_of
IS-A
IS-A
Animation
Movies
Crime
Movies
Weapons
33
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
IS-A: A Special Type of Relationship
• The IS-A relationship forms trees, a class may have multiple
subclasses, but a class may not have multiple superclasses.
• An entity may consist of several components of the IS-A-tree
‣ “Star Wars” has four attributes.
‣ “Cindarella” has four attributes plus a “Voices” relationship.
‣ “Der Dritte Mann” has four attributes plus the “Weapons”
attribute.
‣ “Roger Rabbit” has four attributes, plus the “Weapons”-Attribute
and the “Voices”-Relationship.
34
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Ncis_ER_diagram.gif 1631×1448 pixels
4/18/10 12:07 PM
Chapter 2
The ER-Model
• Database Design Overview
• Basic ER Constructs
• Cardinalities
• Keys, Weak Entities
• Design Principles
35
Cardinalities
M:N Relationships
• In general, an arbitrary number of entities of type A can relate to an
arbitrary number of entities of type B via a binary relationship.
http://www.meds-sdmm.dfo-mpo.gc.ca/MEDS/Prog_Nat/NCIS/Definition/Ncis_ER_diagram.gif
Page 1 of 1
• An actor can star in numerous movies.
• A movie set comprises many actors.
• An entity of type A may not relate to any entity of type B, and vice versa.
• Meet the many “actors” sitting in LA cafes that have never played in
any movie.
• National geographic movies do not have actors.
A
B
➡ Many-to-Many or m:n relationship
‣ Special cases are
one-to-many (1:n) and
one-to-one (1:1) relationships.
36
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Cardinalities
1:N Relationships
• An entity of type A can relate to any number of entities of type B.
• An entity of type B can relate to at most one entity of type A.
• Example
• A movie may win many awards.
• An award is granted to one movie.
• Again, an entity of type A may not relate to any entity of type B, and
vice versa.
A
B
• A movie may not win any award.
37
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Cardinalities
1:1 Relationships
• An entity of type A can relate to at most one entity of type B.
• An entity of type B can relate to at most one entity of type A.
• Example
• A studio may only have one President.
• One President may only head one studio.
• Again, an entity of type A may not relate to any entity of type B and
vice versa.
A
B
• A studio may temporarily not have any president.
38
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Cardinalities
The (min, max) notation
• The ER model introduces the (min, max) notation to specify an interval
of possible participations in an relationship:
E1
(m1, n1)
R
(m2, n2)
E2
• An entity of type E1 may be related to at least m1 and at most n1 entities
of type E2.
• Likewise, m2 is the minimum number and n2 is the maximum number of
E1 entities to which an E2 entity is related.
39
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Cardinalities
The (min, max) notation
Formal Semantics
• For every DB state I and every entity e1 ∈ I(E1):
m1 ≤ | {e2 ∈ I(E2) | (e1, e2) ∈ I(R) } | ≤ n1
• For every DB state I and every entity e2 ∈ I(E2):
m2 ≤ | {e1 ∈ I(E1) | (e1, e2) ∈ I(R) } | ≤ n2
• Extensions:
‣ “ * ” may be used as maximum if there is no limit.
‣ (0, *) means no restriction at all (general relationship).
• Note that the maximum cardinalities on each side are used to
distinguish between m:n, 1:n, and 1:1 relationships.
40
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Cardinalities
The (min, max) notation
Studio Presidents (1:1 relationship)
“A studio can have at most one president and a president can preside at most one studio.”
President
(0,1)
(0,1)
is_president_of
Studio
Movie awards (1:n relationship)
“A movie award goes exactly to one movie. A movie may be awarded multiple awards (but
maybe none at all).”
Award
(1,1)
(0,*)
awarded_to
Movie
41
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Cardinalities
The (min, max) notation
Derive cardinalities from verbal specifications
“Besides normal customers, the database may contain customers who have not yet
ordered anything.”
Order
(
,
)
from
(
,
)
Customer
Derive cardinalities from verbal specifications
“An order can contain several products.”
Order
(
,
)
for
(
,
)
Product
42
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Cardinalities
Alternative notations
• Leave the minimum cardinality unspecified.
• This notation exactly represents m:n, 1:n, or 1:1 relationships.
Movie awards (1:n relationship)
N
Award
1
awarded_to
Movie
43
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Cardinalities
Alternative notations
• Sometimes found in software supporting visual ER diagram
development (e.g., in Oracle DesignerTM):
Movie awards (1:n relationship)
Award
awarded to
won
Movie
‣ The “crow foot” indicates the “many” side.
‣ Dashed lines indicate optional participiation.
‣ Relationship roles are given (for both sides).
44
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Cardinalities
Movie Example
Cardinalities in our movie scenario
Add cardinalities using the (min,max) notation
Actor
signed_contract
Contract
is_contracting_studio
is_subject_of
Movie
is_producing_studio
Studio
45
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Ncis_ER_diagram.gif 1631×1448 pixels
4/18/10 12:07 PM
Chapter 2
The ER-Model
• Database Design Overview
• Basic ER Constructs
• Cardinalities
• Keys, Weak Entities
• Design Principles
46
Keys
http://www.meds-sdmm.dfo-mpo.gc.ca/MEDS/Prog_Nat/NCIS/Definition/Ncis_ER_diagram.gif
Page 1 of 1
ER key
A key K of an entity type E is an attribute of E which uniquely
identifies the entities of this type. No two different entities share the
same value for the key attribute, i.e., I(K) is injective for all DB states I.
Composite keys are allowed.
K
A1
A2
E
47
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Keys
Keys in our movie scenario
• Movies
• Is title a good candidate key? (4 King Kong movies in IMDB)
• How about Title + Year? (Still around 300 “duplicate keys”)
• Actor
• Firstname+Lastname or
• Firstname+Lastname+DOB
• Studio
• Name
48
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Where is the Key?
49
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Keys
Keys in our movie scenario
Underline keys
Contract_ID
Date_Signed
Title
Firstname
Year
Lastname
signed_contract
Actor
Contract
is_subject_of
Movie
Type
DOB
Length
is_contracting_studio
is_producing_studio
Studio
Name
Address
50
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Weak Entities
•In many schemas, some entities describe a kind of detail that cannot
exist without a master (or owner) entity.
‣ If entities are part of an IS-A hierarchy
‣ If entities are association entities that have been created to eliminate
n-ary relationships.
‣ If the existence of the detail entity (e.g., a room) requires the existence
of the master entity (e.g., a building).
•In such a case,
1.There is a relationship with cardinality (1, 1) on the detail entity side,
and in addition
2.The key of the master is inherited and becomes part of the key of the
detail entity.
51
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Weak Entities
• Without a specific ER construct for this case, we would require the
following additional constraint:
‣ If two entities are in “has” relationship, e.g., an invoice and a position,
‣ Then their attribute “Inv No” are required to have identical values. For
example, invoice #12 cannot have position 2 in invoice #42 as detail.
• Such constraints occur if an entity does not have a key by itself, but it is
only unique in the context of some other (master) entity.
52
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Weak Entities
•Note: In such cases, keys are always composite.
•Examples:
‣ A classroom is identified by a building and a room number.
‣ A section in a book is identified by a chapter and a section title.
‣ A web page URI is composed of a web server DNS address and a
path on that server.
•There is also an existence dependency. For instance, if the building is
pulled down, the classrooms automatically disappear. If the web server is
shut down, all URIs on that server cease to function.
53
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Weak Entities
• In the ER model, such scenarios are modeled via weak entities (nonweak entities are also called strong entities).
• In ER diagrams, weak entities and their identifying relationships are
indicated by double lines.
• For the weak entity, the inherited part of the key is not shown.
• The relationship type between the weak entity and the identifying
owner is called identifying relationship and always describes a 1:N
relationship (see next section).
Notation of weak entities
(1,*)
Invoice
Inv_No
Date
has
(1,1)
Position
Pos
54
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Weak Entities
• Usage of weak entities is required only if the key of one entity
contains the key of a related entity. A weak entity adds further key
attributes to the master key.
• Weak entities are normal entities except that their key is constructed in
a special way.
• Weak entities may themselves be masters of other weak entities
(building an entire hierarchy of dependencies).
55
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Weak Entities
Modeling with weak entities
Model a set of online quizzies (multiple choice tests).
‣ Each quiz is identified by a title, each question within a quiz is numbered, and each possible
answer to a given question is referenced by a letter.
‣ For each question and answer, the associated text is stored. Answers are classified into correct
and incorrect ones.
• What is the complete key for each of the occurring entity types?
56
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Association Entities Revisited
• We saw that association entities are created in order to resolve n-ary
relationships.
• For instance, we found that modeling a cinema that shows the same
movie twice a day requires a ternary relationship.
• Use an association entity: turn relationship into weak entity with
multiple owners. Inherits keys of all owners.
Association entity “Show”
Name
Address
Cinema
does
Title
Time
Show
Desc
Movie
of
57
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Weak Entities in Movie Example
Weak entities in our movie scenario
Assuming keys and relationships identified earlier, do we have weak entities here? If not, what
would need to be changed to obtain at least one?
Contract_ID
Date_Signed
Title
Firstname
Year
Lastname
signed_contract
Actor
Contract
is_subject_of
Movie
Type
DOB
Length
is_contracting_studio
is_producing_studio
Studio
Name
Address
58
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Ncis_ER_diagram.gif 1631×1448 pixels
4/18/10 12:07 PM
Chapter 2
The ER-Model
• Database Design Overview
• Basic ER Constructs
• Cardinalities
• Keys, Weak Entities
• Design Principles
59
Basic Principles
•Design based on application need.
http://www.meds-sdmm.dfo-mpo.gc.ca/MEDS/Prog_Nat/NCIS/Definition/Ncis_ER_diagram.gif
Page 1 of 1
•Avoid redundancy.
•Keep it simple!
•Use relationships wisely (and sparingly).
•Use attributes wisely (and sparingly).
•Use weak entities wisely (and sparingly).
60
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Design Based on Application Need
•Entity types and attributes should reflect the reality and should be useful
for the application.
‣ When modeling movies, gender is not a sensible attribute.
‣ For applications like Amazon, storing the address of each actor does not
make much sens.
• Relationship types should reflect relationships in the real-world or the
semantics valid for the application
‣ Actors and movies are in an m:n relationship, 1:n, n:1 or 1:1 would not
correctly reflect the real world.
‣ The relationship between courses and teachers depends on the semantics
within the application:
- A course is taught by one teacher (1:n)
- A team of teachers teaches a course (m:n)
61
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Avoid Redundancy
• Redundant information occurs when the same information is
expressed in multiple ways.
• Redundancy wastes space, both on paper and on disk.
• Redundancy eases the appearance of inconsistencies, as information
has to be changed at all places where it is redundantly represented.
62
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Keep it Simple
KISS: Keep It Simple, St...!
• Avoid using unnecessary entity types.
‣ For instance, do you really care that a movie is represented by a holding
and that the holding in turn owns a studio?
• Avoid using unnecessary relationship types.
‣ For instance, does your application really need the distinction between
contracting studios and producing studios?
‣ Avoid redundancy when relationships can be derived.
• Avoid using unnecessary attributes.
‣ If your application does not use the actor nickname, there is no need to
model it.
63
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Attribute vs. Entity
• Attributes are easier to implement than entities and relationships.
• An entity type is justified if
• It represents more than just the name of an object, or
• it is the “n-part” or a 1:n relationship.
Association entity “Show”
• Studio only has a name as attribute.
• Studio is not the n-part of a 1:n relationship.
owns
Studio
Name
Movie
Movie
Title
Title
StudioName
64
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud
Summary
• Three phases of database design: conceptual, logical, and physical DB design.
• Basic ER constructs: entity types, relationship types, attributes
• 1:1, 1:N, and M:N relationships and min-max-notation.
• Inheritance of attributes through IS-A relationship.
• Keys in ER-models uniquely identify entities
• Modeling Existence dependency using weak entities
• Keep it simple!
65
Introduction to Database Systems | winter term 2013/14 | Melanie Herschel | Université Paris Sud