Database Design Determinacy.

Slides:



Advertisements
Similar presentations
Relational Database. Relational database: a set of relations Relation: made up of 2 parts: − Schema : specifies the name of relations, plus name and type.
Advertisements

Normalisation The theory of Relational Database Design.
SQL Lecture 10 Inst: Haya Sammaneh. Example Instance of Students Relation  Cardinality = 3, degree = 5, all rows distinct.
ENTITY RELATIONSHIP MODELLING
Module 2 Designing a Logical Database Model. Module Overview Guidelines for Building a Logical Database Model Planning for OLTP Activity Evaluating Logical.
Entity/Relationship Modelling
Introduction to Schema Refinement. Different problems may arise when converting a relation into standard form They are Data redundancy Update Anomalies.
CS 380 Introduction to Database Systems (Chapter 5: The Relational Data Model and Relational Database Constraints)
Chapter 3 The Relational Model and Normalization
Module Title? DBMS E-R Model to Relational Model.
Week 6 Lecture Normalization
Functional Dependencies
THE RELATIONAL DATA MODEL CHAPTER 3 (6/E) CHAPTER 5 (5/E) 1.
Copyright, Harris Corporation & Ophir Frieder, Normal Forms “Why be normal?” - Author unknown Normal.
Logical Database Design ( 補 ) Unit 7 Logical Database Design ( 補 )
Normalization (Codd, 1972) Practical Information For Real World Database Design.
Concepts of Relational Databases. Fundamental Concepts Relational data model – A data model representing data in the form of tables Relations – A 2-dimensional.
Database Design (Normalizations) DCO11310 Database Systems and Design By Rose Chang.
1 n 1 n 1 1 n n Schema for part of a business application relational database.
Normalization Well structured relations and anomalies Normalization First normal form (1NF) Functional dependence Partial functional dependency Second.
CS370 Spring 2007 CS 370 Database Systems Lecture 4 Introduction to Database Design.
Entity-Relationship (ER) Modelling ER modelling - Identify entities - Identify relationships - Construct ER diagram - Collect attributes for entities &
Slide Chapter 5 The Relational Data Model and Relational Database Constraints.
Logical Database Design (1 of 3) John Ortiz Lecture 6Logical Database Design (1)2 Introduction  The logical design is a process of refining DB schema.
COMP1212 COMP1212 Anomalies and Dependencies Dr. Mabruk Ali.
Entity/Relationship Modelling. Entity Relationship Modelling In This Lecture Entity/Relationship models Entities and Attributes Relationships Attributes.
IST Database Normalization Todd Bacastow IST 210.
Lecture 4: Logical Database Design and the Relational Model 1.
NormalisationNormalisation Normalization is the technique of organizing data elements into records. Normalization is the technique of organizing data elements.
Database Normalization. What is Normalization Normalization allows us to organize data so that it: Normalization allows us to organize data so that it:
Lecture # 11 & 12 (First Exam) Chapter # 5 The Relational Data Model and Relational Database Constraints Database Systems.
Logical Design & the Relational Model
DATA MODELING AND DATABASE DESIGN
Entity/Relationship Modelling
CompSci 280 S Introduction to Software Development
Data Modeling Using the ERD
INLS 623 – Database Normalization
Case Studies: Data Modeling
Introduction to Databases by Dr. Soper extended with more examples
Normalization Karolina muszyńska
Database Normalization
Functional Dependencies
Constraints in Entity-Relationship Models
CPSC-310 Database Systems
Mr C Johnston ICT Teacher
Payroll Management System
Translation of ER-diagram into Relational Schema
Entity Relationship Diagram
The Entity-Relationship Model
Entity-Relationship Model and Diagrams (continued)
Introduction lecture1.
A SIMPLE GUIDE TO FIVE NORMAL FORMS (See the next slide for required reading) Prof. Ghandeharizadeh 2018/11/14.
Practice of ER modeling
Relational Database.
Database Fundamentals
Module 5: Overview of Normalization
Entity Relationship Diagrams
Cse 344 May 11th – Entities.
Chapter 14 Normalization.
The Relational Data Model and Relational Database Constraints
Normalisation to 3NF.
Database Normalization.
Chapter 4 The Relational Model and Normalization
Entity Relation Model Tingting Zhang.
Entity Relationship Model
Database.
CS 405G: Introduction to Database Systems
DATA MODELING AND DATABASE DESIGN
Extra ER LAB #2.
Presentation transcript:

Database Design Determinacy

The problem Considering the relation: {Sno,sdept,mn,courseNo,grade} One student belongs to one department One department has one manager Students to courses are many to many One grade for a student taking a class

Considering these actions: Updating a manager……how much work we should do? Inserting a course when a dept. is just formed and no student ….can we insert? When all the students have graduated…and what is left??

Anomalies Update anomalies -  changing information in one tuple leaves the same information unchanged in another; occurs with redundancy. Deletion anomalies - if a set of values becomes empty, we may lose other information as a side effect. Insertion anomalies - inability to represent certain information.

How can we avoid these? Remove redundant Restructure the database schema How? By Normalization! But before that, we need to know about the concept of determinancy

Determinancy Diagramming Technique Simple Determinancy Complex Determinancy

Consider a collection of attributes Determinancy Consider a collection of attributes Name, Student ID, Age, Course Name, Course Code Certain attributes can be used to uniquely determine one value of another attribute.

Name SID CName CCode Age Smith 1345 BSc Comp COM217 33 Jones 234 BSc SE COM328 19 Chen 5234 Aboud 2623 2678 22

Of these attributes: SID determines Name. e.g. 234 -> Jones SID determines CName. e.g. 5234 -> BSc Comp SID determines CCode. e.g. 2678 -> COM217 SID determines Age e.g. 234 -> 19 CName determines CCode e.g.BSc Comp -> COM217 CCode determines CName e.g. COM217 -> BSc Comp

BUT Age doesn’t determine anything Name doesn’t determine anything Defn: A is a determinant of B if each value of A has precisely one (possibly null) value of B associated with it. We say, A determine B or B is functionally dependent on A

In fact using the earlier table we could find the In fact using the earlier table we could find the determinants by inspection. BUT NOT ALWAYS! MORE IMPORTANTLY We can find the determinants by considering the enterprise rules for the attributes.

Each course name has exactly one course code. Each course code has exactly one course name. Each student ID is issued to one student. Each name may be associated with several student ids.

Examples: In the University each lecturer has one phone number. Each phone number may be associated with many lecturers (e.g. shared offices, communal phones). Lecturer# DETERMINES phone# Phone# DOESN’T DETERMINE lecturer#

Dog# determines owner# Owner# doesn’t determine dog# Each dog owner may own several dogs. Each dog is owned by one owner (assuming no group owners) Dog# determines owner# Owner# doesn’t determine dog#

Each employee has one national insurance number. Each national Each employee has one national insurance number. Each national insurance number is allocated to exactly one employee. Employee# determines national insurance number National insurance number determines employee#

Car# doesn’t determine driver# Driver# doesn’t determine car# Each employee may drive several different cars from the car pool. Each car in the car pool may be driven by several drivers at different times. Car# doesn’t determine driver# Driver# doesn’t determine car# In practice we don’t summarise the “doesn’t determine” lines.

We can produce a simple diagram which shows the determinancy We can produce a simple diagram which shows the determinancy. AB A determines B : A B

Lecturer# DETERMINES phone# Examples Lecturer# DETERMINES phone# Phone# DOESN’T DETERMINE lecturer#lecturer#phone# lecturer# phone#

Dog# determines owner# Owner# doesn’t determine dog# dog# owner#

Employee# determines national insurance number National insurance number determines employee# employee# national ins. number

Car# doesn’t determine driver# Driver# doesn’t determine car# car#

Composite Determinants. Several attribute values taken together can determine the value of some other attribute. Example In the Car, Driver example earlier, include an attribute number_of_times. The number of times a specific driver has driven a specific car.

Enterprise rules Driver can have several number_of_times. Car can have several number_of_times. Driver AND Car has one number_of_times. Gives (Driver, Car) determines number_of_times

Try the same for student#, module# and grade. Car# number_of_times driver# Question: Try the same for student#, module# and grade. Each student has a grade for each module they take.

Interpreting and producing diagrams. What does this determinancy diagram represent? Warehouse# quantity in stock part# re-order-level

How does it differ from this diagram? Warehouse# quantity in stock part# re-order-level

Exercises: Produce a determinancy diagram for the Name, Student ID, Course Name, Course Code and Age attributes used earlier.

More exercises a) Each student is given a unique student identifier. Each student is enrolled on exactly one course, but each course has several students. Each course consists of several modules.

b) A company has several cars for rent b) A company has several cars for rent. They can be rented to any valid driver who has a driving license. The name, address and license number of each driver are to be stored along with the day and date on which they rented the car. A driver can rent any available car.

c) A company has several warehouses each identified by its postcode c) A company has several warehouses each identified by its postcode. Each warehouse has storage space allocated to several items. Each type of item has a unique location within a specific warehouse. Each item has a unique serial number, and all items of the same type are stored in the same location.