View
218
Download
2
Category
Tags:
Preview:
Citation preview
IS 4420Database Fundamentals
Chapter 3:Modeling Data in the
Organization
Leon Chen
2
Systems Development Life
Cycle Project Identification
and Selection
Project Initiation and Planning
Analysis
Physical Design
Implementation
Maintenance
Logical Design
Enterprise modeling
Conceptual data modeling
Logical database design
Physical database design and definition
Database implementation
Database maintenance
Database Database Development Development
Process Process
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
8
Sample E-R Diagram (Figure 3-1)
Supplier_ID
Supplier_Name
Supplier_Address
Attribute
9
Relationship degrees specify number of entity types involved
Entity symbols
A special entity that is also a relationship
Relationship symbols
Relationship cardinalities specify how many of each entity type is allowed
Attribute symbols
10
Entity Person: EMPLOYEE, STUDENT Place: WAREHOUSE, COUNTRY Object: BUILDING, MACHINE Event: SALE, REGISTRATION Concept: ACCOUNT, COURSE
EMPLOYEE DEPENDENT
Strong entity Weak entityAssociative entity
CERTIFICATE
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
Inappropriate entities
System userSystem user System outputSystem output
Appropriate entities
Figure 3-4
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
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
16
Figure 3-8 – Entity with a multivalued attribute (Skill) and derived attribute (Years_Employed)
Derived from date employed and current date
Multivalued: an employee can have more than one skill
17
Figure 3-19 – An attribute that is both multivalued and composite
This is an example of time-stamping.More examples?
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
19
Figure 3-9a Simple key attribute
The key is underlined
20
Figure 3-9b Composite key attribute
Flight_Number Date
21
Guidelines for Identifiers
Will not change in value Will not be null Substitute new, simple keys for long,
composite keys ? Game_Number
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
The relationship type is modeled as the diamond and lines between entity types
attribute of the relationship
24
Relationship Instance is between specific entity instances
25
One entity related to another of the same entity type
Entities of two different types related to each other Entities of three
different types related to each other
Degree of a relationship is the number of entity types that
participate in it
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
28
29Note: a relationship can have attributes of its own
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
31
Cardinalities
Mandatory one
Mandatory many
Optional one
Optional many
11
18
32
Figure 3-16a Basic relationship
Mandatory minimum cardinalities – Figure 3-17a
33
Figure 3-17cOptional cardinalities with unary degree, one-to-one relationship
34
max cardinality constraint
Maximum Cardinality Constraint
35
Entities can be related to one another in more than one way
36
Attributes can be transformed to relationships
Attributes or Relationship?
37
Attributes should be transformed to relationships
Attributes or Relationship?
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
39Figure 3-11b – An associative entity (CERTIFICATE)
40
Bill of materials structure
41
Figure 3-18 – Ternary relationship as an associative entity
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 Weak entityIdentifying relationship
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
Relationship degrees specify number of entity types involved
Entity symbols
A special entity that is also a relationship
Relationship symbols
Relationship cardinalities specify how many of each entity type is allowed
Attribute symbols
47
Sample E-R Diagram (Figure 3-1)
Supplier_ID
Supplier_Name
Supplier_Address
Attribute
Recommended