Professional Documents
Culture Documents
IELM 511: Information System Design: Part 1. ISD For Well Structured Data - Relational and Other DBMS
IELM 511: Information System Design: Part 1. ISD For Well Structured Data - Relational and Other DBMS
IELM 511: Information System Design: Part 1. ISD For Well Structured Data - Relational and Other DBMS
Introduction
Part 1. ISD for well structured data – relational and other DBMS
Info storage (modeling, normalization)
Info retrieval (Relational algebra, Calculus, SQL)
DB integrated API’s
Relational design
Customers are identified by their SSN (equiv to HKID). The bank stores each customer’s name
and address. Customers may have accounts, and can take out loans. A customer may be associated
with a particular banker, who may act as a loan officer of personal banker for that customer.
Bank employees are also identified by SSN. The bank stores the Name, address, phone #, start day
of employment of each employee, the name of all dependents of the employee, and the manager of
the employee.
The bank offers two types of accounts: savings and checking. Accounts can be held by more than
one customer, and a customer may have many accounts. Each account has a unique account
number. We store each account’s balance, and the most recent date when the account was accessed
by each customer holding the account. Each savings account has an interest rate, and overdrafts
are recorded for each checking account.
A loan originates art a particular branch, and is held by one or more customers. Each loan has a
unique number. For each loan, the bank stores the loan amount and the payments (date and
amount) . Payment numbers are not unique, but a payment number uniquely identifies a payment
for a specific loan.
(Recap) Bank ER
1
n
n 1 n
m
n m
n
1 1
n
Agenda
Relational design
A. Domain constraints
B. Key constraints
minimal:
removal of any attribute from Key
no longer a Superkey of R
Constraints on tables..
K1 = { State, LicensePlateNo}
K1 is a minimal Superkey Key
K3 = { VehicleID, Manufacturer}
Superkey ?
Key ?
Constraints on tables...
D. Referential constraints
- All referential constraints must be defined
- X(Ai) references Y(Bj) dom(Ai) = dom(Bj)
- Foreign Key attributes that reference a Primary Key
Foreign Key examples
EMPLOYEE SSN Name StartDate TelNo MgrSSN
FK
FK
CUSTOMER SSN Name Address BankerSSN
Converting ER into Relational tables
1. For each regular entity, E,
One table E with all the simple attributes of E.
Select a primary key for E, and mark it.
6. Specializations*
n
SACCOUNT( ac-no, int-rate, ….) 1 1
n
n
SACCOUNT( ac-no, int-rate, ….) 1 1
n
n
BORROWS( cust-ssn, loan-num, ….) 1 1
n
OR
NOTATION: X Y
X Y implies that
for any two tuples, t1 and t2,
if t1[X] = t2[X], then t1[ Y] = t2[ Y]
Examples:
0402 Jane Doe Fall 05 ie110, ie317 0402 Doe Jane Fall 05 ie110
0402 Doe Jane Fall 05 ie317
Projects
SSN Lname Fname ProjNo Hours
P1 10 Not 1NF
1123 Smith John
P2 5
P2 10
3312 Doe Jane
P3 5
EMPLOYEE EMP_PROJECTS
Prime Attribute:
An attribute that is a member of the primary key
3. General 3NF:
Notice our definition of 3NF depends on our selection of a PK.
If a table has multiple choices of PK’s, then further problems may arise
However, in practical cases, such issues are rare and outside our scope.
References and Further Reading