1 CMPT 275 Phase: Design. Janice Regan, 2008 2 Map of design phase DESIGN HIGH LEVEL DESIGN Modularization User Interface Module Interfaces Data Persistance

1

CMPT 275

Phase: Design

Janice Regan, 2008 2

Map of design phaseDESIGN

HIGH LEVELDESIGN

Modularization

User Interface

Module Interfaces

Data PersistanceSubsystem

User Manual

architecture

LOW LEVELDESIGN

ClassesClass Interfaces

Interaction Diagrams

Implementation

3

Implementation issues related to Data Persistence

NORMALIZATION


Relational DB Design We will structure our relational database

table(s) using Normalization

process of assigning attributes to tables

series of stages called Normal Forms

1st normal form: fixed length records

2nd normal form: remove partial dependencies

3rd normal form: remove transitive dependencies


Relational DB Design

We will structure our relational database table(s) using Normalization

Advantage: assures equal length records

reduces data redundancies hence helps eliminate problems that result from redundancies

Disadvantage: decrease performance as we normalize to higher

forms, higher forms require more tables


An example… To illustrate how to normalize, we shall use

the example of a Student Registration System. Here are some requirements:

1. For each student, we need to remember: student-id, name, address, phone, courses

2. For each of the course taken, must remember: credit, semester, grade, room, instructor’s office, instructor.


An example… To illustrate how to normalize, we shall use

the example of a Student Registration System. Here are some requirements:

3. Students can repeat same course in a later semester

4. There is only one offering a a given course in a semester

5. For each of the course attempted, must remember: semester, grade, room, instructor, instructor's office


OO Classes: Class diagram

Student Course offering

Receives a grade for takes

Student ID

name

address

phone

Course namesemester

roomInstructor

Instructor’s officeList of courses List of students

0..* 0..*

Course

CourseName

credit

0..* 1

List of grades


Our First Table From our requirements, we could create the

following database table: (horizontal lines separate records, representing single student objects)

Instructor’s office

Std-id Std-name Std-address Std-phone Coursename Sem Grade Credit Room Instructor

15438

256364735221544

Paul K.

Will B.Kim L.Xiao T.

Brook St., Bby

Elf Ave., Van.Mer Cr., PocoAlpha St., Bby

294.2563

256.2453939.2766295.9976

Cmpt 101Cmpt 150Bus 152Engl 102Biol 234Cmpt 354

03-203-103-203-103-203-103-2

C-BA-A+B+DA-

4332333

AQ2AQ1ASBWMEDCAQ1AQ2

ASB985ASB352WM543AQ834EDC243ASB985ASB111

Dr. KlausM. NoleV. KaruW. LotiDr. QuelDr. KlausDr. Yu

Each record is uniquely identified by the student number (Std-id). The primary key for the table is therefore Std-id. This table is unnormalized (contains records of varying length)


So far, attributes are in an unnormalized form.

Objects, transformed into DB records, will not all be of same length. Each record contains all information about one student.

student-idnameaddressphonecoursecreditsemestergraderoominstructorinstructor’s office

Group of attributes repeated each time a particular course is attempted by 1 student

Group of attributes repeated for each course takenby 1 student

Our First Table: Is there a problem?

NOT ALL RECORDS ARE OF THE SAME LENGTH !!


What is the problem? Problem: attributes that are lists (multiple

courses per student, multiple attempts per course) do not produce fixed length records

Solution: remove lists by adding additional rows one to hold each attribute in the list

Consider the example: for a student, have 1 complete row per course attempted/taken

This results in a table in First Normal Form


First Normal Form Definition of First Normal Form (1NF):

Tables do not have repeating groups, i.e., each row/column intersection can contain one and only one value, not a set of values.

All the key attributes are defined, no blank (null) values of keys are permitted


Our example Defining primary key attributes Which attributes are needed to assure each

record is uniquely identified Std-Id is not enough

a student can take multiple courses

Std-id and course name is not enough a student can take the same course more than once

if they wish

Std-id, course name and semester is enough Each time the student takes a course it is uniquely

identified as a single record in the table


Std-phone

First Normal Form of Table (1NF)

Std-id Std-name Std-address Course-name Semester Grade Credit Room Instructor Instructor’s office

154381543815438256364735221544 21544

Paul K.Paul K.Paul K.Will B.Kim L.Xiao T.Xiao T.

Brook St., BbyBrook St., BbyBrook St., BbyElf Ave., Van.Merry Cr., PocoAlpha St., BBYAlpha St., Bby

294.2563294.2563294.2563256.2453939.2766295.9976295-9976

Cmpt 101Cmpt 150Bus 152Engl 102Biol 234Cmpt 354Cmpt 354

03-203-103-203-103-203-103-2

C-BA-A+B+DA-

4332333

AQ2AQ1ASBWMEDCAQ1AQ2

ASB985ASB352WM543AQ834EDC243ASB 985ASB111

Dr. KlausM. NoleV. KaruW. LotiDr. QuelDr. KlausDr. Yu

Result: Single table with compound (multi-attribute) primary key.

Primary Key: each row uniquely identified by one single attribute

Compound Primary Key: each row uniquely identify by a or group of attributes

The compound primary key for the above table is: Std-id, Course-name, Semester


Is there still a problem?

Yes! Our table in First Normal Form could still contain

data redundancies due to partial dependencies. Partial dependencies are based only on a part of

the compound primary key. Consider an attribute A, that is dependent on

the compound primary key K If A is dependent on all components of the compound

primary key the A is fully dependent on K If A is dependent on some but not all of the

components of the primary key then A is partially dependent on K


Redundancy: Examples + problems

Examples of redundancy and partial dependence: For each course a student takes the student’s

name, address and phone number are repeated. A student’s name and address are dependent on the student’s id but not on the course name or semester

For each course a student repeats the course credit is repeated. The course credit is dependent on the course name but not the student’s id or the semester


Problems related to Redundancy Redundancy

Insert anomalies: e.g. Each time a student takes a course the student information must be entered, this adds to the potential for error

Delete anomalies: if delete the row where info about Std-id 47352 is stored will also delete info that cannot be found anywhere else in DB table namely that Dr. Quel’s office is EDC243

Update problems: because of redundant data, if a student moves, need to change student's address in all rows corresponding to every instance of every course the student had ever taken. Problems occur if one occurrence is missed or an error is made in one occurrence


Partial Dependencies Definition: non-key attribute(s) dependent on

only some of primary key(s)

Examples: Phone #, Std-name, and address depend only on Std-

id (not course name or semester)

Credit depends only on course name (not on Std-id or semester)

Instructor, Instructor’s office, room, and grade depend on course and semester (not Std-id)


Partial Dependencies Definition: non-key attribute(s) dependent on

only some of primary key(s)

When an attribute is only partially dependent on the primary keys of the table there may be redundant occurrences of that attribute in the table

Therefore, To remove redundancies we should remove partial dependencies


Problem with 1NF non-key attribute(s) may depend on

some but not all of the primary key(s)

e.g.: primary keys are Std_id, Course-name and semester

address depends only on Std-id


From 1NF to 2NF Solution: Remove partial dependencies

Determine if there are any partial dependencies.

If so, divide 1NF table into several tables such that in each table each non-primary key attribute is dependent on only the primary key (or compound primary key) of that table.

Note that if primary key of 1NF table is not a compound primary key, there cannot be partial dependencies and hence the 1NF table is already in 2NF.


Second Normal Form - Example Transform our 1NF table into a 2NF table STEP 1: We determine dependencies on

single primary key: Std-id

Phone #, Std-name, Std-address Course-name

credit Semester

none dependent only on semester


2NF Example - Step 1

DB tables look like:

Std-id Std-name Std-address Std-phone

15438 Paul K. Brook St. Bby 294.2563

21544 Xiao T. Alpha St., Bby 295.9976

25636 Will B. Elf Ave., Van. 256.2453

Student Table

47352 Kim L. Merry Cr., Poco 939.2766

Course Table

Course-name credit

Cmpt 101 4

Cmpt 354 3

Engl 102 2

Bus 152 3

Cmpt 150 3

Biol 234 3


Second Normal Form - Example STEP 2: We determine dependencies on

pairs of primary keys:

Course-name + Semester

room, instructor, instructor’s office

Course-name + Std-id

none

Semester + Std-id

none


Course-name Semester Room Instructor Instructor’s office


Cmpt 101 03-2 AQ2 Dr. Klaus ASB985

Cmpt 150 03-1 AQ1 M. Nole ASB352

Bus 152 03-2 ASB V. Karu WM543

Engl 102 03-1 WM W. Loti AQ834

Course Offering Table

Biol 234 03-2 EDC Dr. Quel EDC243


Cmpt 354 03-2 AQ2 Dr. Yu ASB111


Second Normal Form - Example

Step 3

We determine dependencies on whole compound primary key:

Course-name + Semester + Std-id

grade



Student Registration Table

Std-id Course-name Semester Grade

154381543815438256364735221544 21544


03-203-103-203-103-203-103-2

C-BA-A+B+DA-


2NF Example, alternate Step 3-1Introducing Association Looking at the data model (class diagram), we can recognize

the “many-to-many” multiplicity relationship between Student, grade and CourseOffering


Receives a grade for takes

Student IDname

addressphone

Course namesemester

List of gradesroom

InstructorInstructor’s officeList of courses

List of students

Course

CourseNamecredit0..*0..*

0..* 1

These 3 attributes are used to implement “many-to-many” multiplicity relationships


Association Class However, this data model does not lead to DB

tables with records of fixed length because these 3 attributes are of varying size for each object of Student and Course Offering class types, so…

… we introduce yet another “class” that associates 1 student to many attempts at (registrations to) one course and 1 course to many attempts (registrations) per 1 student. For each of these attempts there is one grade


Association Class An association class takes a many-many relation

and breaks it into two 1-many relationships Student and Student Registration have a “1-to-many”

multiplicity relationship Course Offering and Student Registration have a “1-to-

many” multiplicity relationship

The association class will contain the attributes that are lists (that cause the many to may relationship)

The association class wil contain the attributes that depend upon all the variables (lists) in the association class.


2NF Example, alternate Step 3 - 2 This relationship can be broken down into 2 “1-

to-many” multiplicity relationships by creating an association class Student-Registration


Student IDname

addressphone

Course namesemester

roomInstructor

Instructor’s office

Course

CourseNamecredit0..*

1

Student Registration

Course namesemester

grade 0..*

Student ID

1

1

0..*


2NF Example, alternate Step 3 - 3 We can therefore store

the attributes that depend on this association into a Student Registration table. The compound primary key of this table is the union of the primary keys of the Student and the Course Offering tables:

C-BA-A+B+DA-



154381543815438256364735221544 21544


03-203-103-203-103-203-103-2



25636 Will B. Elf Ave., Van. 256.2453

Student Table


Course-name Semester Room Instructor Instructor’s office


Cmpt 150 03-1 AQ1 M. Nole ASB352

Bus 152 03-2 ASB V. Karu WM543

Engl 102 03-1 WM W. Loti AQ834


Biol 234 03-2 EDC Dr. Quel EDC243


Cmpt 354 03-2 AQ2 Dr. Yu ASB111

Course Table

Course-name credit

Cmpt 101 4

Cmpt 354 3

Engl 102 2

Bus 152 3

Cmpt 150 3

Biol 234 3


Second Normal Form

To get Student Registration System in 2NF we need 4 tables (files) Multiplicities come from our Requirement Analysis

phase

With this 2NF DB, students do not have to register to a course to be admitted to an institution

Room and instructor for a course offering can be entered even if there are no students registered yet

Less redundancy: Most update problems have been eliminated, but we can still have multiple occurrences of instructor and instructor’s office


Second Normal Form

Definition of 2NF:

The table is in 1NF

The table includes no partial dependencies


Is there still a problem?

Yes! Our tables in 2NF could still contains data

redundancies due to transitive dependencies.

When one non-primary key attribute is dependent on another non-primary key attribute, the second non-primary key attribute is transitively dependent on the first non-primary key attribute.


Transitive Dependencies: example instructor’s office (non-primary key attribute) is

transitively dependent on instructor (another non-primary key attribute) but not on any of the primary key attributes for that particular table (course and/or semester)

Solution: Conversion from 2NF to 3NF

Determine the transitive dependencies.

Split 2NF table containing the transitive dependency such that the dependency is represented by its own table.


3NF Example

C-BA-A+B+DA-



154381543815438256364735221544 21544


03-203-103-203-103-203-103-2



25636 Will B. Elf Ave., Van. 256.2453

Student Table


Course-name Semester Room Instructor

Cmpt 101 03-2 AQ2 Dr. Klaus

Cmpt 150 03-1 AQ1 M. Nole

Bus 152 03-2 ASB V. Karu

Engl 102 03-1 WM W. Loti


Biol 234 03-2 EDC Dr. Quel

Cmpt 354 03-1 AQ1 Dr. Klaus

Cmpt 354 03-2 AQ2 Dr. Yu

Course TableCourse-name credit

Cmpt 101 4

Cmpt 354 3

Engl 102 2

Bus 152 3

Cmpt 150 3

Biol 234 3

Dr. Klaus ASB985

W. Loti AQ834 Dr. Quel EDC243 Dr. Yu ASB111

M. Nole ASB352 V. Karu WM543

Instructor Instructor’s office

Instructor Table


Third Normal Form Definition:

Every table is in 2NF.

There are no transitive dependencies.


Normalization Summary When normalizing, we seek to make sure that

attributes depend on the key (1NF)

on the whole key (2NF)

on nothing but the key (3NF)

When normalized: records have fixed length

no insert/delete/update anomalies

minimize redundancy

Documents

1 CMPT 275 Phase: Design. Janice Regan, 2008 2 Map of design phase DESIGN HIGH LEVEL DESIGN Modularization User Interface Module Interfaces Data Persistance