Logical (Information Level) Design of Relational Databases.

Slides:



Advertisements
Similar presentations
Database Design: Normalization J.G. Zheng June 29 th 2005 DB Chapter 4.
Advertisements

Relational Terminology. Normalization A method where data items are grouped together to better accommodate business changes Provides a method for representing.
Normalization – Additional Notes. Normalization Abstract Example For the following un-normalized relation: RELN1[A, B, {C, D}, E, F, G] where E can be.
Modeling the Data: Conceptual and Logical Data Modeling
Normalization of Database Tables
Database Design Conceptual –identify important entities and relationships –determine attribute domains and candidate keys –draw the E-R diagram Logical.
The Relational Database Model:
1 NORMALISATION. 2 Introduction Overview Objectives Intro. to Subject Why we normalise 1, 2 & 3 NF Normalisation Process Example Summary.
Normalization of Database Tables
Project and Data Management Software
July 14, 2015ICS 424: recap1 Relational Database Design: Recap of ICS 324.
NORMALIZATION N. HARIKA (CSC).
Michael F. Price College of Business Chapter 6: Logical database design and the relational model.
Mapping ERM to relational database
Introduction to Databases
Normalization Rules for Database Tables Northern Arizona University College of Business Administration.
Normalization B Database Systems Normal Forms Wilhelm Steinbuss Room G1.25, ext. 4041
Daniel AdinugrohoDatabase Programming 1 DATABASE PROGRAMMING Lecture on 29 – 04 – 2005.
1 Nassau Community CollegeProf. Vincent Costa Acknowledgements: Introduction to Database Management, All Rights ReservedIntroduction to Database Management.
Logical Relational Database Design. Logical Relational Design Purpose of logical data design is to represent application data in the form of related 2-dimensional.
File and Database Design SYS364. Today’s Agenda WHTSA DBMS, RDBMS, SQL A place for everything and everything in its place. Entity Relationship Diagrams.
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 9.1.
XP Chapter 1 Succeeding in Business with Microsoft Office Access 2003: A Problem-Solving Approach 1 Level 3 Objectives: Identifying and Eliminating Database.
CREATE THE DIFFERENCE Normalisation (special thanks to Janet Francis for this presentation)
MIS 385/MBA 664 Systems Implementation with DBMS/ Database Management Dave Salisbury ( )
Chapter 1 Overview of Database Concepts Oracle 10g: SQL
Conceptual Design versus Logical Design. Conceptual Data Design Prepared at beginning of project High level view of how the client sees the data Top down.
1 Chapter 1 Overview of Database Concepts. 2 Chapter Objectives Identify the purpose of a database management system (DBMS) Distinguish a field from a.
Concepts and Terminology Introduction to Database.
Lecture 2 An Overview of Relational Database IST 318 – DB Admin.
CBAD2103 Data Analysis and Modeling. Chapter 7 Conceptual Design Methodology.
Fundamentals, Design, and Implementation, 9/e. Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/2 Copyright.
Avoiding Database Anomalies
Normalization. Rigorous technique used to break down data represented in a user view into a set of 2- dimensional tables where “all attributes in the.
Normalization A technique that organizes data attributes (or fields) such that they are grouped to form stable, flexible and adaptive entities.
1 DATABASE SYSTEMS DESIGN IMPLEMENTATION AND MANAGEMENT INTERNATIONAL EDITION ROB CORONEL CROCKETT Chapter 7 Normalisation.
Normalization (Codd, 1972) Practical Information For Real World Database Design.
資料庫正規化 Database Normalization 取材自 AIS, 6 th edition By Gelinas et al.
In this chapter, you learn about the following: ❑ Anomalies ❑ Dependency and determinants ❑ Normalization ❑ A layman’s method of understanding normalization.
10/3/2012ISC329 Isabelle Bichindaritz1 Logical Design.
CS370 Spring 2007 CS 370 Database Systems Lecture 4 Introduction to Database Design.
Chapter 1Introduction to Oracle9i: SQL1 Chapter 1 Overview of Database Concepts.
Unit 4 Object Relational Modeling. Key Concepts Object-Relational Modeling outcomes and process Relational data model Normalization Anomalies Functional.
Database Design. The process of developing database structures from user requirements for data a structured methodology Structured Methodology - a number.
1 5 Chapter 5 Database Design 1: Some Normalization Examples Spring 2006.
Component 4/Unit 6d Topic IV: Design a simple relational database using data modeling and normalization Description and Information Gathering Data Model.
IT The Relational DBMS Section 05. Relational Database Theory Normalization for Logical Database Design.
9/23/2012ISC329 Isabelle Bichindaritz1 Normalization.
Normalization. 2 u Main objective in developing a logical data model for relational database systems is to create an accurate representation of the data,
Normalization Example. Database Systems, 8 th Edition 2 Database Tables and Normalization Normalization –Process for evaluating and correcting table structures.
BSA206 Database Management Systems Lecture 2: Introduction to Oracle / Overview of Database Concepts.
1 DATABASE TECHNOLOGIES (Part 2) BUS Abdou Illia, Fall 2015 (September 9, 2015)
Chapter 10 Designing Databases. Objectives:  Define key database design terms.  Explain the role of database design in the IS development process. 
DBMS ER model-2 Week 6-7.
11/10/2009GAK1 Normalization. 11/10/2009GAK2 Learning Objectives Definition of normalization and its purpose in database design Types of normal forms.
6-1 © Prentice Hall, 2007 Topic 6: Object-Relational Modeling Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich,
8-1 © Prentice Hall, 2007 Chapter 8: Object-Relational Modeling Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich,
Microsoft Access 2010 Chapter 11 Database Design.
Logical Design 12/10/2009GAK1. Learning Objectives How to remove features from a local conceptual model that are not compatible with the relational model.
Normalization. Overview Earliest  formalized database design technique and at one time was the starting point for logical database design. Today  is.
NormalisationNormalisation Normalization is the technique of organizing data elements into records. Normalization is the technique of organizing data elements.
Methodology - Logical Database Design. 2 Step 2 Build and Validate Local Logical Data Model To build a local logical data model from a local conceptual.
Database Architecture Normalization. Purpose of Normalization A technique for producing a set of relations with desirable properties, given the data requirements.
5 1 Chapter 5 Normalization of Database Tables Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel.
What Is Normalization  In relational database design, the process of organizing data to minimize redundancy  Usually involves dividing a database into.
MS Access. Most A2 projects use MS Access Has sufficient depth to support a significant project. Relational Databases. Fairly easy to develop a good user.
Normal Forms 1NF – A table that qualifies as a relation is in 1NF. (Back)(Back) 2NF – A relation is in 2NF if all of its nonkey attributes are dependent.
SEEM3430: Information Systems Analysis and Design
Relational Model and ER Model: in a Nutshell
© 2011 Pearson Education, Inc. Publishing as Prentice Hall
Presentation transcript:

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 List Section: DBS355ASubject Name: Intro to DB Instructor No: 213Instructor Name: Patricia Belvedere Student No: Student Name: Joe Brown Student No: Student Name: Le Huang Section: DBS355BSubject Name: Intro to DB Instructor No: 222Instructor Name: Libby Langer Student No: Ella Zeltserman Student No: 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]