Download Database Design Process IT420: Database Management and Organization

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Entity–attribute–value model wikipedia , lookup

Extensible Storage Engine wikipedia , lookup

Relational model wikipedia , lookup

Database model wikipedia , lookup

Transcript
IT420: Database Management and
Organization
Entity-Relationship Model to Relational Model
20 January 2006
Adina Crăiniceanu
www.cs.usna.edu/~adina
1
Database Design Process
ƒ Requirements analysis
ƒ Conceptual design: Entity-Relationship
Model
ƒ Logical design: transform ER model into
relational schema
ƒ Schema refinement: Normalization
ƒ Physical tuning
2
Goals
ƒ Transform ER model to relational model
3
1
ER Model - Entities
ƒ Attributes
ƒ Identifiers: no two
instances with the same
value for identifier
ƒ Weak entity: its existence
depends on another
entity
ƒ ID-Dependent entity:
weak + identifier contains
another identifier
4
ER Model - Relationships
ƒ HAS-A
ƒ Maximum cardinality
ƒ Minimum cardinality
ƒ IS-A (super-type/sub-type)
ƒ Exclusive/inclusive
5
Relational Model
ƒ Tables
ƒ Integrity constraints
ƒ Primary key
ƒ Candidate key
ƒ Foreign key
6
2
ER to Relational
ƒ Transform entities in tables
ƒ Transform relationships using foreign keys
ƒ Specify logic for enforcing minimum
cardinalities
7
Create a Table for Each Entity
EMPLOYEE (EmployeeNumber, EmployeeName, Phone,
Email, HireDate, ReviewDate, EmpCode)
Primary key is
designated by
key symbol
Note
shadowless
table
8
Select the Primary Key
ƒ The ideal primary key
is short, numeric and
fixed
ƒ Surrogate keys meet
the ideal, but have no
meaning to users
9
3
Specify Candidate (Alternate) Keys
ƒ candidate key = alternate key
ƒ Candidate keys: alternate identifiers of
unique rows in a table
ƒ ERwin uses AKn.m notation, where n is
the number of the alternate key, and m is
the column number in that alternate key
10
Specify Candidate (Alternate) Keys
11
Specify Column Properties:
Data Type
ƒ Generic Data Types:
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
CHAR(n)
VARCHAR(n)
DATE
TIME
MONEY
INTEGER
DECIMAL
12
4
Specify Column Properties:
SQL Server Data Types
13
Specify Column Properties:
Oracle Data Types
14
Specify Column Properties:
Null Status
ƒ Null status indicates
whether or not the
value of the column
can be NULL
15
5
Specify Column Properties:
Default Value
ƒ A default value is the value supplied by the
DBMS when a new row is created
16
Specify Column Properties:
Data Constraints
ƒ Data constraints are limitations on data values:
ƒ Domain constraint - Column values must be in a
given set of specific values
ƒ Range constraint - Column values must be within a
given range of values
ƒ Intra-relation constraint – Column values are limited
by comparison to values in other columns in the same
table
ƒ Inter-relation constraint - Column values are limited
by comparison to values in other columns in other
tables
17
Create Relationships:
1:1 Strong Entity Relationships
ƒ Place the key of one entity in the other
entity as a foreign key:
ƒ Either design will work – no parent, no child
ƒ Minimum cardinality considerations may be
important:
ƒ O-M will require a different design that M-O
18
6
Create Relationships:
1:1 Strong Entity Relationships
19
Create Relationships:
1:N Strong Entity Relationships
ƒ “Place the key of the parent in the child”
20
Create Relationships:
1:N Strong Entity Relationships
21
7
Create Relationships:
N:M Strong Entity Relationships
ƒ In an N:M strong entity relationship there is no
place for the foreign key in either table:
ƒ A COMPANY may supply many PARTs
ƒ A PART may be supplied by many COMPANYs
22
Create Relationships:
N:M Strong Entity Relationships
ƒ Create an intersection table:
ƒ The primary keys of each table Æ composite
primary key for intersection table
ƒ Each table’s primary key becomes a
foreign key linking back to that table
23
Create Relationships:
N:M Strong Entity Relationships
COMPANY_PART_INT (CompanyName, PartNumber)
24
8
Relationships Using ID-Dependent Entities:
Four Uses for ID-Dependent Entities
ƒ Representing N:M Relationships
ƒ We just discussed this
ƒ Association Relationships
ƒ Multivalued Attributes
ƒ Archtype/Instance Relationships
25
Relationships Using ID-Dependent Entities:
Association Relationships
ƒ An intersection table:
ƒ Holds the relationships between two strong entities in
an N:M relationship
ƒ Contains only the primary keys of the two entities:
ƒ As a composite primary key
ƒ As foreign keys
ƒ An association table:
ƒ Has all the characteristics of an intersection table
ƒ PLUS it has one or more columns of attributes
specific to the associations of the other two entities
26
Relationships Using ID-Dependent Entities:
Association Relationships
QUOTATION (CompanyName, PartNumber, Price)
27
9
Relationships Using ID-Dependent Entities:
Multivalued Attributes
ER
model
28
Relationships Using ID-Dependent Entities:
Multivalued Attributes
ER
model
As a set
of tables
29
Relationships Using ID-Dependent Entities:
Archetype/Instance Pattern
As a
data
model
30
10
Relationships Using ID-Dependent Entities:
Archetype/Instance Pattern
As a
data
model
As a set
of tables
31
Relationships Using Weak Entities:
Archetype/Instance Pattern
As a
data
model
32
Relationships Using Weak Entities:
Archetype/Instance Pattern
As a
data
model
As a set
of tables
33
11
Mixed Entity Relationships:
The Line-Item Pattern
As a
data
model
34
Mixed Entity Relationships:
The Line-Item Pattern
As a set
of tables
35
Subtype Relationships
As a
data
model
36
12
Subtype Relationships
As a
data
model
As a set
of tables
37
Recursive Relationships:
1:1 Recursive Relationships
As a
data
model
As a
table
38
Recursive Relationships:
1:1 Recursive Relationships
As a
data
model
39
13
Recursive Relationships:
1:N Recursive Relationships
As a
data
model
As a
table
40
Recursive Relationships:
N:M Recursive Relationships
As a
data
model
41
Recursive Relationships:
N:M Recursive Relationships
As a
data
model
As a set
of tables
42
14
Minimum cardinality:
Parent Required
DEPARTMENT (DepartmentName, BudgetCode, ManagerName)
EMPLOYEE
(EmployeeNumber, EmployeeName,
DepartmentName)
ƒ On Insert: child OK
ƒ On Delete:
ƒ delete child (cascade) or prohibit
ƒ On Update:
ƒ update child (cascade) or prohibit
43
Minimum cardinality:
Child Required
ƒ More difficult to enforce (write code)
DEPARTMENT (DepartmentName, BudgetCode, ManagerName)
EMPLOYEE
(EmployeeNumber, EmployeeName,
DepartmentName)
ƒ Tricky:
ƒ A department must have some employee
ƒ EMPLOYEE has DepartmentName as FK,
NOT NULL
44
15