1. Entity Relationship Diagrams

2. Database Development Process
Business Information Requirements
Conceptual Data Modeling
Business view
Logical Database Design
Systems view
Physical Database Build
Technical Notes
Conceptual data modeling develops a formal model of the business information requirements using the ER modeling technique.
An initial, high level data model is created, and then refined and quality checked.
Database design transforms the ER model into designs for physical database objects including tables, indexes, views and tablespaces.
Database build involves developing and running structured query language (SQL) statements to create the physical database objects and can also involve loading an initial set of data into the database and granting user access privileges.
Operational Database

3. Terminology CONCEPTUAL LOGICAL (Business view) (Systems view) ANALYSIS
DESIGN
ENTITY
TABLE
RELATIONSHIP
FOREIGN KEY
Technical Notes
Conceptual modeling Unique identifiers reflect the way the business distinguishes between one instance of an entity and another. Multiple UIDs are possible one is designated as primary.
Logical modeling
Primary Unique Identifiers are mapped to Primary Keys.
Unique Identifiers are mapped to Unique Keys.
Surrogate keys may have to be created if the business keys are unacceptable in the technological environment.
ATTRIBUTE
COLUMN
PRIMARY KEY
UNIQUE
IDENTIFIER
UNIQUE KEY

4. Information Models Organize thought processes
Accurately model business data
Communicate with stakeholders
Analyze the scope
Provide sound basis for system design

5. CS 450 ERD Conventions attribute Cardinality (degree) empnum key M 1
Works For
EMPLOYEE
DEPARTMENT
entity
relationship
Participation Requirements (optionality)

6. Main Elements of an Oracle ERD
Relationship
CUSTOMER
# * customer number
* first name
* last name
o other initials
Unique
Identifier
held by
Entity
MEMBERSHIP
Exclusive Arc
Attributes
the holder of
COMPANY
Super-type
held by
the holder of
SUPPLIER
Technical Notes
Oracle follows the data modeling conventions defined by Richard Barker.
Other conventions exist to produce similar results. The appendix contains references to other data modeling conventions.
The ER model was introduced in 1977 by Peter Chen and has been refined by numerous computer scientists.
Sub-type
OTHER
COMPANY
part of
composed of
Recursive
Relationship

7. ENTITY RELATIONSHIP MODEL
Hardware and Software Independence
ENTITY RELATIONSHIP MODEL
Agreement Term
Product
NETWORK DATABASE
HIERARCHICAL DATABASE
Agreement
Agreement
Item 1
Product X
Item 2
Agreement
Product x
Product y
Item 1
Item 2
RELATIONAL DATABASE
Code
Date
Customer
Code
Description
Agreement
Number
Quantity
Product

8. Relationship Definitions
The way one entity relates to another
The business rules that link together business information needs
What one thing has to do with another
A named association between entities

9. Relationship Diagramming Conventions
A line between two entities
Lower case relationship name
Optionality (Minimum cardinality)
Mandatory - must be
Optional - may be
Technical Notes
A relationship is a line with two ends.
The name is the business rule which links two entities.
Write the name of each end of the relationship in lower case.
Each end can be optional or mandatory.
The degree is ‘one and only one’ or ‘one or more’. If there could be less than one, it is an optional relationship not a matter of degree.
Class Management
Point out the crow's foot.
Degree (Maximum cardinality)
One or more
One and only one

10. Relationship Diagramming Conventions
COPY
TITLE
Technical Notes
Another term for degree is Maximum Cardinality.
Another term for optionality is Minimum Cardinality.
Class Management
Point out the crow’s foot.
many
(crow’s foot)
optional
mandatory
one

11. Relationship Syntax Name Object Subject entity entity Optionality
must be or
may be
relationship
name
one or more or
one and only one
Each
entity 1
entity 2
Technical Notes
A relationship should make good English and business sense. It can be used with a stakeholder to validate the diagram.
Class Management
This slide shows the students how to read a relationship easily.
Subject
entity
Name
Object
entity
Optionality
Degree

12. How do you read this? assigned to EMPLOYEE DEPARTMENT Class Management
The next 7 slides are intended for in-class interactive use. They are for reinforcement and practice, and do not appear in the students’ notes.
You may prefer to use the other facilities available and create your own examples.
Ask a student to explain the relationship between EMPLOYEE and DEPARTMENT.
The next slide gives the solution.

13. How do you read this?
assigned to
EMPLOYEE
DEPARTMENT
Each EMPLOYEE must be assigned to one and only one DEPARTMENT
Class Management
Discuss any differences if there are any.

14. How do you read this? EMPLOYEE DEPARTMENT responsible for
Class Management
This slide can be used to ask another student to read the relationship in the other direction.
The next slide gives the solution.

15. How do you read this?
EMPLOYEE
DEPARTMENT
responsible for
Each DEPARTMENT may be responsible for one or more EMPLOYEES
Class Management
Discuss any differences.

16. Full Reading of Relationship
assigned to
EMPLOYEE
EMPLOYEE
DEPARTMENT
DEPARTMENT
responsible for
Each EMPLOYEE must be assigned to one and only one DEPARTMENT
Class Management
Use this slide to show how the relationship looks when it is drawn together.
It is simply a combination of the last four slides.
Each DEPARTMENT may be responsible for one or more EMPLOYEES

17. How do you read this? enrolled in STUDENT COURSE taken by
Class Management
Use this slide to get another student to read the relationship in both directions.
The next slide gives the answer.

18. How do you read this?
taken by
enrolled in
STUDENT
COURSE
Each STUDENT may be enrolled in one or more COURSES
Class Management
Discuss any differences.
Each COURSE may be taken by one or more STUDENTS

19. Analyzing and Modeling Relationships
Determine the existence of a relationship
Name each direction of the relationship
Determine the degree of each direction of the relationship
Determine the optionality of each direction of the relationship
Read the relationship aloud to validate it
Technical Notes
You must complete five steps to create a relationship.
Use the steps for each combination of entities that you identify.
Class Management
The next 5 slides discuss these steps in more detail.

20. Oracle’s Layout Guidelines
Parent Entity (1)
Child Entity
Dead Crows Fly East !
Parent Entity (2)

21. Attributes Badge Number - Identifies an employee
Name - Qualifies an employee
Payroll category (weekly or salaried) - Classifies an employee
Date of birth - Quantifies an employee
Employment status (active, leave, terminated) Classifies of an employee
Class Management
If any of the students mention foreign keys, make sure that they understand a foreign key is represented by the relationship in conceptual modeling, not by an attribute.
Do not raise the issue unless they do.

22. Finding Attributes Is this attribute really needed ?
Beware of obsolete requirements from previous systems
Technical Notes
Interviewing the user should be the primary source of information requirements.
Information can come from any available source.
For further information see CASE*Method Entity Relationship Modeling 5-6 and 5-7.
Beware of derived data

23. Attribute Diagramming Conventions
Inside the entity's soft box
Singular
Lowercase
EMPLOYEE
badge num
first name
last name
payroll num
date of birth
Technical Notes
Remember that an entity box can be expanded to the size necessary to hold attribute names.
employment status

24. Meaningful Components
PERSON
PERSON
last name
first name
name
Break down aggregate attributes
ITEM
code
type
vendor
num
Class Management
Let the students talk about their experiences with embedded code.
You could show examples on the board to illustrate aggregate attributes and embedded code fields. Demonstrate breaking them down until they cannot be further decomposed.

25. Verify for Single Value
RENTAL
transaction date
total amount paid
item
Can an attribute have more than one value for one instance of the entity?
Yes, more than one item may be rented at a time. An entity is missing.
Technical Notes
An entity for RENTAL ITEM is missing.
RENTAL
transaction date
total amount paid
RENTAL ITEM
item num

26. Attributes Which have Attributes
TITLE
Does information need to be stored about any of the attributes?
product code
title
description
review details
Yes, review details. An entity is missing.
Class Management
This is the result of creating the new entity.
REVIEW
author
comment
date recorded
product code
title
description
review details
TITLE

27. Finding Common or Derived Data
72----
Count
Total
Maximum, Minimum, Average
Calculation
Technical Notes
Relational principles state that data should be held once, once only, and in the best possible place.
Derived data is already held in another form.
Class Management
Explain why it is unnecessary, in conceptual modeling, to store derived data. The issues are examined when doing initial database design.
This slide often brings out discussions on data warehousing. That is discussed briefly in a later slide.
Derived attributes are redundant and can lead to inconsistent values

28. Attribute Optionality
Mandatory Attributes
A value must be stored for each entity instance
Tagged with *
Optional Attributes
A value may be stored for each entity instance
Tagged with o

29. Attribute Optionality
EMPLOYEE *
badge num *
first name *
last name o
title o
weight

30. Attribute Details and Volumes
Attribute - * Engine Size
Format Type Number
Maximum length 4
Average length 4
Decimal place 1
Unit of measure cc
Allowable values 900,1000,1500,1800,2000
Volume Initial %
Class Management
Ask the students for other examples. Make sure they can differentiate between an attribute and a value for that attribute.

31. Using a Domain Movie Mono AUDIO Stereo MON STE Audio SUR Game Surround
Class Management
Explain that a domain does not appear on a diagram but is part of the support information for the model.
Use other examples of domains, such as, months of the year or states. Explain that a domain is for common validation purposes.
Surround
Sound

32. Creating an Entity
For DB Planning

33. Adding Details

34. Domains

35. Creating Relationships

36. Diagrammer Behavior
Definition changes are stored in Repository even if the diagram is not saved.
Saving a diagram saves the layout.
Diagrams are not synchronized automatically.
Requerying is your responsibility.
Diagrams can be exported to, for example, Word documents.

37. Editing in the RON