1. Data Modeling
ISYS 464

2. Database Design Process
Conceptual database design:
The process of creating a data model independent of implementation details such as the target database model and physical considerations.
Logical database design:
The process of designing database logical structure based on a specific database model (such as relational model), but independent of a particular DBMS and physical considerations.
Physical database design:
The process of implementing the database on a secondary storage.

3. Requirements Collection and Analysis
The process of collecting and analyzing information about the organization that is to be supported by the database system, and use this information to identify the requirements for the new system.

4. User Views
A user view defines what is required of a database system in terms of the data to be held and transactions to be performed on the data from the perspective of a particular job role or enterprise application area.
Identifying user views helps to ensure that no major users of the database are forgotten when developing the requirements for the new database system.

5. Example of User’s View
Shopping cart
Bottom-Up approach

6. Fact-Finding Techniques
Examining documentation
Defining problem and need for database:
Internal memos, minutes of meetings, documents that describe the problem, organizational chart
Describe the current system:
Various types of flowcharts and diagrams, data dictionary, database system design, program documentation
Interviewing
Observing the enterprise in operation
Questionnaires

7. Conceptual Database Design Methodology
Identify entity types.
Identity relationship types between the entity types.
Identify and associate attributes with entity or relationship types.
Determine attribute domains.
Determine candidate keys and primary key.
Validate conceptual model:
Check for redundancy, support required transactions, review the model with user

8. Entity-Relationship Diagram
ER modeling is a top-down approach to database design that begins by identifying the entities and relationships between entities that must be represented in the model.
Relative ease of use.
Widespread CASE tool support.
The belief that entities and relationships are natural modeling concepts in the real world.

9. ERD Models Entities and Business Rules
Example:
A customer may submit any number of orders. However, each order must be submitted by exactly one customer.
A student may register for a section of a course only if he or she has successfully completed the prerequisites for that course.

10. Entities
An entity is a person, place, object, event, or concept in the user environment about which the organization wishes to maintain data.
Person: Employee, Student, patient
Place: Warehouse, Store
Object: Product, Machine.
Event: Registration, Sale, Renewal
Concept: Account, Course
Physical existence:
Customer, student, product, etc.
Conceptual existence:
Bank accounts, sale

11. Entity Type
A collection of entities that share common properties or characteristics.
An entity type represents a collection of entities.
In an ERD, it is given a singular name.
Diagrammatic representation:
A rectangle labeled with the name of the entity

12. Entity Instance
An entity instance is a single occurrence of an entity type:
Student entity: SID, Sname, Major
Two instances of Student entity type:
S1, Peter, Bus
S5, Paul, Sci

13. Relationship Type Relationship: Interaction between entity types.
It is an association representing an interaction among the instances of one or more entity types that is interest to the organization.
It has a verb phrase name:
Faculty teach Course, Faculty advise Student
Customer open Account, Customer purchase Product.

14. Figure 3-10 Relationship types and instances
a) Relationship type
b) Relationship instances 17

15. Degree of a Relationship
The number of participating entity types in a relationship.
Unary (recursive)
Binary
Ternary

16. Three kinds of Binary Relationship
1:1
1:M
M:M

17. M:M Relationship Peter Paul John Woody Alan Mary Linda Nancy Mia Pia
Girl
Boy
A boy may date 0, 1, or many girls.
A girl may date 0, 1, or many boys.

18. 1:1 Relationship Husband Peter Paul John Woody Alan Mary Linda Nancy
Mia
Pia
Wife
A man may marry 0 or 1 woman.
A woman may marry 0 or 1 man.

19. 1:M Relationship Father Child Peter Mary Brian Paul Linda Aron John
Woody
Alan
Mary
Brian
Linda
Aron
Nancy
Ronald
Mia
Pia
Child
A father has 1 or many children.
A child has 1 father.

20. Cardinality Constraint
A cardinality constraint specifies the number of instances of entity A that can (or must) be associated with each instance of entity A.
Participation constraint
Full participation (Mandatory)
Partial participation (Optional)

21. Notations

22. Other Notations UML Notations: Traditional: 0..1, 1..1 0..*, 1..* 3..5
Has
Student
Account
1..1
1..1 1 1
Student
Has
Account

23. 1:1 Relationship Examples: Husband, Wife State, State Governor
Order, Invoice

24. 1:M Relationship Examples: Father, Child Department, Employee
Customer, Order

25. M:M Relationship Examples: Boy friend, Girl friend
Bank customer, Bank account
Student, Student organization

26. Traditional ERD Notations1 1
Student
Has
Account M M M
Enroll
Advise 1 M
Faculty 1
Teach
Course

27. UML ERD Notations Has Student Account 0..* 0..* 0..* Faculty Course
1..1
1..1
0..*
Enroll
Advise
0..*
0..*
1..1
Faculty
Teach
Course
1..1
1..*

28. Book Notations Has Student Account 0..* Faculty Course Enroll Advise
Teach
Course

29. Other Examples A database to record visitors and web pages they view.
An online shopping website database to record customers, orders (shopping carts) and products purchased by customers.
An auction database to record sellers and the items they sell, buyers and the items they purchase.
University account database to record students, accounts and messages.

30. Recursive Relationship
A relationship type where the same entity type participates more than once in different roles.
Examples:
Employee – Supervise -- Employee
Student -- Tutor– Student
Faculty – Evaluate -- Faculty

31. Supervise
Supervisor
Employee
Superviswee
Employee
Supervise

32. Attributes Properties of an entity or a relationship.
Simple and composite attributes
Address:Street address, City, State, ZipCode
Street Address: Number, Street, Apt#
Single-valued and multi-valued attributes
Student’s Major attribute
Faculty’s DegreeEarned attribute
Vehicle’s Color attribute
Others: PhoneNumber, Address
Derived attributes
Keys
Candidate key, primary key, composite key

33. UML otations Student SID {PK} Sname Fname Lname Address Street City
State
Zip
Phone[1..3]
Sex
DateOfBirth
/Age

34. SID {PK}
Sname( Fname, Lname)
Address( Street, City, State, Zip)
{Phone}
Sex
DateOfBirth
[Age]

35. Fname
Lname
Phone
DateOfBirth
SID
Sname
Age
Student

36. Domains of Attributes
The set of allowable values for one or more attributes.
Input validation
Examples:
Sex: F, M
EmpHourlyWage: Between 6 and 300
EmpName: 50 charcters

37. Time-Dependent Attributes
Auditing
Reconstructing the database state at a point in time:
Database snapshot
Regulations:
Sarbanes-Oxley
Public Company Accounting Reform and Investor Protection Act of 2002 and commonly called SOX or SarbOx; July 30, 2002)
Example:
ProductPrice: PID, {PriceHistory(Price, TimeStamp)}

38. Attributes on Relationship Online Shopping Cart
Addr
CartID
Date
CID
Cname
Has M
ShoppingCart
Customer 1 M
Has M
Product
Price
PID
Pname

39. Online Shopping Cart Addr CartID Date CID Cname Has M ShoppingCart
Customer 1 M
Qty
Has M
Product
Price
PID
Pname

40. Attributes on Relationship
Examples:
Student/Course: Grade
Order/Product: Quantity
Product/Country: Date, Quantity

41. Enroll 0..* 0..* Student Course Student Course SID CID Grade EnrollM M
Course
Grade

42. N-ary Relationship Doctor – Patient – Ailment Police – Crimal – Crime
AirCraft – Bomb - Target

43. Figure 3-12 Examples of relationships of different degrees (cont.)
c) Ternary relationship
Note1: a relationship can have attributes of its own.
Note2: This ternary relationship exists only if there is
no binary relationship between these three entities. 22

44. Problems with ER Models Connection Traps
Fan traps: Where a model represents a relationship between entity types, but the pathway between certain entity occurrences is ambiguous
Has
Oversees
Branch
Staff
Division
1..*
1..1
1..1
1..*
Which branch does Peter work?
Has
Oversees
Branch
Staff
Division
1..*
1..1
1..*
1..1

45. Chasm Traps
Where a model suggests the existence of a relationship between entity types, but the pathway does not exist between certain entity occurrences.
Has
Oversees
Branch
Staff
PropertyFor
Rent
1..*
1..1
0..1
0..*
Which properties are available at each branch?

46. Entity Type not System User or Organizational Unit
Report Me
SendTo
MyCompany
Department
Has
Note: An entity type represents a collection of entities.

47. Figure 3-21 Examples of multiple relationships
a) Employees and departments
Entities can be related to one another in more than one way 40

48. Online Shopping Cart Addr CartID Date CID Cname Has M ShoppingCart
Customer 1 M
Query database:
How many carts generated for customer “Peter”
Products ordered in a cart.
Total amount of a cart.
Today’s total sales.
Total sales by products.
Qty
Has M
Product
Price
PID
Pname