The Relational Database Model CST272. Return Creating the Unnormalized Table n List the fields n Select a primary key – The field (or concatenation of.

Slides:



Advertisements
Similar presentations
Normalisation.
Advertisements

Normalization Rules for Database Tables
A Normalisation Example
Six Blind Men and the Elephant. Basic ERD Symbology EntityRelationship AttributeMultivalued Attribute Associative Entity.
MS-Access XP Lesson 2. Input Mask Property 1.Field : Phone No Data Type : Number Input Mask : Character 0 represent a single digit and phone.
1 Class Agenda (04/03 and 04/08)  Review and discuss HW #8 answers  Present normalization process Enhance conceptual knowledge of database design. Improve.
Normalisation Ensuring data integrity in database design 1.
Announcements n No class on Thursday Time to get together with your group and work on the project n Office Hours this week: Today: 1:00 to 1:30 Wednesday:
Athabasca University Under Development for COMP 200 Gary Novokowsky
ISP 121 Access Normalization and Relationships. Normalization Say we’re operating a pet day-care and we need to keep information on our pets/customers.
Announcements n Difference between “excused” and “absent” n Office hours next week May not be here Monday Tuesday: 1:00 to 2:00 Wednesday: 10:00 to 11:00.
The Relational Database Model:
Designing a Database Unleashing the Power of Relational Database Design.
Project and Data Management Software
Data Model Examples USER SPECIFICATIONS.
ISI Request For Quote Integrates with Microsoft Dynamics GP Inventory, Purchase Order Processing and Sales Order Processing Dynamics is a registered trademark.
©2008 TTW Where “Lean” principles are considered common sense and are implemented with a passion! Product Training Sales Invoices.
Database Normalization CP3410 Daryle Niedermayer, I.S.P., PMP.
MIS2502: Data Analytics Relational Data Modeling
Normalization Rules for Database Tables Northern Arizona University College of Business Administration.
Introduction to Databases. Overview  What is a Database?  What is a Database Management System?  How is information organized in a database?  What.
Food Recall System Pre Code System Design Layout Version 1.0.
CREATE THE DIFFERENCE Normalisation (special thanks to Janet Francis for this presentation)
Relational Database Concepts. Let’s start with a simple example of a database application Assume that you want to keep track of your clients’ names, addresses,
1 Class Agenda (11/07 and 11/12)  Review HW #8 answers  Present normalization process Enhance conceptual knowledge of database design. Improve practical.
Microsoft Access Understanding Relationships Academic Health Center Training (352)
Database Management Relational Databases and Data Normalization By: Prof. Thomas G. Re Nassau Community College.
Relational databases and third normal form As always click on speaker notes under view when executing to get more information!
More on relational databases, including 1 to 1, 1 to many and many to many relationships Please use speaker notes for additional information!
Avoiding Database Anomalies
Normalization A technique that organizes data attributes (or fields) such that they are grouped to form stable, flexible and adaptive entities.
A Normalisation Example Mark Kelly McKinnon Secondary College Vceit.com Based on work by Robert Timmer-Arends.
Normalization (Codd, 1972) Practical Information For Real World Database Design.
Copyright Ó Oracle Corporation, All rights reserved. Normalization Use the student note section below for further explanation of the slide content.Use.
DAY 12: DATABASE CONCEPT Tazin Afrin September 26,
Copyright 2008 McGraw-Hill Ryerson 1 TECHNOLOGY PLUG-IN T5 DESIGNING DATABASE APPLICATIONS.
Normalization Information Systems II Ioan Despi. Informal approach Building a database structure : A process of examining the data which is useful & necessary.
Customer Order Order Number Date Cust ID Last Name First Name State Amount Tax Rate Product 1 ID Product 1 Description Product 1 Quantity Product 2 ID.
Constraints - primary and foreign keys in Oracle Please use speaker notes for additional information!
HSC IT Center Training University of Florida Microsoft Access Understanding Relationships Health Science Center IT Center – Training
ITN Table Normalization1 ITN 170 MySQL Database Programming Lecture 3 :Database Analysis and Design (III) Normalization.
Concepts of Database Management, Fifth Edition Chapter 6: Database Design 2: Design Methodology.
Quiz questions. 1 A data structure that is made up of fields and records? Table.
Normalization Data Design - Mr. Ahmad Al-Ghoul
Normalization MIS335 Database Systems. Why Normalization? Optimizing database structure Removing duplications Accelerating the instructions Data integrity!
Vendor Master Record Registration To Register New or Update an Existing Supplier Registration
MIS2502: Data Analytics Relational Data Modeling
Relational Database in Access Student System As always please use speaker notes!
Sample Table Standard Notation Entity name in uppercase
MIS2502: Data Analytics Relational Data Modeling David Schuff
Concepts of Database Management, Fifth Edition Chapter 6: Database Design 2: Design Methodology.
Microsoft Access 2010 Chapter 11 Database Design.
Databases Database Normalisation. Learning Objectives Design simple relational databases to the third normal form (3NF).
What Is Normalization  In relational database design, the process of organizing data to minimize redundancy  Usually involves dividing a database into.
Normalisation FORM RULES 1NF 2NF 3NF. What is normalisation of data? The process of Normalisation organises your database to: Reduce or minimise redundant.
Normalisation Worked example for an Order Remember : The data should depend upon the key, the whole key and nothing but the key.
Announcements n Difference between “excused” and “absent” n Office hours next week May not be here Monday Tuesday: 1:00 to 2:00 Wednesday: 10:00 to 11:00.
Flat file and relational databases Flat file database In a flat file database information is held in a single table. Student IDStudent name GenderDOBCourse.
Database Normalization
Database Relationships
MIS2502: Data Analytics Relational Data Modeling
Normalization and Databases
Microsoft Applications
CS 3630 Database Design and Implementation
Database Normalisation
Product Training Purchase Invoices
RECEIPT [Receipt description]
SALES RECEIPT Downloaded from
INVOICE Downloaded from
Topic 12 Lesson 2 – Retrieving Data with Queries
Presentation transcript:

The Relational Database Model CST272

Return

Creating the Unnormalized Table n List the fields n Select a primary key – The field (or concatenation of two or more fields) that uniquely identifies each record Purchase Order Report

Purchase Order (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Product number, Product, Unit price, Quantity, Extension, Subtotal, Tax, Shipping, Discount, PO total) Unnormalized Table Purchase Order Report

The Unnormalized Purchase Order Table Purchase Order Report Return

To Convert from Unnormalized to 1NF n Identify, list and remove repeating groups n Modify Primary key (concatenated fields) n Important: In 1NF there always will still be just one table

Purchase Order (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Product number, Product, Unit price, Quantity, Subtotal, Tax, Shipping, Discount, PO total) Repeating Groups The Unnormalized Purchase Order Table Purchase Order Report

The Payables Table in 1NF Return Purchase Order Report

Payables (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Product number, Product, Unit price, Quantity, Subtotal, Tax, Shipping, Discount, PO total) 1NF (First Normal Form) Purchase Order Report The Payables Table in 1NF

To Convert from 1NF to 2NF n Identify the determinants – A listing of every possible combination of elements (fields) that make up the 1NF primary key n Identify the functional dependencies – Which non-key fields rely on which determinants to determine their value n For the new 2NF tables, the determinants are the primary keys

Payables (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Product number, Product, Unit price, Quantity, Subtotal, Tax, Shipping, Discount, PO total) Determinants PO number  Product number  PO number, Product number  Functional Dependencies

Payables (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Product number, Product, Unit price, Quantity, Subtotal, Tax, Shipping, Discount, PO total) Determinants PO number  PO date Product number  PO number, Product number  Functional Dependencies

Payables (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Product number, Product, Unit price, Quantity, Subtotal, Tax, Shipping, Discount, PO total) Determinants PO number  PO date, Vendor number Product number  PO number, Product number  Functional Dependencies

Payables (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Product number, Product, Unit price, Quantity, Subtotal, Tax, Shipping, Discount, PO total) Determinants PO number  PO date, Vendor number, Vendor name Product number  PO number, Product number  Functional Dependencies

Payables (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Product number, Product, Unit price, Quantity, Subtotal, Tax, Shipping, Discount, PO total) Determinants PO number  PO date, Vendor number, Vendor name, Address Product number  PO number, Product number  Functional Dependencies

Payables (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Product number, Product, Unit price, Quantity, Subtotal, Tax, Shipping, Discount, PO total) Determinants PO number  PO date, Vendor number, Vendor name, Address, City Product number  PO number, Product number  Functional Dependencies

Payables (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Product number, Product, Unit price, Quantity, Subtotal, Tax, Shipping, Discount, PO total) Determinants PO number  PO date, Vendor number, Vendor name, Address, City, State Product number  PO number, Product number  Functional Dependencies

Payables (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Product number, Product, Unit price, Quantity, Subtotal, Tax, Shipping, Discount, PO total) Determinants PO number  PO date, Vendor number, Vendor name, Address, City, State, ZIP code Product number  PO number, Product number  Functional Dependencies

Payables (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Product number, Product, Unit price, Quantity, Subtotal, Tax, Shipping, Discount, PO total) Determinants PO number  PO date, Vendor number, Vendor name, Address, City, State, ZIP code Product number  Product PO number, Product number  Functional Dependencies

Payables (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Product number, Product, Unit price, Quantity, Subtotal, Tax, Shipping, Discount, PO total) Determinants PO number  PO date, Vendor number, Vendor name, Address, City, State, ZIP code Product number  Product PO number, Product number  Unit price Functional Dependencies

Payables (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Product number, Product, Unit price, Quantity, Subtotal, Tax, Shipping, Discount, PO total) Determinants PO number  PO date, Vendor number, Vendor name, Address, City, State, ZIP code Product number  Product PO number, Product number  Unit price, Quantity Functional Dependencies

Payables (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Product number, Product, Unit price, Quantity, Subtotal, Tax, Shipping, Discount, PO total) Determinants PO number  PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Subtotal Product number  Product PO number, Product number  Unit price, Quantity Functional Dependencies

Payables (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Product number, Product, Unit price, Quantity, Subtotal, Tax, Shipping, Discount, PO total) Determinants PO number  PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Subtotal, Tax Product number  Product PO number, Product number  Unit price, Quantity Functional Dependencies

Payables (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Product number, Product, Unit price, Quantity, Subtotal, Tax, Shipping, Discount, PO total) Determinants PO number  PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Subtotal, Tax, Shipping Product number  Product PO number, Product number  Unit price, Quantity Functional Dependencies

Payables (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Product number, Product, Unit price, Quantity, Subtotal, Tax, Shipping, Discount, PO total) Determinants PO number  PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Subtotal, Tax, Shipping, Discount Product number  Product PO number, Product number  Unit price, Quantity Functional Dependencies

Payables (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Product number, Product, Unit price, Quantity, Subtotal, Tax, Shipping, Discount, PO total) Determinants PO number  PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Subtotal, Tax, Shipping, Discount, PO total Product number  Product PO number, Product number  Unit price, Quantity Functional Dependencies

Purchase Order (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Subtotal, Tax, Shipping, Discount, PO total) Payables (PO number, Product number, Unit price, Quantity) Product (Product number, Product) 2NF (Second Normal Form) Purchase Order Report

To Convert from 2NF to 3NF n Within the existing 2NF tables, identify the non-key determinants – Any non-key fields that could be a primary key for other fields in one of the 2NF tables n Identify those functional dependencies n Create new table(s) from the determinant(s) and functional dependency(cies) n Do not remove the non-key determinant(s) from original table(s)

Purchase Order (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Subtotal, Tax, Shipping, Discount, PO total) Payables (PO number, Product number, Unit price, Quantity) Product (Product number, Product) Non-key Determinants

Purchase Order (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Subtotal, Tax, Shipping, Discount, PO total) Payables (PO number, Product number, Unit price, Quantity) Product (Product number, Product) Vendor number  Non-key Determinants

Purchase Order (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Subtotal, Tax, Shipping, Discount, PO total) Payables (PO number, Product number, Unit price, Quantity) Product (Product number, Product) Vendor number  Vendor name Non-key Determinants

Purchase Order (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Subtotal, Tax, Shipping, Discount, PO total) Payables (PO number, Product number, Unit price, Quantity) Product (Product number, Product) Vendor number  Vendor name, Address Non-key Determinants

Purchase Order (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Subtotal, Tax, Shipping, Discount, PO total) Payables (PO number, Product number, Unit price, Quantity) Product (Product number, Product) Vendor number  Vendor name, Address, City Non-key Determinants

Purchase Order (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Subtotal, Tax, Shipping, Discount, PO total) Payables (PO number, Product number, Unit price, Quantity) Product (Product number, Product) Vendor number  Vendor name, Address, City, State Non-key Determinants

Purchase Order (PO number, PO date, Vendor number, Vendor name, Address, City, State, ZIP code, Subtotal, Tax, Shipping, Discount, PO total) Payables (PO number, Product number, Unit price, Quantity) Product (Product number, Product) Vendor number  Vendor name, Address, City, State, ZIP code Non-key Determinants

Vendor (Vendor number, Vendor name, Address, City, State, ZIP code) Purchase Order (PO number, Vendor number, Subtotal, Tax, Shipping, PO total, PO date) Payables (PO number, Product number, Unit price, Quantity) Product (Product number, Product) 3NF (Third Normal Form)

Finalize the Tables in Database Design Language n Present the 3NF tables with all keys: – Primary keys—that field which uniquely identifies (differentiates) a record from all other records in the table – Alternate (secondary) keys—a field that could have been the primary key but is not; DBMS must enforce that values of field are unique for every record – Foreign keys—a field that links to field values in another table; a foreign key value must match the primary key of one of the records in table to which it joins, or be null

Vendor (Vendor number, Vendor name, Address, City, State, ZIP code) Purchase Order (PO number, Vendor number, Subtotal, Tax, Shipping, PO total, PO date) FK Vendor number  Vendor Payables (PO number, Product number, Unit price, Quantity) FK PO number  Purchase Order FK Product number  Product Product (Product number, Product) DBDL (Database Design Language)

Vendor (Vendor number, Vendor name, Contact, Telephone) Unnormalized—Contact Listing

Vendor (Vendor number, Vendor name, Contact, Telephone) DBDL—Contact Listing

Merge the Tables n If you have two tables with the identical primary key, they generally should be merged into a single table n The results of each new normalization should be merged into the existing tables from previous normalizations

Vendor (Vendor number, Vendor name, Address, City, State, ZIP code, Contact, Telephone) Purchase Order (PO number, Vendor number, Subtotal, Tax, Shipping, PO total, PO date) FK Vendor number  Vendor Payables (PO number, Product number, Unit price, Quantity) FK PO number  Purchase Order FK Product number  Product Product (Product number, Product) DBDL—The Merged Tables

Vendor (Vendor number, Vendor name, Address, City, State, ZIP code, Contact, Telephone, Fax, Term days, Term percent, Date last order) Purchase Order (PO number, Vendor number, Subtotal, Tax, Shipping, PO total, PO date, Bill date, Discount date, Due date) FK Vendor number  Vendor Payables (PO number, Product number, Unit price, Quantity, Back ordered?) FK PO number  Purchase Order FK Product number  Product Product (Product number, Product) DBDL—The Final Tables

Mini Quiz n Normalize a “Student Transcript”using the model given from the “Payables” database Student Transcript Student ID: 345Advisor ID: 56 Student Name: Sally HensonAdvisor name: Ralph Pollard Credits completed: 32Advisor office: H203 Class standing: FreshmanAdvisor phone: Course numberGrade CS33 A EG13 B+ 1.Unnormalized table 2.Repeating groups (list) 3.1NF 4.Determinants and functional dependencies 5.2NF 6.Non-key determinants and functional dependencies 7.3NF in DBDL (with all keys) 1.Unnormalized table 2.Repeating groups (list) 3.1NF 4.Determinants and functional dependencies 5.2NF 6.Non-key determinants and functional dependencies 7.3NF in DBDL (with all keys) Return

The Unnormalized Table n Student (StudentID, StudentLast, StudentFirst, AdvisorID, AdvisorLast, AdvisorFirst, AdvisorOffice, AdvisorPhone, CreditsCompleted, ClassStanding, CourseNumber, Grade) – CreditsCompleted is the total credits currently completed by the student – ClassStanding is Freshman, Sophomore, etc. – CourseNumber is each course (of more than one) that the student has taken or is taking Student Transcript

Convert from Unnormalized to 1NF n Identify, list and remove repeating groups n Modify the unnormalized table by including an additional field to create a concatenated primary key Student Transcript

Repeating Groups n CourseNumber, Grade Student Transcript

1NF n Student Grade (StudentID, StudentLast, StudentFirst, AdvisorID, AdvisorLast, AdvisorFirst, AdvisorOffice, AdvisorPhone, CreditsCompleted, ClassStanding, CourseNumber, Grade) Student Transcript Return

Convert from 1NF to 2NF n Identify the determinants n List the functional dependencies for each determinant n Create the new tables—one for each determinant and the fields functionally dependent upon it

Determinants n StudentID  n CourseNumber  n StudentID, CourseNumber  1NF

Determinants and Functional Dependencies n StudentID  StudentLast, StudentFirst, AdvisorID, AdvisorLast, AdvisorFirst, AdvisorOffice, AdvisorPhone, CreditsCompleted, ClassStanding n CourseNumber  n StudentID, CourseNumber  Course Grade 1NF Return

2NF n Student (StudentID, StudentLast, StudentFirst, AdvisorID, AdvisorLast, AdvisorFirst, AdvisorOffice, AdvisorPhone, CreditsCompleted, ClassStanding n Course (CourseNumber) n Student Course (StudentID, CourseNumber, Grade) Determinants Return

Convert from 2NF to 3NF n Identify any non-key determinants n List the functional dependencies for each non-key determinant n Create any new tables—one for each non- key determinant and the fields functionally dependent upon it

Non-key Determinants n AdvisorID  2NF

Non-key Determinants n AdvisorID  AdvisorLast, AdvisorFirst, AdvisorOffice, AdvisorPhone 2NF Return

3NF n Student (StudentID, StudentLast, StudentFirst, AdvisorID, CreditsCompleted, ClassStanding n Advisor (AdvisorID, AdvisorLast, AdvisorFirst, AdvisorOffice, AdvisorPhone) n Course (CourseNumber) n Student Course (StudentID, CourseNumber, Grade) Return Non-key Determinants

Finalize All Tables in DBDL n Identify all keys, both primary keys and foreign keys

DBDL n Student (StudentID, StudentLast, StudentFirst, AdvisorID, CreditsCompleted, ClassStanding FK AdvisorID  Advisor n Advisor (AdvisorID, AdvisorLast, AdvisorFirst, AdvisorOffice, AdvisorPhone n Course (CourseNumber) n Student Course (StudentID, CourseNumber, Grade) FK StudentID  Student FK CourseNumber  Course 3NF

The Vendor Table

The Product Table

The Purchase Order Table

The Payables Table

The Vendor Data

The Product Data

The Purchase Order Data

The Payables Data Use the mouse to click and place a in the field meaning "Yes" or turn off meaning "No" Use the mouse to click and place a in the field meaning "Yes" or turn off meaning "No"

n List the supplier company, supplier stock number and item name for all products in the inventory data base? n (Linked on common field between tables) select Item, [Supplier stock number], [Company name] from Inventory, Supplier where Inventory.[Supplier code] = Supplier.[Supplier code]; Joining Two Tables Together

select Item, [Supplier stock number], [Company name] from Inventory, Supplier where Inventory.[Supplier code] = Supplier.[Supplier code];

select Item, [Supplier stock number], [Company name] from Inventory, Supplier...;

select Item, [Supplier stock number], [Company name] from Inventory, Supplier where Inventory.[Supplier code] = Supplier.[Supplier code];