Entity-Relationship (E-R) modeling: constructing a conceptual schema (Chapter 5) Due to course...
54
Entity-Relationship (E-R) modeling: constructing a conceptual schema (Chapter 5) Due to course constraints I have to defer other modeling issues (normalization in chapters 3 and 4) until later in the semester.
Entity-Relationship (E-R) modeling: constructing a conceptual schema (Chapter 5) Due to course constraints I have to defer other modeling issues (normalization
Entity-Relationship (E-R) modeling: constructing a conceptual
schema (Chapter 5) Due to course constraints I have to defer other
modeling issues (normalization in chapters 3 and 4) until later in
the semester.
Slide 2
Entity a thing you need to model. It is analogous to a class in
object oriented design. Fields of an entity are called attributes.
An entity instance is an occurrence of a particular entity. It is
analogous to an object. However, there is no encapsulation in the
OO sense.
Slide 3
One or more attributes is usually an identifier, which uniquely
identifies an entity. It is also called a key, though the term
identifier is used in the data model and key is used when creating
tables. Semantics.
Slide 4
Design issue: Many designers like to keep each identifier and
primary key dataless This means that it contains no information
about the entity. This way, they never change. Ex. IDs, account
numbers, etc.
Slide 5
Advantageous if theres an index or hash function that uses the
keys since a changing key would change the internal structure. Also
useful since a key value sometimes exists in other records that are
related to the entity with the given key. These would need to
change also.
Slide 6
A relationship defines how two or more entities are connected
according the rules in the reality you are modeling.
Slide 7
Some guidelines A relationship should be named and well-
defined. Do not simply state there is a relationship between two
entities. Articulate what the relationship represents.
Slide 8
Example: there is a relationship between a student entity and a
course entity. So? Does it represent courses for which the student
has registered? Does it represent courses dropped? Does it
represent courses needed for a major? Does it represent courses on
a transcript? Spell it out!!
Slide 9
Degree of a relationship is the number of entities involved.
Most are degree 2 (binary relationships) but some are more. A
ternary relationship involves 3 entities. Example: p. 148. Can you
think of more?
Slide 10
Cardinality is the number of entity instances in a
relationship. Maximum cardinality is the maximum number of
instances in a relationship. For example, the relationship between
a sports team and its players has a maximum cardinality defined by
rules of the sport.
Slide 11
Three types of maximum cardinality 1-1 relationship between A
and B For each instance of type A there is no more than one
instance of type B, and vice-versa. Notation and example: p.
149
Slide 12
Some possible examples: Employee fleet vehicle Project employee
(defined by who is project leader and assumes each employee leads
no more than one project.) Employee computer 1:1
Slide 13
1-many relationship between A and B For each instance of type A
there may be many instances of type B; however, for each instance
of type B there is no more than one instance of type A. Notation
and example: p. 149.
Slide 14
Other possible examples: Course sections Departments employees
project employees (participation) Employee computer 1:N
Slide 15
May actually specify a maximum number. Example: Team-players.
Number depends on the sport. Sometimes the term parent applies to
the entity on the one side and child applies to the entity on the
many side.
Slide 16
Many-many relationship between A and B For each instance of
type A there may be many instances of type B, and vice-versa.
Notation: p. 149 More examples follow
Slide 17
Students courses (could have several meanings) Authors books
Movies actors; advisors students; artist songs Major courses
N:M
Slide 18
These are sometimes called HAS-A relationships. A team has
players; a student has courses; etc.
Slide 19
Minimum cardinality May specify a minimum number of instances.
Can specify whether an instance is mandatory or optional. Examples:
p. 150. Can you think of more?
Slide 20
A crows foot notation (page 152-153) often used to provide a
visual of the relationships. Well use this notation in subsequent
diagrams
Slide 21
Weak entity Cannot exist unless another type of entity exists
Employee dependent (dependent is weak) building room (room is weak)
course section (section is weak) book has more
Slide 22
ID-dependent entity special type of weak entity in which the ID
contains the ID of another entity EX: Rooms on campus have an ID
such as MAC 122 (Building ID and room number). Other examples on
page 154 All ID-dependent entities are weak A weak entity may not
be ID-dependent (example p.155)
Slide 23
Shown in diagram using solid lines (ex. P.154) If the parent
entity is removed, so must all child entities. Dashed lines
represent non-identifying relationships
Slide 24
Strong entity existence does not depend on another entity. Ex:
Students, employees, departments, computer, building, etc.
Slide 25
Difference between strong and weak not always clear. Subject to
variances in interpretation of the mode. Kroenke lists possible
tests on page 156 and 160
Slide 26
Example: One-to-many relationship between a pharmaceutical
company and a drug. One-to-many relationship between an employee
and a dependent. Dependent does not exist w/o the employee. Drug
does not exist w/o the pharmaceutical company Are drug and
dependent both weak?
Slide 27
If the employee is removed the dependent disappears. If the
pharmaceutical company disappears, the drug may be assigned to
another company. Argues that the drug is strong.
Slide 28
Creating an E-R diagram using Visio: Open Microsoft Office
Visio. Select Software and Database under template categories.
Select Database Model Diagram as a template. Press the Create
button. Drag and drop one or more entity images to your
worksheet.
Slide 29
Double click on the icon and, through the properties pane below
the worksheet, you can give it a name and define its fields. Drag
and drop a relationship icon to the worksheet. Connect each end to
an entity.
Slide 30
To get the crows foot format select Display Options in the
database tab Select the Relationship tab check the Crows feet
checkbox. Double click the relationship icon select miscellaneous
under categories Select the appropriate cardinality.
Slide 31
NOTE: Visio does not allow the specification of a many-to-many
relationship. Does a poor job as a modeling tool. However, we will
see later that ALL many-to-many relationships can be implemented
via two one-to-many relationships
Slide 32
Probably best to NOT use visio for true data modeling diagrams.
But OK for defining relationships among tables and for this
course.
Slide 33
Ternary relationships. Doctor Patients Drugs Relationship below
does not convey all necessary information patient drug n:m doctor
drug n:m prescription prescribes
Slide 34
A specific drug given to a patient must have been prescribed by
a doctor. Would need doctor patient drugs
Slide 35
Building a data model: Interview the users of data. Find out
how they operate!! Look at existing forms, reports, files, lists,
etc. Determine entities. Look for key words such as order,
appointment, product, customer, etc.
Slide 36
Specify relationships. Examine all combinations of entities or
examine documents obtained from previous steps. Determine what
attribute (identifier) uniquely determines an entity.
Slide 37
Determine attributes. Ask whether an attribute should be its
own entity. Salesperson has a region: should region be just an
attribute or a separate entity? Data models should reflect reality.
Problem is one persons reality may be different than anothers.
Slide 38
See book for examples.
Slide 39
In Class example: Design a data model for a university
database.
Slide 40
Using Patterns to design relationships. Asking users what the
maximum cardinality is wont work they wont know what youre talking
about. You can show them a prototype form or report to learn how
many entity objects relate to another. Ex. Show a course form to a
user that shows one instructor. The user will likely let you know
if other instructors should be shown.
Slide 41
Figure 5-15a on p. 159 Suggests a 1-1 relationship between
strong entities member and locker Data model in Figure 5-16
Slide 42
Figure 5-17 on p. 160 Suggests a one-to-many between company
and department Figure 5-18 shows the model
Slide 43
Figures 5-19a and 5-19b on p. 161 The form and report suggest a
many-to- many relationship between company and part Data model in
Figure 5.20
Slide 44
Association pattern: Consider a n:m relationship connecting
students and courses (transcript). Where is the grade stored? It is
not part of the student entity It is not part of the course
entity.
Slide 45
The data model should show a 3 rd entity (transcript?)
containing the grade This is analogous to the example from figures
5.21 & 5.22 on p. 162-163
Slide 46
Multivalued attribute pattern when is an attribute not an
attribute Consider a customer entity. Is the phone number an
attribute? If just one number, store as an attribute. If multiple
numbers, might be a problem since arrays or lists can not be
attribute types in a relation.
Slide 47
May create an ID-dependent entity, PHONE, connected to the
customer. If just two numbers max, might create a primary and
secondary phone number attribute of the customer.
Slide 48
Archetype/Instance pattern One entity represents an instance of
another. Prints of a painting Copies of a book Sections of a
course
Slide 49
Line Item Pattern Multiple instances of an entity used to
describe another entity Ex: Line items to describe an order
Slide 50
Recursive relationships may be 1:1, 1:n, or n:m A course and
its prerequisites (n:m). A course may have multiple prerequisites
and may be a prerequisite for multiple other courses. Manufacturing
(Bill of Materials). Products consists of parts, some of which are
composed of other parts. Parts may be included in other parts (p.
173)
Slide 51
Basic ER modeling Define strong and weak entities. Define
relationships and categorize as 1:1, 1:n, or n:m The rest allows
you to refine for better accuracy.
Slide 52
Subtype entities Similar to inheritance. A subtype entity isa
special case of another entity (supertype). Ex. Distinction of male
and female patients for medical tests. Ex. Distinction of different
types of employees. Diagram notation on page 156 and 158.
Slide 53
Discriminator: supertype attribute that determines the subtype.
Ex: patient gender or employee classification. May not always
exist. Examples on page 156
Slide 54
An exclusive subtype means the supertype relates to at most one
subtype. An inclusive subtype means the supertype can relate to
more than one subtype. Ex. A patient is male or female, not both.
An employee might be a team leader, programmer, analyst, or
all.