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

Relational database table

Marge Hohly

SQL to retrieve information

Structured query language (SQL)
used to access information
English-like phrases
Example:
SELECT last_name, department_id
FROM employees
WHERE employee_id = 200;

Marge Hohly

Results of SQL statement

Marge Hohly

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

Marge Hohly

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 cant be NULL

Marge Hohly

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

Column integrity
Contain values consistent with data
format of column
Column Name

Data Type

Optionality

BANK_NO

Number (5)

Not null

ACCT_NO

Number (8)

Not null

BALANCE

Number (12,2)

Not null

DATE_OPENED

Date

Marge Hohly

10

Summary Data-Integrity Rules

Marge Hohly

11

Data-Integrity Summary

Marge Hohly

12

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

13

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.
(next slide)

Marge Hohly

14

Example

Marge Hohly

15

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

16

JOBS Table

Marge Hohly

17

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

18

Review 12.2.3

Marge Hohly

19

Conceptual becomes Physical

model
Conceptional
becomes Physical
model

Marge Hohly

20

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

21

Short Name Example

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

22

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

23

Cascade barred relationships

UID from parent entity becomes part
of the UID of the child entity

Marge Hohly

24

Relationship mapping
Relationships are mapped to foreign
keys (at the many end)
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

25

Relationship mapping
1:M mapping
Foreign key goes in
table at crows 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

26

Relationship mapping
FK is mandatory from this diagram

FK is optional from this diagram

Marge Hohly

27

Enforcing Optionality
Optional or
Mandatory
determined by
crows foot end of
relationship

Marge Hohly

28

NonTransferable Relationship
Transferablility is a procedural model
Must be implemented by a program
Need to document this
constraint/business rule

Marge Hohly

29

Barred Relationship
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

30

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

31

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

32

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

33

Review
FK

1:M

*
o

PK, FK in same key,

rename one
M:M first resolve with an intersection
entity
Marge Hohly

34

Review cont.
Will be part of PK a composite key
FK on mandatory side

FK on either side

Marge Hohly

35

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 one of the Arc can be valid and
all others must be NULL
Mandatory relationship is enforced
with a check constraint
Marge Hohly

36

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

37

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

38

Subtype Review

Marge Hohly

39

Subtype mapping
Mapping supertypes and subtypes
makes sure that the right information
gets stored with each type.

Marge Hohly

40

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 optional.
Mandatory column to
distinguish between each
different subtypes of entity.

Marge Hohly

41

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

42

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

43

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

44

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

45

2-table cont.
A separate table
would be created
for SHIRTS and
SHOES.

Marge Hohly

46

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

47