Download DDLesson11Fa10

Database Design
Sections 11
Database relationship, Integrity, keys,
mapping conceptual model to
logical/physical model
Relational database concepts
 Discuss
 Primary keys
 Foreign keys
 Data integrity
 Physical mapping & transition to SQL
 Entity = table
 Attribute = column
Marge Hohly
2
Relational database table
Marge Hohly
3
SQL to retrieve information
 Structured query language (SQL)
used to access information
 English-like phrases
 Example:
SELECT lname, dept_no
FROM employees
WHERE emp_no = 210;
Marge Hohly
4
Results of SQL statement
Marge Hohly
5
Primary Key
 Primary Key (PK)
 Column or set of columns that uniquely identifies
each row in a table
 Employee ID in Employee table (single unique)
 Bank ID & Account ID in Accounts table (composite)






Every table has a Primary key
not null
no part of PK can be null (entity integrity)
unique
can be composite
Candidate key (column that can be considered for a
Primary key)
Marge Hohly
6
Foreign Key
 Foreign Key (FK)




depends on business rule
comes from relationship
primary key from another table
If FK is part of a PK, then the FK can’t be NULL
Marge Hohly
7
Key questions
 what makes emp_no and payroll_id
good candidates for the primary key?
 why is having alternate or unique
keys useful?
Marge Hohly
8
Column integrity
 Contain values consistent with data
format of column
Marge Hohly
9
Summary Data-Integrity Rules
Marge Hohly
10
Data-Integrity Summary
Marge Hohly
11
Data-Integrity Summary
 Entity integrity- no part of PK can be NULL
 Referential integrity – FK must match an
existing PK value (or else be NULL)
 Column integrity – column must contain
only values consistent with defined data
format
 User-defined integrity – data stored in
database must comply with the rules of the
business
Marge Hohly
12
Referential Integrity
 Use Foreign Key to map relationships
 A foreign key (FK) is a column or
combination of columns in one table
that refers to a primary key in the
same table or another table.
 11.4.10 (next slide)
Marge Hohly
13
11.4.10
Marge Hohly
14
Composite key
 Made up of two or more values
 Together unique
 ENROLL Table/Entity
 student_no & ticket_no
 ACCOUNTS
 bank_no & acct_no
Marge Hohly
15
JOBS Table
Marge Hohly
16
Transformation
 Conceptual model, focus on the
business and its rules.
 Data modeling pays attention to the
business requirements, regardless of
implementation.
 Conceptual model
Logical model
Marge Hohly
17
Review 12.2.3
Marge Hohly
18
Conceptual becomes Physical
model
 Conceptional
becomes Physical
model
Marge Hohly
19
Terminology Mapping






- An entity leads to a table.
- An attribute becomes a column.
- A primary unique identifier
produces a primary key.
- A secondary unique identifier
produces a unique Key.
- A relationship is transformed
into a foreign key and foreign-key
columns.
- Constraints are the rules that
the database must follow to be
consistent. Some of the business
rules are translated into check
constraints; other more complex
ones require additional
programming in the database or
the application.
Marge Hohly
20
12.2.8















For entity names of more than one word,
take the:
- First character of the first word
- First character of the second word
- Last character of the last word
Example: JOB ASSIGNMENT gets a short
name of JAT
For entity names of one word but more than
one syllable, take the:
- First characer of the first syllable
- First character of the second syllable
- Last character of the last syllable
Example: EMPLOYEE gets a short name of
EPE
For entity names of one syllable but more
than one character:
- First character
- Second character
- Last character
Example: FLIGHT gets a short name of FLT
Marge Hohly
21
Naming restrictions with Oracle
 Table and column names:
 must start with a letter
 can contain up to 30 alphanumeric
characters
 cannot contain space or special characters
such as “!,” but “$,” “#,” and “-“ are
permitted
 Table names must be unique.
 Column names must be unique within a
table.
 Avoid “reserved” words in tables and
columns.
Marge Hohly
22
Cascade barred relationships
 UID from parent entity becomes part
of the UID of the child entity
Marge Hohly
23
Relationship mapping
 Relationships are mapped to foreign
keys
 Foreign keys enable users to access
related information from other tables.
 Mapping relationships to relational
database structures is part of creating
the “first-cut” database design.
Marge Hohly
24
Relationship mapping
 1:M mapping
 Foreign key goes in
table at crow’s foot
from parent
 FK1 Dept_id
mandatory is required
 FK2 might be better
mgn_id and is optional
 Does the president of
the company have a
manager?
Marge Hohly
25
Relationship mapping
 FK is mandatory from this diagram
 FK is optional from this diagram
Marge Hohly
26
12.3.4
 Optional or
Mandatory
determined by
crow’s foot end of
relationship
Marge Hohly
27
NonTransferable Relationship
 Transferablility is a procedural model
 Must be implemented by a program
 Need to document this
constraint/business rule
Marge Hohly
28
Barred Relationship
 12.3.6
 Barred relationship is mapped to a
foreign-key column on the many side,
just like any other M:1 relationship.
 Bar means it becomes part of the
composite primary key of the child
 ACCOUNT table has both acct_id and
bank_id as the composite primary
key
Marge Hohly
29
Cascading barred relationships
 Pick up one more
component to the
composite key with
each level
 Company –
company_id
 Division
company_id & div_id
 Department
company_id, div_id &
dept_no
 Team
team_id, company_id,
div_id & dept_no
Marge Hohly
TEAM
within
made up of
DEPARTMENT
within
made up of
DIVISION
within
made up of
COMPANY
30
M:M relationship mapping
 M:M resolved with
intersection entity
 Intersection entity
has a composite
key with the PK
from each parent
as FK in child
Marge Hohly
31
1:1 relationship mapping
 Create a foreign key and a unique
key
 If relationship mandatory on one
side, Foreign key created on the
mandatory side as a unique key
 If optional on both sides, you can
choose which table gets the foreign
key.
Marge Hohly
32
Review
 FK
1:M
*
o

PK, FK in same key,
rename one
 M:M first resolve with an intersection
entity
Marge Hohly
33
Review cont.
 Will be part of PK a composite key
 FK on mandatory side
 FK on either side
Marge Hohly
34
Arc mapping
 Foreign key from the parent (single)
side are placed in the child (many)
side
 The Foreign key is ALWAYS Optional
in the child
 Only of the Arc can be valid and all
others must be NULL
 Mandatory relationship is enforced
with a check constraint
Marge Hohly
35
Arc constraint
 You need a constraint to make sure
only one is NOT NULL at a time
 Example: FK1, FK2, FK3, ....
 ALTER EVENT constraint (FK1 is not
null and FK2 is null and FK3 is null
....) OR (FK1 is null and FK2 is not
null and FK3 is null ....) OR (FK1 is
null and FK2 is null and FK3 is not
null ....)
Marge Hohly
36
ARC mapping
 If mandatory then one MUST be NOT
NULL
 If optional then all may be NOT NULL
 You will always need a check
constraint defined
Marge Hohly
37
Subtype Review
Marge Hohly
38
Subtype mapping
 Mapping supertypes and subtypes
makes sure that the right information
gets stored with each type.
Marge Hohly
39
Subtype modeling


Mapping as a single table
Rules




Tables: Only one table is
created, independent of the
number of subtypes.
Columns: The single table
gets a column for all the
attributes of the supertype,
with the original optionality.
Table gets a column for each
attribute of the subtype, but
column are.
Mandatory column to
distinguish between each
different subtypes of entity.
Marge Hohly
40
Subtype modeling – Single table
cont.
 Rules
 Identifiers: Unique identifiers transform into
primary and unique keys.
 Relationships: Relationships at the supertype
level transform as usual. Relationships at
subtype level are implemented as optional
foreign-key columns.
 Integrity constraints: A check constraint is
needed to ensure that for each particular
subtype, all columns that come from mandatory
attributes are not null.
Marge Hohly
41
Subtype model – Single table
 Note mandatory
attributes salary/hourly
rate became optional
 Need check constraint to
enforce mandatory
requirement

CHECK (epe_type =
‘FTE’ and salary is not
null and hourly_rate is
null and agy_id is null)
OR (epe_type ‘PTE’ and
salary is null and
hourly_rate is not null
and agy_id is not null)
Marge Hohly
42
When Supertype/Single table
 The single-table implementation is
common and flexible implementation.
 Appropriate where:
 Most attributes are at supertype level
 Most relationships are at supertype level
 Business rules are globally the same for
the subtypes
Marge Hohly
43
Two-Table implementation


Create a table for each subtype
Rules




Tables: One table per first-level
subtype.
Columns: Each table gets a column for
all attributes of the supertype with the
original optionality.
Each table also gets a column for each
attribute belonging to the subtype, also
with the original optionality.
Identifiers: The primary UID at the
supertype level creates a primary key
for each table. Secondary UIDs of the
supertype become unique keys in each
table.
Relationships: All tables get a foreign
key for a relationship at the supertype
level, with the original optionality. For
relationships at the subtype levels, the
foreign key is implemented in the table
it is mapped to. Original optionality is
retained.
Marge Hohly
44
2-table cont.
 A separate table
would be created
for SHIRTS and
SHOES.
Marge Hohly
45
Subtype Considerations
 Subtype implementation may be
appropriate when:
 Subtypes have very little in common. There are
few attributes at the supertype level and several
at the subtype level.
 Most of the relationships are at the subtype
level.
 Business rules and functionality are quite
different between subtypes.
 How tables are used is different -- for example,
one table is being queried while the other is
being updated.
Marge Hohly
46