Logical (Information Level) Design of Relational Databases

Logical Relational Design

• Purpose of logical data design is to represent application data in the form of related 2-dimensional relations. These will be used to create the tables in a relational database for the application.

• Details are obtained by analysing samples of a wide range of user views from the application.

User view• A user view is a view of the data presented

by the application to the user

• User views may include: input screen, output screen, input form, summary report, detailed report (most important type of user view is one that is used to input data)

• User view may be either an actual sample or a prototype

• User view should contain sample data

Information-Level Design (Book’s Approach)

• For each userview:– Represent the user view as a collection of tables.– Normalize these tables.– Identify all keys.– Merge the result of the previous steps into the

design.

Information Level Design Methodology

Methodology(Text’s) to analyse a single user view

• Steps taken to represent a user view as a collection of tables:1. Determine the entities involved and create a

separate table for each type.2. Determine the primary key for each of these

tables.3. Determine the attributes for each of these

entities.4. Normalize each table.5. Determine relationships among the entities.

Methodology(Formal) to analyse a single user view

• Steps taken to represent a user view as a collection of normalized relations:1. Identify and list all attributes for the user view as

a relation.2. Choose the most likely primary key for the

relation.3. Determine whether an attribute is single-valued

or repeats either individually or as part of a set of related attributes.

4. Normalize each relation.

Normalization

• Technique used to analyze data is called normalization.

• Applying the technique of normalization to as user view allows data presented in a complex form to be expressed in the form of 2 dimensional relations.

• These relations will become tables in the relational database for the application.

Normalization (ctd)

• The purpose of normalization is to have all data in a relation functionally dependent on the primary key of the relation (i.e. The value for each attribute can be determined by the whole key and nothing other than the key).

• Normalization requires that a primary key be identified for each relation.

Primary Key

• Try to use as a primary key the attribute(s) that best uniquely identifies the information

• A primary key may be an actual attribute (eg School Name) or more commonly may be an assigned value (eg Student Number, SIN)

Dependencies

• Depending on the primary key chosen for a relation the following dependencies may exist in a relation: multi-valued, partial, transitive and functional.

• A normalized relation can only contain functional dependencies.

• Normalization resolves multi-valued, partial and transitive dependencies.

Sample Userview: Class ListSection: DBS355A Subject Name: Intro to DB

Instructor No: 213 Instructor Name: Patricia Belvedere

Student No:111222333 Student Name: Joe Brown

Student No: 212121212 Student Name: Le Huang

Section: DBS355B Subject Name: Intro to DB

Instructor No: 222 Instructor Name: Libby Langer

Student No: 3232323232 Ella Zeltserman

Student No: 5555555555 Maria Ramirez

Sample User View: Class List

• To reduce the complexity of this example I am assuming that only one instructor is assigned to teach a section of a subject (although this is NOT true for summer semesters at our school!)

Unnormalized Class List Relation

• Relational Notation: • [ ] : contains list of attributes for relation• A, B : attribute or attributes that are the Primary

Key• { } : attribute or group of attributes that have more

than one value for a single value of the primary key

• CLASSLIST [ Subject Code, Section Code, Instructor No, Instructor Name, Subject Name, {Student Number, Student Name} ]

Multi-valued Dependency

• A multi-valued dependency (also known as a repeating group) is when a single value of the primary key determines 1 or more than one value of a non-key attribute; A ->> B

• For example Subject Code and Section Code as the primary key of the Class List relation determine more than one value of Student Number.

Partial Dependency

• A partial dependency is when only a part of a composite primary key determines the value of a non-key attribute;

• A, B -> C but actually B -> C• For example Subject Code and Section

Code together are the primary key for a section of a subject but Subject Code alone determines the value of Subject Name.

Transitive Dependency• A transitive (or indirect) dependency is when the

primary key determines the value of a non-key attribute that then determines the value of another non-key attribute; if A -> B, C but we can determine that B -> C then we can say A -> B and B -> C

• For example Subject Code and Section Code together are the primary key for a section of a subject and determine the value of Instructor No which then determines the name of the assigned instructor.

Normalization

• To normalize a relation we must identify and resolve all dependencies other than full functional dependencies by creating new relations.

• If in the unnormalized relation [A, B, {C, D,} E, F, G ] we know that F -> G (transitive) and that B -> E (partial) and that A,B ->> C, D then we will have as resulting normalized relations: [A, B, C, D ] ; [B, E] ; [A, B, F ] ; [F, G ]

Actual 3NF Relations for Class List

• [Subject Code, Subject Name ]

• [Instructor No, Instructor Name ]

• [Student Number, Student Name ]

• [Subject Code, Section Code, Instructor No]

• [Subject Code, Section Code, Student Number]