er-diagram into relational db designeecs.csuohio.edu/~sschung/cis430... · 2017-02-04 ·...
TRANSCRIPT
Process of Database Design
• Logical Design
– Based upon the conceptual data model
– Four key steps
1. Develop a logical data model for each known user
interface for the application using normalization
principles.
2. Combine normalized data requirements from all user
interfaces into one consolidated logical database model
3. Translate the conceptual E-R data model for the
application into normalized data requirements
4. Compare the consolidated logical database design with
the translated E-R model and produce one final logical
database model for the application9.59.5
Relational Database Model• Data represented as a set of related tables or
relations
• Relation
– A named, two-dimensional table of data. Each
relation consists of a set of named columns and
an arbitrary number of unnamed rows
– Properties
• Entries in cells are simple
• Entries in columns are from the same set of values
• Each row is unique
• The sequence of columns can be interchanged without
changing the meaning or use of the relation
• The rows may be interchanged or stored in any
sequence9.79.7
Relational Database Model
• Well-Structured Relation
– A relation that contains a minimum
amount of redundancy and allows users
to insert, modify and delete the rows
without errors or inconsistencies
9.89.8
Transforming E-R Diagrams into Relations
• It is useful to transform the conceptual data
model into a set of normalized relations
• Steps
1. Represent entities
2. Represent relationships
3. Normalize the relations
4. Merge the relations
9.99.9
Refining the ER Design for the COMPANY Database
� Change attributes that represent
relationships into relationship types
� Determine cardinality ratio and
participation constraint of each
relationship type
Design Choices for ER Conceptual Design
� Model concept first as an attribute
� Refined into a relationship if attribute is a
reference to another entity type
� Attribute that exists in several entity
types may be elevated to an independent
entity type
� Can also be applied in the inverse
Attributes
• An entity is represented by a set of attributes, that is descriptive properties possessed by all members of an entity set.
• Domain – the set of permitted values for each attribute
Example:
Customer = (customer-id, customer-name, customer-street, customer-city)
Loan = (loan-number, amount)
Attributes
• Multivalued (Set Valued) attributes: Attributes
that have many values and require creating:
– Several new attributes, one for each component of
the original multivalued attribute
– A new entity composed of the original multivalued
attribute’s components
• Derived attribute: Attribute whose value is
calculated from other attributes
– Derived using an algorithm
14
Multivalued Attributes
• Normalization Required toFirst Nomal Form
• A multivalued attribute M of an entity E is represented by a separate table EM– Table EM has attributes corresponding to
the primary key of E and an attribute corresponding to multivalued attribute M
– Eg: Create Dept_Location table from Department tableDept_Location( Dnumber, Dlocation)
Multivalued Attributes
– E.g. Multivalued attribute dependent-namesof employee is represented by a table
employee-dependent-names( employee-id, dname)
– Each value of the multivalued attribute maps to a separate row of the table EM• E.g., an employee entity with primary key John
and dependents Johnson and Johndotir maps to two rows:
(John, Johnson) and (John, Johndotir)
Transforming Composite Attribute
• Flatten the Structure to One Attribute
eg: Address of Employee Table
• Flatten the Structure to Multiple
Attributes
eg: Name � Lname, MI, Fname of
Employee Table
• Making the Composite attribute into
Separate Table
Transforming Composite Attribute 3
• Making a Composite Attribute into Separate
Table Customer_Address
Customer_Address
(Customer_Id, Street_Number, Street_Name,
Apt_Num, City, State, Zip, Country)
• More Query Power for Data Analytic on Address
• No Need to Access Big Customer Table for Address
Analytics
• Required Join with Address Table and Customer Table for
other Customer Information
Alternative Notations for ER Diagrams
� Specify structural constraints on
Relationships
� Replaces Cardinality ratio (1:1, 1:N, M:N) and
single/double line notation for Participation
constraints
� Associate a pair of integer numbers (min, max)
with each participation of an entity type E in a
relationship type R, where 0 ≤ min ≤ max and
max ≥ 1
Cardinality Ratio(1:1, 1:N, M:N)
• 1:1 :Each dept has at
most one manager on
Manages.
Translation to
relational model?
Many-to-Many1-to-1 1-to Many Many-to-1
dname
budgetdid
since
lot
name
ssn
ManagesEmployees Departments1 1
Constraints on Binary Relationship Types
� Cardinality ratio for a binary relationship
� Specifies maximum number of relationship
instances that entity can participate in
� Participation Constraint
� Specifies whether existence of entity depends
on its being related to another entity
� Types: total and partial
Attributes of Relationship Types
� Attributes of 1:1 or 1:N relationship types
can be migrated to one entity type
� For a 1:N relationship type
� Relationship attribute can be migrated only to
entity type on N-side of relationship
� For M:N relationship types
� Some attributes may be determined by
combination of participating entities
� Must be specified as relationship attributes
Transforming E-R Diagrams into Relations
Represent Relationships
– Binary 1:N Relationships
• Add the Primary key attribute (or attributes) of
the entity on the one side of the relationship as a
Foreign key in the relation on the other (N) side
• The one side migrates to the many side
9.259.25
Binary 1 To 1 Relationship
Employee(Manager) MANAGES DepartmentEMPLOYEE
FNAME MINIT LNAME SSN BDATE ADDRESS SEX SALARY SUPERSSN DNO
John B Smith 123456789 09-Jan-55 731 Fondren, Houston, TX M 30000 987654321 5
Franklin T Wong 333445555 08-Dec-45 638 Voss, Houston, TX M 40000 888665555 5
Joyce A English 453453453 31-Jul-62 5631 Rice, Houston, TX F 25000 333445555 5
Ramesh K Narayan 666884444 15-Sep-52 975 Fire Oak, Humble, TX M 38000 333445555 5
James E Borg 888665555 10-Nov-27 450 Stone, Houston, TX M 55000 1
Jennifer S Wallace 987654321 20-Jun-31 291 Berry, Bellaire, TX F 43000 888665555 4
Ahmad V Jabbar 987987987 29-Mar-59 980 Dallas, Houston, TX M 25000 987654321 4
Alicia J Zelaya 999887777 19-Jul-58 3321 Castle, SPring, TX F 25000 987654321 4
DEPARTMENT
DNAME DNUMBER MGRSSN MGRSTARTDATE
Headquarters 1 888665555 19-Jun-71
Administration 4 987654321 01-Jan-85
Research 5 333445555 22-May-78
Automation 7 123456789 06-Oct-05
Transforming E-R Diagrams into Relations
Represent Relationships
– Binary and higher M:N relationships
• Create another relation and include
primary keys of all relations as primary
key of new relation
9.289.28
Association Class to TableORDER LINE
Order_Number
Product_ID
Quantity_Ordered
61384 M128 2
61384 A261 1
62807 A261 2
62807 R149 1
62009 R149 2
Transforming E-R Diagrams into Relations
– Unary 1:N Relationships
• Relationship between instances of a single entity type
• Utilize a recursive foreign key
– A foreign key in a relation that references the primary key
values of that same relation
– Unary M:N Relationships
• Create a separate relation
• Primary key of new relation is a composite of two attributes
that both take their values from the same primary key
9.319.31
Unary 1 to M to Table:MANAGES
Emp_ID Name Mgr_ID Birthdate
11111 John Smith 33333 12/30
22222 Jane Doe 33333 03/23
33333 Anne Hana 99999 05/05
44444 Nick Shaw 99999 11/23
99999 RonBirkman
07/20
Unary Association Class to Table:CONTAINS
ContainigItem_Number
ContainedItem_Number
Quantity_Contained
61384 M128 2
61384 A261 1
62807 A261 2
62807 R149 1
62009 R149 2
Item_Number
Name Cost
A261 Nail 0.99
61384 AAA 21.11
M128 Screw 2.99
62807 BBB 200.11
62009 CCC 99.00