1. IS 4420 Database Fundamentals Chapter 3: Modeling Data in the Organization Leon Chen

2. Systems Development Life Cycle
Database Development Process
Enterprise modeling
Project Identification
and Selection
Conceptual data modeling
Project Initiation
and Planning
Analysis
Logical Design
Logical database design
Physical database design and definition
Physical Design
Implementation
Database implementation
Maintenance
Database maintenance

3. Overview What is data modeling Importance of data modeling
Business rules
Entity-relationship model: entities, relationships, and attributes

4. Conceptual Data Modeling
Business Rules
Data names
Data definitions
Conceptual Data Model
(Entity-Relationship Diagram)

5. Data Modeling is the Most Important
Input for follow-up processes
Data rather than processes are the most complex
Data tend to be more stable than business processes

6. Business Rules
Statements that define or constrain some aspect of the business. For example:
Friday is business casual dress day
Students can only register a course if prerequisite is successfully completed
Automated through DBMS software

7. Entity-Relationship Model
A logical representation of the data for an organization or for a business area
3 constructs:
Entity - person, place, object, event, concept (often corresponds to a row in a table)
Attribute - property or characteristic of an entity (often corresponds to a field in a table)
Relationship – link between entities (corresponds to primary key-foreign key equivalencies in related tables)
Type vs. instance
Entity type: Instructor
Entity instance: Leon Chen
Entity-Relationship Diagram
A graphical representation of entity-relationship model
Also called E-R diagram or just ERD
STUDENT
Name
Registers 2

8. Sample E-R Diagram (Figure 3-1) Attribute
Supplier_ID
Supplier_Name
Supplier_Address 3

9. A special entity that is also a relationship
Relationship symbols
Attribute symbols
Entity symbols
A special entity that is also a relationship
Relationship degrees specify number of entity types involved
Relationship cardinalities specify how many of each entity type is allowed 8

10. Entity Person: EMPLOYEE, STUDENT Place: WAREHOUSE, COUNTRY
Object: BUILDING, MACHINE
Event: SALE, REGISTRATION
Concept: ACCOUNT, COURSE
CERTIFICATE
EMPLOYEE
DEPENDENT
Weak entity
Strong entity
Associative entity

11. What Should an Entity Be?
SHOULD BE:
An object that will have many instances in the database
An object that will be composed of multiple attributes
An object that we are trying to model
SHOULD NOT BE:
A user of the database system
An output of the database system (e.g. a report)

12. Figure 3-4
Inappropriate entities
System user
System output
Appropriate entities

13. Attribute Attribute - property or characteristic of an entity type
Classifications of attributes:
Required vs. Optional Attributes
Simple vs. Composite Attribute
Single-Valued vs. Multivalued Attribute
Stored vs. Derived Attributes
Identifier Attributes - keys 5

14. Required vs. Optional Attributes
Example: entity – ONLINE_ACCOUNT
Required attributes (Not NULL)
Account_ID
Password
Owner_Name
Optional attributes
Phone_Number
Password_Hint

15. Figure 3-7 – A composite attribute
An attribute broken into component parts 12

16. Figure 3-8 – Entity with a multivalued attribute (Skill) and derived attribute (Years_Employed)
from date employed and current date
Multivalued:
an employee can have
more than one skill 13

17. Figure 3-19 – An attribute that is both multivalued and composite
This is an example of time-stamping.
More examples? 37

18. Identifiers (Keys)
Identifier (Key) - An attribute (or combination of attributes) that uniquely identifies individual instances of an entity type
Candidate Key – an attribute that could be a key. Examples (for STUDENT, PERSON)?
Simple Key versus Composite Key 6

19. Figure 3-9a Simple key attribute
The key is underlined 14

20. Figure 3-9b Composite key attribute
Flight_Number
Date 15

21. Guidelines for Identifiers
Will not change in value
Will not be null
Substitute new, simple keys for long, composite keys
?  Game_Number 7

22. Relationship Relationship Type vs. Relationship Instance
Degree of a relationship
Cardinality of a relationship
Associative Entity – combination of relationship and entity

23. Figure 3-11a
attribute of the relationship
The relationship type is modeled as the diamond and lines between entity types 20

24. Relationship Instance is between specific entity instances

25. Degree of a relationship is the number of entity types that participate in it
Entities of two different types related to each other
One entity related to another of the same entity type
Entities of three different types related to each other 8

26. Cardinality of a Relationship
One-to-One
Each entity in the relationship will have exactly one related entity
One-to-Many
An entity on one side of the relationship can have many related entities, but an entity on the other side will have a maximum of one related entity
Many-to-Many
Entities on both sides of the relationship can have many related entities on the other side

27. 22

28. 23

29. Note: a relationship can have attributes of its own24

30. Cardinality Constraints
Cardinality Constraints - the number of instances of one entity that can or must be associated with each instance of another entity
Minimum Cardinality. Examples?
If zero, then optional
If one or more, then mandatory
Maximum Cardinality. Examples?
The maximum number 29

31. Cardinalities Mandatory one Mandatory many Optional one Optional many11 18

32. Figure 3-16a Basic relationship
Mandatory minimum cardinalities – Figure 3-17a 1

33. Optional cardinalities with unary degree, one-to-one relationship
Figure 3-17c
Optional cardinalities with unary degree, one-to-one relationship 34

34. Maximum Cardinality Constraint
max cardinality constraint 41

35. Entities can be related to one another in more than one way40

36. Attributes or Relationship?
Attributes can be transformed to relationships

37. Attributes or Relationship?
Attributes should be transformed to relationships

38. Associative Entities It’s an entity – it has attributes
AND it’s a relationship – it links entities together
When should a relationship with attributes be an associative entity?
All relationships for the associative entity should be many
The associative entity could have meaning independent of the other entities
The associative entity should have at least one or more attributes other than the identifier
The associative entity may participate in other relationships other than the entities of the associated relationship
Ternary relationships should be converted to associative entities

39. Figure 3-11b – An associative entity (CERTIFICATE)21

40. Bill of materials structure27

41. Figure 3-18 – Ternary relationship as an associative entity36

42. Strong vs. Weak Entities
Strong entities
exist independently of other types of entities
has its own unique identifier
represented with single-line rectangle
Weak entity
dependent on a strong entity…cannot exist on its own
does not have a unique identifier
represented with double-line rectangle
Identifying relationship
links strong entities to weak entities
represented with double line diamond

43. Strong entity
Identifying relationship
Weak entity

44. Figure 3-22a
E-R diagram for Pine Valley Furniture

45. Microsoft Visio Notation for Pine Valley Furniture
Different modeling software tools may have different notation for the same constructs

46. A special entity that is also a relationship
Relationship symbols
Attribute symbols
Entity symbols
A special entity that is also a relationship
Relationship degrees specify number of entity types involved
Relationship cardinalities specify how many of each entity type is allowed 8

47. Sample E-R Diagram (Figure 3-1) Attribute
Supplier_ID
Supplier_Name
Supplier_Address 3