Database Design

Conceptual Database Design  Requirements collection and analysis

 Determine what information the database must hold
 Determine the relationships among the components
of that information
Entity/Relationship (E/R) Model Conceptual database design using some data model
 A data model is a collection of concepts for describing:
1. data and relationships among data
2. data semantics and constraints

1 2

Design Approaches & Notations Entity-Relationship (E/R) Model

 Entity-Relationship Model (E/R)  E/R model (Chen 1976) is a graphical
 Object-Oriented (e.g., Object Definition Language -- ODL) language/notation to present a database model
 Semi-structured data (e.g., XML)  It grew out of modeling applications
 Widely used in conceptual database design
A Design Process  No single standard for the E/R language/notation

Relational
Ideas E/R Relations
DBMS

3 4

Entity-Relationship (E/R) Model Entities and entity sets

 Collection of abstraction / modeling primitives  Entity – A real world object that is “distinguishable” from
other objects
Entity set Weak entity set  Entity Set -- A collection of similar entities
 All entities in an entity set have the same set of attributes
Relationship set Weak relationship set  In ODL:
 Object corresponds to entity
 Class corresponds to entity set
Attribute Inheritance
isa lastName firstName courseNumber name
Multiplicity of relationships
ID Students Courses
Referential integrity

5
GPA address credits 6

1
Entities and entity sets Relationships and Relationship Sets
 Relationships are association among entities
 Relationship set is a set of relationships of the same type
year  If E1, . . ., En are entity sets, a relationship R on these sets is
title name address defined as: R ⊆ E1 × . . . × En
• In general, relationships are n-ary, where n ≥ 2
Movies Stars • Many database relationships are binary

lastName firstName courseNumber name

length filmType
ID Students EnrolledIn Courses

GPA address credits

7 8

Relationships and Relationship Sets Multiplicity of Binary Relationships

 EnrolledIn relationship between entity sets Student and
Course is many-many
title year name address

Movies Stars-In Stars lastName firstName courseNumber name

ID Students EnrolledIn Courses
length filmType

GPA address credits

9 10

Multiplicity of Binary Relationships Multiplicity of Binary Relationships

 In E/R diagrams, arrows indicate multiplicity of relationships
title year name address
courseNumber DepID name
name
Movies Owns Studios
Courses GivenBy Departments

address length filmType

credits
 If a relationship is many-one from entity set Course to Department, we
place an arrow entering Department  The arrow indicates that each entity/tuple in relation Movie is
 The arrow indicates that each entity in the entity set Course is related to “related to” at most one entity in Studio
at most one entity in the entity set Department
 In this case, we may also say that the relationship from Department to
 Owns relationship is one-many from Studio to Movie
Course is one-many (also shown as 1-M). 11 12

2
Multiplicity of Binary Relationships Multiplicity of Binary Relationships
 The relationship Chair between the entity sets Department and
Professor is one-one, indicating which professor is the chair of
which department. Note that this represents also the situation where
a department is assigned no chair.
name address name address
lastName firstName DID name Presidents Runs Studios
ID Professors Chair Departments

address
researchArea address

13 14

Multiway Relationships Multiway Relationships

 ODL (an OO notation which we will introduce later) allows
defining only binary relationships, i.e., relationships involving name address
two classes.
 In general, we need to represent n-ary (multi-way) relationships, Studios
i.e., relationships involving more than two entity sets
 E/R model allows defining n-ary relationships conveniently. title year name address
 An n-ary relationship in E/R is represented by a diamond Contracts Stars
Movies
connecting all entity sets involved.

length filmType

15 16

Attributes on Relationships Attributes on Relationships

 Consider EnrolledIn relationship between Student and Course
name address
lastName firstName courseNumber name
Studios
ID Students EnrolledIn Courses
title year name address
GPA address credits
Movies Contracts Stars
grade
 We may wish to record student’s grade for this course length filmType salary
 Where should it go?
 Sometimes, it is more appropriate to associate attributes with a  Suppose we want to record the star’s salary associated
relationship rather than with the entity sets involved with this contract
17  Where should it go? 18

3
Moving an attribute to an entity set Moving an attribute to an entity set
 We could add an attribute(s) to a relationship
 Alternatively, we could do the following: lastName firstName courseNumber name
 invent a new entity set, whose entities have the attributes
ascribed to the relationship ID Students EnrolledIn Courses
 “connect/include” this entity set in the relationship
 omit the attribute from the relationship itself GPA address credits

 Consider again the “salary” for the “Contract” example: Grade

letterGrade
19 20

Moving an attribute to an entity set Roles in Relationships

name address  It
is possible that one entity set appears two or
Studios more times in a relationship
title year name address  Suppose, we want to capture relationship
between two movies, one of which is the sequel of
Movies Contracts Stars
the other
length filmType
Salaries

amount 21 22

Roles in Relationships Roles in Relationships

Each line to the entity set represents a different role that
Original the entity set plays in the relationship
title year Follow-up

Sequel-of Movies
courseNumber Name

length filmType Courses

Prereq-Follow
Sequel
No-of-credits
Each line to the entity set represents a different role that the entity
set plays in the relationship 23
Prerequisite 24

4
 A more complex example Converting n-ary relationship to binary
 Suppose, each star is associated with exactly one studio  Any n-ary relationship R can be converted into a
 Supp. studio s1 of star a1 may further contract with another studio collection of M-1 binary relationships without loosing
s2 to allow a1 to play in movie m2 made by studio s2 the information represented by R
name address  To do this:
Studios  Introduce a new entity set E, called connecting entity set,
Studio
whose entities might be thought of as tuples in R (the original
Producing
studio of star n-ary relationship)
 Introduce M-1 relationships from E to each one of the entity sets
title year name address involved in R
Movies Contracts Stars  If an entity set E plays more than one role, then E is the target
of one relationship for each role

length filmType 25 26

Converting n-ary relationship to binary Converting n-ary relationship to binary

name address name address

Studios Studios
Producing Studio Studio Producing Studio
of star
studio Producing of star studio of star
studio Contracts
Contracts

Movie-of Movie-of
Star-of Star-of
title year title year
Movie Contracts name address Movies name address
Stars Stars 28
length filmType 27
length filmType

Inheritance in E/R Inheritance in E/R

 Inheritance in E/R is expressed by isa relationship
title year
lastName firstName to Stars
Movies
to Professors ID Students isa
isa length filmType
isa Voices
isa GPA address
SupervisedBy weapon

major Murder-
option Cartoons Mystery
GradStudents UgradStudents
29 30

5
 Inheritance in E/R Constraints
 There is a subtle difference between the concept of inheritance in  There are some important aspects of the real world that
an OO approach and in E/R
cannot be represented using the ODL or E/R model
 In OO, an object must be a member of exactly one class
introduced so far
 In E/R
 We consider an entity as having “components” belonging to several  The additional information about these aspects often takes
entity sets that are “part of” a single isa-hierarchy the form of constraints on the data
 The “components” are connected into a single entity by the isa
relationships  Sometimes modeling this additional information goes
 The entity has whatever attributes any of its components has, and beyond the structural and type constraints imposed by
participates in whatever relationships its components participate in classes, entity sets, attributes, and relationships
 In an E/R diagram, we represent an entity set (e.g.,
CartoonMurderMystery) only if it has attributes and/or relationships
of its own
31 32

A Classification of Constraints Keys

 A Key K is a set of attribute(s) that uniquely identifies an object  A superkey is a set of attributes whose values uniquely identify an
within its class or an entity within its entity set R; Defn: K ⊆ R. entity (object) in the entity set (class); this set may not be minimal.
 That is, no two entities may agree in all their key values
 A minimal superkey is called a (candidate) key.
 Single-value constraints are requirements that the value in a
certain context/role be unique. In addition to key constraints, there  An entity set may have more than one candidate key. One of them
are other sources of single-value constraints (e.g., M:1 or 1:1 is picked (by ?) as the primary key; others may be called alternates
relationships, like a department’s chair)  In E/R, we underline the attributes forming a key of an entity set
 Referential integrity constraints are requirements that a value  No notation in E/R for alternate keys
referred to by some object/entity must actually exist in the database;
lastName firstName
This means, no dangling pointers
 Domain constraints require that the value of an attribute must be ID Students
drawn from a specific set of values (called attribute domain), or lies
within a specific range Here, ID is the key of Student
 General constraints – arbitrary assertions that must hold on the 33db GPA address34

Example Example
 What should we consider as a key for Movie ?  What should be the key for Star = {name, address}?
 title?  name?
 there could be different movies with the same name  We may think that the name cannot serve to distinguish two
 {title, year}? people, but for stars, the names distinguish them, since
traditionally they choose “stage names” as names
 there still could be two movies with the same title made in the
same year, but that’s very unlikely as we understand!
title year
name address
Movies {title, year} is a key for Movie
Stars {name} is the key for Star
length filmType
35 36

6
Example Selecting Primary Key
 What should be considered as the key for Studio? B
A C Suppose candidate keys for E are :
 name? 1. {A, B}
H E D 2. {D, N}
 It is “reasonable” to assume that there are no studios
3. {G, M, N}
with the same names N
G M
name address

Studios  Which of the three should be pick as the primary key?

{name} is the key for Studio

37 38

Selecting Primary Key Single-Value Constraints

 Some criteria to choose a primary key when there are  In E/R:
alternate keys (i.e., more than one candidate):  attributes are atomic (first normal form, 1NF)
 Total size of the attributes forming a key
 Number of attributes forming a key  an arrow (→) can be used to express the multiplicity
 Convenience/Natural choice  What about multi-valued or structured in E/R?
 A combination of the above No for attributes but Yes for relationships

39 40

Single-Value Constraints Referential Integrity Constraints

 Suppose A is a single-valued attribute.  For relationships:
 Single-value + Existence = Referential Integrity Constraint
 Using the E/R model introduced so far, we can’t:
 We extend the arrow notation to indicate a reference is
 Express that the value for A must be present
mandatory (to support referential integrity)
(e.g., when A is the key or part of a key), or
 Express that the value for A may be present courseNumber name ID name
(e.g., when A’s value is optional, for which we use NULL)
Courses GivenBy Departments
 If the choice is not explicit, we use the following “defaults”:
 The value for A must exist if A is part of the key credits address
 The value for A is optional, otherwise
 This means, there is no course listed in the database unless there
41
is a department giving the course. 42

7
 Referential Integrity Constraints Domain constraints
 Domain constraints restrict the values of an attribute to
title year name address name address be drawn from a set
Movies Owns Studios Runs Presidents  E/R does not support imposing domain constraints
 ODL allows using types to limit/control possible values of the
length filmType attributes
 ODL does not support restricting the “range” of values allowed
 The studio for a movie must always be present in Studio for an attribute
 If someone is a president, then the studio that he/she runs must
exist in Studio
 However, the model allows studios without presidents (temporarily)

43 44

Weak Entity / Relationship Sets:

Relationship degree constraints Example
 Relationship degree constraints (multiplicity) restrict the number  Log records the transactions initiated through an ATM
of entities in the entity sets involved in a relationship
 For example, we can impose a constraint that:  Each transaction has a number, a date, and an amount
a student cannot be enrolled in more that 5 courses  Different accounts might have transactions by the same
 In E/R, we may attach a “bounding number” to the corresponding link number, on the same date, and for the same amount
 In ODL, a set of references or an array of size 5 (of reference type) will do

number amount account# balance

lastName firstName courseNumber name
Transactions log Accounts
≤5
ID Students EnrolledIn Courses
date
GPA address credits
45 46

Weak Entity / Relationship Sets Another example

 A strong entity set has a key
 A weak entity set does not have sufficient attributes of its
 A movie studio may have several film crews
own to form a key. It participates in a M-1 relationship  The crews in a studio may be designated as
(with no descriptive attributes) with a strong entity set
crew 1, crew 2, and so on
 Discriminator of a weak entity set is a set of attributes
that distinguishes among the entities corresponding to a  All studios use the same designations for crews
strong entity
 key of a weak entity set = key of the strong entity together number name address
with the discriminator of the weak entity
Crews Unit-of Studios
 In E/R, these are represented by:

47 48

8
 Sources of Weak Entity Sets Sources of Weak Entity Sets
 Entity sets fall into a hierarchy  Connecting entity sets (CES):
 The entities in set Crew are sub-units of entities in set Studio
• The “numbers” used for crew entities are not unique until we  CES’s often have no attributes of their own
take into account the name of Studio with which she/he is  Their key is formed from the key attributes of the entity
associated (subordinate)
 It is possible to have a chain of “weak” entity sets/relationships sets which they connect
 A connecting entity set is always weak
number number name address

Sub-Crews Part-of Crews Unit-of Studios

49 50

Example
name address Design Principles
Studios
 Design should
Producing Studio  Reflect the “reality” we are trying to model – faithful/realistic
studio of star  Avoid redundancy -- minimal
Contracts
• Redundant information takes space
• Could cause inconsistency
Movie-of salary  Be as simple as possible
Star-of
title year  Be careful when choosing between using attributes and
Movies
using classes or entity sets. Remember that:
name address
 An attribute is simpler to implement than a class/entity set or a
Stars relationship
length filmType  If something has more information associated with it than just its
51 name, it should probably be modeled as an entity set or a class52

A quick test!
 Which of the following statements is NOT correct?
A. A data model is a collection of concepts for describing data and
their relationships.
B. A data model is a language for describing the data semantics
and the constraints.
C. A data model is a language for expressing queries and
transactions over a database.
D. A data model is an abstract representation of the structure of
the data.

53