Chapter 9: Normalization
|
|
- Maria Miller
- 8 years ago
- Views:
Transcription
1 Chapter 9: Normalization Part 1: A Simple Example Part 2: Another Example & The Formal Stuff A Problem: Keeping Track of Invoices (cont d) Suppose we have some invoices that we may or may not want to refer to later 1
2 A Problem: Keeping Track of Invoices (cont d) Fig. 9.1 Could store in an excel file but, as seen, might have problems if have complex questions relating to the data: 1. How many 4 bolts did Frankenstein Parts order in 2002? 2. What items were sold on a certain date? Solution: A Normalized Database First Normal Form (NF1): No Repeating Elements or Groups of Elements In Fig. 9.1, rows 2, 3, 4 represent invoice 125, which in DB terms is a single tuple In NF1 want to get rid of repeating elements, which are: column H2 to H4, column J2 to J4, column K2 to K4 etc these contain lists of values, and these are hated by NF1 NF1 wants atomicity: each attribute is simple & indivisible the repeating data for invoice 125 is cells: H2-M2, H3-M3, H4- M4 Can satisfy NF1, simply by separating each item in these lists into its own row (See Fig. 9.2). 2
3 Solution: NF1 Cont d Fig. 9.2 But, were trying to reduce & simplify, now have introduced more data! No matter, this will be addressed later (with NF3) Solution: NF1 Cont d Have only done half of NF1. NF1 addresses: 1. Row of data can t have repeat groups of similar data (atomicity) 2. Each row of data must have a unique identifier (or Primary Key) In order to look at 2., have to convert Fig 9.2 into a RDBMS (see the table in MS Access Fig. 9.3) Fig. 9.3 As can be seen, no one column ids each row, so have to use two together: order_id & item_id Together the concatenated primary key ids each row 3
4 Solution: NF1 Cont d The underlying structure of the table can be represented as Fig. 9.4 Fig. 9.4 order_ date Identify the columns that t make up the customer_id primary key with the PK notation. customer_address Fig. 9.4 begins the Entity Relationship customer_state Diagram (or ERD). DB schema now satisfies the 2 requirements of NF1: atomicity & uniqueness. Thus it meets the most basic criteria of a relational db. item_total_pricetotal order_total_price Solution: NF2 Second Normal Form (NF2): No Partial Dependencies on a Concatenated Key Next have to test each table for partial dependencies on a concatenated key Means that for a table with a concatenated primary key, each column that is not part of the primary key must depend upon the entire concatenated key for its existence. If a column depends upon only 1 part of the concatenated key, then entire table has failed NF2 & must create another table to fix it. For each column must ask the question: Can this column exist without one or the other part of the concatenated primary key? If answer is yes even once table fails NF2 4
5 Solution: NF2 Cont d Refer to Fig. 9.4 again to recall table structure. Recall the meaning of the two columns Fig. 9.4 in the primary key: order_ date order_id ids invoice this item comes from. customer_id item_id is the inventory items unique identifier. customer_address Can think of it as a part number. customer_state Don't analyze these columns (since they are part of the primary key). total Instead consider the remaining columns... item_total_price order_total_price Solution: NF2 Cont d order_date is the date on which the order was made. relies on order_id; an order date has to have an order, otherwise it is only a date can an order date exist without an item_id? yes: order_date relies on order_id, not item_id id (a specific order doesn t have to have a specific item) so order_date fails NF2 customer_id is ID of the customer who placed the order does it rely on order_id? No: a customer can exist without placing any. does it rely on item_id? id? No (same reason). customer_id does not rely on either member of the PK What to do? NF3 will come to the rescue here, hence? for all the rest of the customer_* columns 5
6 Solution: NF2 Cont d is next column not itself part of PK. It is the plain-language description of the inventory item. relies on item_id, but can it exist without an order_id? Yes! An inventory item (&"description") could sit on a shelf, and never be purchased... It can exist independent of an order. fails the test. is no. of items purchased on a particular invoice. can it exist without an item_id? No: cant have "amount of nothing" can it exist without an order_id? No: a quantity purchased with an invoice is meaningless without an invoice. So this column does not violate NF2 depends on both parts of our concatenated PK. Solution: NF2 Cont d is similar to. It depends on the item_id but not on order_id, so it does violate NF2. item_total_price is tricky: seems to depend on both order_id & item_id, so passes NF2. but it is a derived value: it is times. so, in fact, it doesn t belong in the db at all. can easily be reconstructed outside of db; to include it would be redundant (and could quite possibly introduce corruption). therefore can discard it order_total_price the sum of all the item_total_price fields for a particular order, is another derived value. can discard this field too for the same reason as item_total_price 6
7 Solution: NF2 Cont d Fig. 9.4 order_date customer_id customer_address customer_state item_total_price order_total_price Fig. 9.4 (New) order_date customer_id?? customer_address? customer_state? item_total_price order_total_price? Solution: NF2 Cont d What to do with a table that fails NF2, as this one has? First take out the second half of the concatenated PK (item_id) & put it in its own table. All columns that depend on item_id - whether in whole or in part - follow it into the new table, order_items (see Fig. 9.5). The other fields those that rely on just the first half of the PK (order_id) and those we aren't sure about stay where they are. Fig. 9.5 order_date customer_id customer_address customer_state order_items 7
8 Solution: NF2 Cont d things to notice abut Fig. 9.5: 1. have brought a copy of order_id to the order_items table to allow each order_item to "remember" which order it is a part of. 2. table has fewer rows than before & no longer has a concatenated PK. PK consists of a single column, order_id. 3. order_items table does have a concatenated primary key. Crows feet mean in Fig. 9.5: each order can be associated with any number of order-items, but at least one; each order-item is associated with one order, and only one. Fig. 9.5 order_date customer_id customer_address customer_state order_items Solution: NF2 Phase II Remember, NF2 only applies to tables with a concatenated PK. Now has a single-column PK, it has passed NF2. order_items, however, still has a concatenated PK. have to pass it thro NF2 analysis again to see if it passes. ask the same question we did before: Can this column exist without one or the other part of the concatenated PK? Fig. 9.6 shows order_items table structure. Fig. 9.6 order_items relies on item_id, but not order_id, so this again fails NF2 relies on both parts of PK, does not violate NF2 relies on item_id but not on order_id, so it does violate NF2 8
9 Fig. 9.6 Solution: NF2 Phase II Cont d order_items item_ descriptionp Fig. 9.6 (New) order_items On first pass thro NF2 test, lost all fields relying on item_id & put them into new table. This time, only taking fields failing the test: ie stays. What's different this time? First pass, removed item_ id key from altogether cos of the 1:M relationship between & order-items. Therefore field had to follow item_id into the new table. Second pass, item_id wasn t taken from order-items table cos of the M:1 relationship between order-items & items. Therefore, since does not violate NF2 this time, it is permitted to stay in the table with the two PK parts that it relies on. Solution: NF2 Phase II Cont d Crows feet mean in Fig. 9.7: each item can be associated with any number of lines on any number of invoices, including zero; each order-item is associated with one item, and only one. These two lines are examples of 1:M relationships. This 3-table structure, is how express a M:N relationship: Each order can have many items; each item can belong to many. Notes: Didn t bring a copy of order_id column into new table cos individual items needn t know the they are part of, as order_items remembers this r ship via the order_id & item_id columns. Taken together these columns comprise the PK of order_items, but taken separately they are FKs to rows in other tables. New table does not have a concatenated PK, so it passes NF2. Fig. 9.7 order_date customer_id customer_address customer_state order_items items 9
10 Solution: NF3 Third Normal Form (NF3): No Dependencies on Non-Key Attributes Can return to repeating Customer info problem. As db stands, if customer places >1 order have to input customer's s contact info again cos there are columns in that rely on "non-key attributes". To understand this, consider order_date. Can it exist independent of order_id? No!: an "order date" is meaningless without an order. order_date depends on a key attribute (order_id is "key attribute" because it is table s PK). What about can it exist on its own, outside of the table? Yes. It is meaningful to talk about a customer name without referring to an order or invoice. Solution: NF3 Cont d Same goes for customer_address,, & customer_state. These 4 columns actually rely on customer_id, which is not a key in this table (it is a non-key attribute). These fields belong in their own table customers, with customer_id as PK (see Fig 9.8). However, notice in Fig 9.8 that relationship has been severed btw table and the Customer data that used to inhabit it. customer_id(fk) order_date order_items items Fig. 9.8 customers customer_id(pk) customer_address customer_state 10
11 Solution: NF3 Cont d Restore relationship by creating a foreign key (indicated by (FK)) in As know, FK is a column that points to the PK in another table. Fig 9.9 describes this relationship, and shows our completed ERD. Relationship between & customers may be expressed in this way: each order is made by one, and only one customer; each customer can make any number of, including zero customer_id(fk) order_date order_items items Fig. 9.9 customers customer_id(pk) customer_address customer_state Solution: NF3 Cont d Last point to note: order_id and item_id columns in order_items perform a dual purpose: not only do they function as the (concatenated) PK for order_items, they also individually id serve as FKs to the table and items table respectively. This is shown in Fig customer_id(fk) order_date order_items order_id(fk) PK item_id(fk) items Fig customers customer_id(pk) customer_address customer_state 11
12 Normalisation cont d Introduction to Database Design As we have seen, an important part of database design is deciding on a suitable logical structure or schema to implement... called database design. SP Considering supplier parts example (S,P,SP) S# P# QTY S S1 P1 300 there is a feeling of correctness. S1 P2 200 S# SName Status City S1 P3 400 S1 Smith 20 Paris Normalisation theory is a S2 P1 300 S2 Jones 10 Paris S2 P2 400 S3 Blake 30 Rome formalism of simple ideas with a P S3 P2 200 practical application P# PName Colour Weight City P1 Nut Red 12 London P2 Bolt Green 17 Paris in logical database schema design. P3 Screw Blue 27 Rome P4 Screw Red 14 London Normalisation theory should allow us to recognise relations with undesirable properties, tell us what is "wrong" & how to "correct" it. 12
13 Intro to Database Design Cont d Normalisation theory is built around normal forms - each normal form has a set of satisfiable criteria. Normal forms exist in a hierarchy: 1NF -> 2NF -> 3NF -> BCNF -> 4NF -> PJ/NF (5NF) Codd defined 1NF, 2NF, 3NF in NF had inadequacies so revised in 74 by Boyce/Codd (BCNF) Fagin defined 4NF, 1979 defined 5NF. 6NF,7NF?... dependencies theory suggests there may be higher NFs but not practicable in database environment. DB designers should aim for higher NFs but this is not law - just recommended as normalisation simply provides guidelines for database design. There are often good reason for not using normalisation theory. Introduction to Database Design Cont d In order to describe the various normal forms we must first introduce some definitions: Functional Dependency Given relation R, attribute Y of R is functionally dependent on X of R, R.X -> R.Y, or R.X functionally determines R.Y iff each R.X value has associated with it precisely one R.Y value, where X and/or Y may be composite. R.X called the determinant, R.Y called the dependent S.SNAME, S.STATUS and S.CITY are each functionally dependent on S.S# S# If R.X is a candidate key or if R.X is the primary key, then all R.Y must be functionally dependent on R.X In SP we have a composite primary key so SP.(S#,P#) -> SP.QTY 13
14 Introduction to Database Design Cont d There is no requirement in the definition of functional dependence that R.X be a candidate key, thus: R.X -> R.Y iff whenever 2 tuples of R.X are the same then the corresponding R.Y values are also the same. R.Y is fully functionally dependent on R.X.. iff it is functionally dependent on R.X & not fully functionally dependent on any subset of R.X Example: S.(S#,STATUS) -> S.CITY is true but not full functional dependence as S.S# -> S.CITY If R.X -> R.Y but not fully then R.X must be composite Normalisation: Example 2 Given the report in Fig 9.11, need to put it in a tidy DB. Problems with current form: PROJ_NUM is supposed to be PK or part of PK but contains nulls. Maybe PROJ_ NUM+EMP _ NUM will define e each row. The table entries contain inconsistencies (e.g. JOB_CLASS Elect. Engineer could be EE or E. Eng or others) Fig
15 Normalisation: Example 2 Cont d Further problems with current form: The table has data redundancies leading to the following anomalies: 1. Update Anomalies: Modifying (e.g.) JOB_CLASS for Employee 105 requires lots of alterations (one for each employee 105). 2. Insertion Anomalies: To complete a row definition, a new employee must be given a project; if not yet assigned, this must be assumed to complete the employee tuple. 3. Deletion Anomalies: If employee 103 quits, every row with EMP_NUM=103 must be deleted with the potential loss of other data. Inefficiency: If a large number of new employees are hired, a lot of redundant/unassigned d d data must be assumed and input. Integrity: Possible data integrity problems may arise out of the above. Example 2: Conversion to NF1 So Problems with Fig. 9.11: Data cannot be as shown in Fig cos have to be able to identify all tuples with a PK. PROJ_NUM cannot be PK in Fig cos of nulls Cannot have the repeating groups shown in Fig so have to alter table to remove them. Step 1. Eliminate the repeating groups Eliminate the null values. Now have Fig Fig
16 Example 2: Conversion to NF1 Cont d Step 2. Identify the Primary Key Layout in Fig is only a cosmetic change need a PK to uniquely identify all tuples. This may be seen to be PROJ_NUM+EMP_NUM Step 3. Identify all dependencies The identification of the PK means already have the following: PROJ_NUM,EMP_NUM PROJ_NAME,EMP_NAME,JOB_CLASS,CHG_HOUR, HOURS Fig Example 2: Conversion to NF1 Cont d Step 3. Cont d But there are additional dependencies: 1. The project number determines the project name: PROJ_NUM PROJ_NAME 2. If know employee number, also know their name, job classification and their charge per hour: EMP_NUM EMP_NAME, JOB_CLASS, CHG_HOURS 3. Also knowing job classification means also know the charge per hour: JOB_CLASS CHG_HOURS These dependencies are shown in the Dependency Diagram in Fig Dependency Diagrams are useful for getting an overall view of relationships among attributes. Fig PROJ_ NUM PROJ_ NAME EMP_ NUM EMP_ NAME JOB_ CLASS CHG_ HOUR HOURS Normal Partial Transitive 16
17 Example 2: Conversion to NF1 Cont d Looking at Fig. 9.13, can see that: 1. PK attributes are bold, underlined and a different colour. 2. Arrows above (blue) denote desirable FDs (those based on PK) 3. Arrows below the diagram (red and green) are less desirable: a) Partial Dependencies: dependencies based on part of composite PK Need only know PROJ_NUM to know PROJ_NAME, so PROJ_NAME is only dependent on part of the PK. Need only know EMP_NUM to find the EMP_NAME, JOB_CLASS, CHG_HOUR. b) Transitive Dependencies: Dependency of 1 non-prime attribute on another From Fig. 9.13, can see that CHG_HOUR is dependent on JOB_CLASS Neither of these is part of PK (i.e. a Prime Attribute). Fig PROJ_ NUM PROJ_ NAME EMP_ NUM EMP_ NAME JOB_ CLASS CHG_ HOUR HOURS Normal Partial Transitive Example 2: Conversion to NF1 Cont d Properties of NF1: A table in NF1 must have: 1. All key attributes defined 2. No repeating groups in the table (i.e each row/column entry must have only one value) Problem with Fig is the partial dependencies. This can be eliminated with NF2 17
18 Example 2: Conversion to NF2 Step 1. Identify all key components: PROJ_NUM EMP_NUM PROJ_NUM, EMP_NUM Each component becomes the key of a new table. Three new tables project, employee, assign Step 2. Identify the dependent attributes Use Fig to determine which attributes are dependent on which others, using the arrows in the dependency diagram project(proj_num, PROJ_NAME) employee(emp_num, EMP_NAME, JOB_CLASS, CHG_HOURS) assign(proj_num, EMP_NUM, ASSIGN_HOURS) Results are shown in Fig Example 2: Conversion to NF2 Cont d At this point, most anomalies discussed above have been eliminated e.g. if want to add/change/delete a project record, only need to alter 1 row of project So a table is in NF2 iff 1. It is in NF1 And 2. It has no partial dependencies (can still have transitive dependencies) Fig still has a transitive dependency which can generate anomalies e.g. if charge per hour changes for a job classification held by many employees, that change must be made for all (leading to possible update anomalies) Resolve transitive dependencies in NF3 PROJ_ NUM project PROJ_ NAME Fig EMP_ NUM EMP_ NAME JOB_ CLASS employee CHG_ HOUR PROJ_ NUM EMP_ NUM assign ASSIGN _HOURS 18
19 Example 2: Conversion to NF3 Step 1. Identify each new determinant For each transitive dependency, write its determinant as a PK for a new table (recall: determinant is any attribute whose value determines other values within a row). If have 3 transitive dependencies, have 3 different determinants Here only have one: JOB_CLASS Step 2. Identify the dependent attributes Identify the attributes dependent on each determinant identified in Step 1. Here, have JOB_CLASS CHG_HOUR Name the table to reflect its contents & function, here JOB is ok Step 3. Remove dependent attrib from transitive dependencies Remove all dependent attributes from dependent relationship(s) from each table with transitive relationships JOB_CLASS remains in the employee table as FK Example 2: Conversion to NF3 Final dependency diagram is shown in Fig Fig PROJ_ PROJ_ EMP_ EMP_ JOB_ JOB_ CHG_ PROJ_ EMP_ NUM NAME NUM NAME CLASS CLASS HOUR NUM NUM project employee job assign Or 4 Tables: project(proj_num, PROJ_NAME) assign(emp_num, PROJ_NUM, ASSIGN_HOURS) employee(emp_num, EMP_NAME, JOB_CLASS) job(job_class, CHG_HOUR) A table is in NF3 iff It is in NF2 And It contains no transitive dependencies. ASSIGN _HOURS 19
The 3 Normal Forms: Copyright Fred Coulson 2007 (last revised February 1, 2009)
The 3 Normal Forms: A Tutorial by Fred Coulson Copyright Fred Coulson 2007 (last revised February 1, 2009) This tutorial may be freely copied and distributed, providing appropriate attribution to the author
More informationTopic 5.1: Database Tables and Normalization
Topic 5.1: Database Tables and Normalization What is Normalization? Normalization is a process for evaluating and correcting table structures to minimize data redundancies, thereby helping to eliminate
More informationFunctional Dependency and Normalization for Relational Databases
Functional Dependency and Normalization for Relational Databases Introduction: Relational database design ultimately produces a set of relations. The implicit goals of the design activity are: information
More informationModule 5: Normalization of database tables
Module 5: Normalization of database tables Normalization is a process for evaluating and correcting table structures to minimize data redundancies, thereby reducing the likelihood of data anomalies. The
More informationChapter 6. Database Tables & Normalization. The Need for Normalization. Database Tables & Normalization
Chapter 6 Database Tables & Normalization Objectives: to learn What normalization is and what role it plays in the database design process About the normal forms 1NF, 2NF, 3NF, BCNF, and 4NF How normal
More informationNormalisation. Why normalise? To improve (simplify) database design in order to. Avoid update problems Avoid redundancy Simplify update operations
Normalisation Why normalise? To improve (simplify) database design in order to Avoid update problems Avoid redundancy Simplify update operations 1 Example ( the practical difference between a first normal
More informationCOSC344 Database Theory and Applications. Lecture 9 Normalisation. COSC344 Lecture 9 1
COSC344 Database Theory and Applications Lecture 9 Normalisation COSC344 Lecture 9 1 Overview Last Lecture Functional Dependencies This Lecture Normalisation Introduction 1NF 2NF 3NF BCNF Source: Section
More informationNormalisation to 3NF. Database Systems Lecture 11 Natasha Alechina
Normalisation to 3NF Database Systems Lecture 11 Natasha Alechina In This Lecture Normalisation to 3NF Data redundancy Functional dependencies Normal forms First, Second, and Third Normal Forms For more
More informationC# Cname Ccity.. P1# Date1 Qnt1 P2# Date2 P9# Date9 1 Codd London.. 1 21.01 20 2 23.01 2 Martin Paris.. 1 26.10 25 3 Deen London.. 2 29.
4. Normalisation 4.1 Introduction Suppose we are now given the task of designing and creating a database. How do we produce a good design? What relations should we have in the database? What attributes
More informationDATABASE NORMALIZATION
DATABASE NORMALIZATION Normalization: process of efficiently organizing data in the DB. RELATIONS (attributes grouped together) Accurate representation of data, relationships and constraints. Goal: - Eliminate
More informationDatabase Design. Marta Jakubowska-Sobczak IT/ADC based on slides prepared by Paula Figueiredo, IT/DB
Marta Jakubowska-Sobczak IT/ADC based on slides prepared by Paula Figueiredo, IT/DB Outline Database concepts Conceptual Design Logical Design Communicating with the RDBMS 2 Some concepts Database: an
More informationFundamentals of Database System
Fundamentals of Database System Chapter 4 Normalization Fundamentals of Database Systems (Chapter 4) Page 1 Introduction To Normalization In general, the goal of a relational database design is to generate
More informationNormalization of Database
Normalization of Database UNIT-4 Database Normalisation is a technique of organizing the data in the database. Normalization is a systematic approach of decomposing tables to eliminate data redundancy
More informationDATABASE DESIGN: NORMALIZATION NOTE & EXERCISES (Up to 3NF)
DATABASE DESIGN: NORMALIZATION NOTE & EXERCISES (Up to 3NF) Tables that contain redundant data can suffer from update anomalies, which can introduce inconsistencies into a database. The rules associated
More informationChapter 15 Basics of Functional Dependencies and Normalization for Relational Databases
Chapter 15 Basics of Functional Dependencies and Normalization for Relational Databases Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 15 Outline Informal Design Guidelines
More informationChapter 10. Functional Dependencies and Normalization for Relational Databases
Chapter 10 Functional Dependencies and Normalization for Relational Databases Chapter Outline 1 Informal Design Guidelines for Relational Databases 1.1Semantics of the Relation Attributes 1.2 Redundant
More informationNormalization in Database Design
in Database Design Marek Rychly mrychly@strathmore.edu Strathmore University, @ilabafrica & Brno University of Technology, Faculty of Information Technology Advanced Databases and Enterprise Systems 14
More informationNormalization. CIS 3730 Designing and Managing Data. J.G. Zheng Fall 2010
Normalization CIS 3730 Designing and Managing Data J.G. Zheng Fall 2010 1 Overview What is normalization? What are the normal forms? How to normalize relations? 2 Two Basic Ways To Design Tables Bottom-up:
More informationChapter 10. Functional Dependencies and Normalization for Relational Databases. Copyright 2007 Ramez Elmasri and Shamkant B.
Chapter 10 Functional Dependencies and Normalization for Relational Databases Copyright 2007 Ramez Elmasri and Shamkant B. Navathe Chapter Outline 1 Informal Design Guidelines for Relational Databases
More informationTheory of Relational Database Design and Normalization
Theory of Relational Database Design and Normalization (Based on Chapter 14 and some part of Chapter 15 in Fundamentals of Database Systems by Elmasri and Navathe, Ed. 3) 1 Informal Design Guidelines for
More informationSchema Refinement, Functional Dependencies, Normalization
Schema Refinement, Functional Dependencies, Normalization MSCI 346: Database Systems Güneş Aluç, University of Waterloo Spring 2015 MSCI 346: Database Systems Chapter 19 1 / 42 Outline 1 Introduction Design
More informationNormalization. Reduces the liklihood of anomolies
Normalization Normalization Tables are important, but properly designing them is even more important so the DBMS can do its job Normalization the process for evaluating and correcting table structures
More informationCS 377 Database Systems. Database Design Theory and Normalization. Li Xiong Department of Mathematics and Computer Science Emory University
CS 377 Database Systems Database Design Theory and Normalization Li Xiong Department of Mathematics and Computer Science Emory University 1 Relational database design So far Conceptual database design
More informationIntroduction to normalization. Introduction to normalization
Introduction to normalization Lecture 4 Instructor Anna Sidorova Agenda Presentation Review of relational models, in class exersise Introduction to normalization In-class exercises Discussion of HW2 1
More informationOverview of Database Management Systems
Overview of Database Management Systems Goals: DBMS basic concepts Introduce underlying managerial issues Prepare for discussion of uses of DBMS, such as OLAP and database mining 1 Overview of Database
More informationThe process of database development. Logical model: relational DBMS. Relation
The process of database development Reality (Universe of Discourse) Relational Databases and SQL Basic Concepts The 3rd normal form Structured Query Language (SQL) Conceptual model (e.g. Entity-Relationship
More informationNormalisation 6 TABLE OF CONTENTS LEARNING OUTCOMES
Topic Normalisation 6 LEARNING OUTCOMES When you have completed this Topic you should be able to: 1. Discuss importance of the normalisation in the database design. 2. Discuss the problems related to data
More informationPart 6. Normalization
Part 6 Normalization Normal Form Overview Universe of All Data Relations (normalized / unnormalized 1st Normal Form 2nd Normal Form 3rd Normal Form Boyce-Codd Normal Form (BCNF) 4th Normal Form 5th Normal
More informationChapter 10 Functional Dependencies and Normalization for Relational Databases
Chapter 10 Functional Dependencies and Normalization for Relational Databases Copyright 2004 Pearson Education, Inc. Chapter Outline 1 Informal Design Guidelines for Relational Databases 1.1Semantics of
More informationDatabase design 1 The Database Design Process: Before you build the tables and other objects that will make up your system, it is important to take time to design it. A good design is the keystone to creating
More informationDATABASE SYSTEMS. Chapter 7 Normalisation
DATABASE SYSTEMS DESIGN IMPLEMENTATION AND MANAGEMENT INTERNATIONAL EDITION ROB CORONEL CROCKETT Chapter 7 Normalisation 1 (Rob, Coronel & Crockett 978184480731) In this chapter, you will learn: What normalization
More informationTheory of Relational Database Design and Normalization
Theory of Relational Database Design and Normalization (Based on Chapter 14 and some part of Chapter 15 in Fundamentals of Database Systems by Elmasri and Navathe) 1 Informal Design Guidelines for Relational
More informationChapter 5: Logical Database Design and the Relational Model Part 2: Normalization. Introduction to Normalization. Normal Forms.
Chapter 5: Logical Database Design and the Relational Model Part 2: Normalization Modern Database Management 6 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden Robert C. Nickerson ISYS
More informationDatabase Management System
UNIT -6 Database Design Informal Design Guidelines for Relation Schemas; Functional Dependencies; Normal Forms Based on Primary Keys; General Definitions of Second and Third Normal Forms; Boyce-Codd Normal
More informationTutorial on Relational Database Design
Tutorial on Relational Database Design Introduction Relational database was proposed by Edgar Codd (of IBM Research) around 1969. It has since become the dominant database model for commercial applications
More informationA Short Tutorial on Using Visio 2010 for Entity-Relationship Diagrams
A Short Tutorial on Using Visio 2010 for Entity-Relationship Diagrams by Nezar Hussain Microsoft Visio 2010 is a flexible software tool that allows users to create some diagrams and charts, providing an
More informationDatabase Design and Normalization
Database Design and Normalization Chapter 10 (Week 11) EE562 Slides and Modified Slides from Database Management Systems, R. Ramakrishnan 1 Computing Closure F + Example: List all FDs with: - a single
More informationNormalization. CIS 331: Introduction to Database Systems
Normalization CIS 331: Introduction to Database Systems Normalization: Reminder Why do we need to normalize? To avoid redundancy (less storage space needed, and data is consistent) To avoid update/delete
More informationNormalization. Normalization. First goal: to eliminate redundant data. for example, don t storing the same data in more than one table
Normalization Normalization Purpose Redundancy and Data Anomalies 1FN: First Normal Form 2FN: Second Normal Form 3FN: Thrird Normal Form Examples 1 Normalization Normalization is the process of efficiently
More informationLecture 6. SQL, Logical DB Design
Lecture 6 SQL, Logical DB Design Relational Query Languages A major strength of the relational model: supports simple, powerful querying of data. Queries can be written intuitively, and the DBMS is responsible
More informationDatabase Design Basics
Database Design Basics Table of Contents SOME DATABASE TERMS TO KNOW... 1 WHAT IS GOOD DATABASE DESIGN?... 2 THE DESIGN PROCESS... 2 DETERMINING THE PURPOSE OF YOUR DATABASE... 3 FINDING AND ORGANIZING
More informationNormalization. Normalization. Normalization. Data Redundancy
Normalization Normalization o Main objective in developing a logical data model for relational database systems is to create an accurate representation of the data, its relationships, and constraints.
More informationWeek 11: Normal Forms. Logical Database Design. Normal Forms and Normalization. Examples of Redundancy
Week 11: Normal Forms Database Design Database Redundancies and Anomalies Functional Dependencies Entailment, Closure and Equivalence Lossless Decompositions The Third Normal Form (3NF) The Boyce-Codd
More informationDatabase Normalization. Mohua Sarkar, Ph.D Software Engineer California Pacific Medical Center 415-600-7003 sarkarm@sutterhealth.
Database Normalization Mohua Sarkar, Ph.D Software Engineer California Pacific Medical Center 415-600-7003 sarkarm@sutterhealth.org Definition A database is an organized collection of data whose content
More information- Eliminating redundant data - Ensuring data dependencies makes sense. ie:- data is stored logically
Normalization of databases Database normalization is a technique of organizing the data in the database. Normalization is a systematic approach of decomposing tables to eliminate data redundancy and undesirable
More informationDATABASE INTRODUCTION
Introduction The history of database system research is one of exceptional productivity and startling economic impact. We have learnt that from the days of file-based systems there are better ways to handle
More informationIntroduction to Microsoft Jet SQL
Introduction to Microsoft Jet SQL Microsoft Jet SQL is a relational database language based on the SQL 1989 standard of the American Standards Institute (ANSI). Microsoft Jet SQL contains two kinds of
More informationDatabase Design and the Reality of Normalisation
Proceedings of the NACCQ 2000 Wellington NZ www.naccq.ac.nz Database Design and the Reality of Normalisation Dave Kennedy ABSTRACT Institute of Technology Christchurch Polytechnic Te Whare Runanga O Otautahi
More information14 Databases. Source: Foundations of Computer Science Cengage Learning. Objectives After studying this chapter, the student should be able to:
14 Databases 14.1 Source: Foundations of Computer Science Cengage Learning Objectives After studying this chapter, the student should be able to: Define a database and a database management system (DBMS)
More informationConceptual Design: Entity Relationship Models. Objectives. Overview
Conceptual Design: Entity Relationship Models Craig Van Slyke, University of Central Florida cvanslyke@bus.ucf.edu John Day, Ohio University Objectives Define terms related to entity relationship modeling,
More informationDatabases -Normalization III. (N Spadaccini 2010 and W Liu 2012) Databases - Normalization III 1 / 31
Databases -Normalization III (N Spadaccini 2010 and W Liu 2012) Databases - Normalization III 1 / 31 This lecture This lecture describes 3rd normal form. (N Spadaccini 2010 and W Liu 2012) Databases -
More informationDatabase Concepts II. Top down V Bottom up database design. database design (Cont) 3/22/2010. Chapter 4
Chapter 4 Database Concepts II Prepared by Kent Wilson University of South Australia Top down V Bottom up database design Entity relationship diagram presents top down view Normalisation looks at the bottom
More informationChapter 5: FUNCTIONAL DEPENDENCIES AND NORMALIZATION FOR RELATIONAL DATABASES
1 Chapter 5: FUNCTIONAL DEPENDENCIES AND NORMALIZATION FOR RELATIONAL DATABASES INFORMAL DESIGN GUIDELINES FOR RELATION SCHEMAS We discuss four informal measures of quality for relation schema design in
More informationCS143 Notes: Normalization Theory
CS143 Notes: Normalization Theory Book Chapters (4th) Chapters 7.1-6, 7.8, 7.10 (5th) Chapters 7.1-6, 7.8 (6th) Chapters 8.1-6, 8.8 INTRODUCTION Main question How do we design good tables for a relational
More informationLecture 2 Normalization
MIT 533 ระบบฐานข อม ล 2 Lecture 2 Normalization Walailuk University Lecture 2: Normalization 1 Objectives The purpose of normalization The identification of various types of update anomalies The concept
More informationSAMPLE FINAL EXAMINATION SPRING SESSION 2015
SAMPLE FINAL EXAMINATION SPRING SESSION 2015 School of Computing, Engineering and Mathematics Student family name: Student given name/s: Student ID number: Course: Unit Name (In Full): Database Design
More informationDATABASE DESIGN: Normalization Exercises & Answers
DATABASE DESIGN: Normalization Exercises & Answers (a) The table shown in Figure 1 is susceptible to update anomalies. Provide examples of insertion, deletion, and modification anomalies. Answers: This
More informationFunctional Dependencies and Finding a Minimal Cover
Functional Dependencies and Finding a Minimal Cover Robert Soulé 1 Normalization An anomaly occurs in a database when you can update, insert, or delete data, and get undesired side-effects. These side
More informationDatabase Design and Normalization
Database Design and Normalization CPS352: Database Systems Simon Miner Gordon College Last Revised: 9/27/12 Agenda Check-in Functional Dependencies (continued) Design Project E-R Diagram Presentations
More informationNormalization. Functional Dependence. Normalization. Normalization. GIS Applications. Spring 2011
Normalization Normalization Normalization is a foundation for relational database design Systematic approach to efficiently organize data in a database GIS Applications Spring 2011 Objectives Minimize
More informationMCQs~Databases~Relational Model and Normalization http://en.wikipedia.org/wiki/database_normalization
http://en.wikipedia.org/wiki/database_normalization Database normalization is the process of organizing the fields and tables of a relational database to minimize redundancy. Normalization usually involves
More informationDatabase Design and Implementation
Database Design and Implementation A practical introduction using Oracle SQL Howard Gould 1 Introduction These slides accompany the book Database Design and Implementation A practical introduction using
More informationNormal forms and normalization
Normal forms and normalization An example of normalization using normal forms We assume we have an enterprise that buys products from different supplying companies, and we would like to keep track of our
More informationRelational Data Analysis I
Relational Data Analysis I Relational Data Analysis Prepares Business data for representation using the relational model The relational model is implemented in a number of popular database systems Access
More informationBCA. Database Management System
BCA IV Sem Database Management System Multiple choice questions 1. A Database Management System (DBMS) is A. Collection of interrelated data B. Collection of programs to access data C. Collection of data
More informationDatabase Design and Normal Forms
Database Design and Normal Forms Database Design coming up with a good schema is very important How do we characterize the goodness of a schema? If two or more alternative schemas are available how do
More informationIf it's in the 2nd NF and there are no non-key fields that depend on attributes in the table other than the Primary Key.
Normalization First Normal Form (1st NF) The table cells must be of single value. Eliminate repeating groups in individual tables. Create a separate table for each set of related data. Identify each set
More informationDesign of Relational Database Schemas
Design of Relational Database Schemas T. M. Murali October 27, November 1, 2010 Plan Till Thanksgiving What are the typical problems or anomalies in relational designs? Introduce the idea of decomposing
More informationUnit 3.1. Normalisation 1 - V2.0 1. Normalisation 1. Dr Gordon Russell, Copyright @ Napier University
Normalisation 1 Unit 3.1 Normalisation 1 - V2.0 1 Normalisation Overview discuss entity integrity and referential integrity describe functional dependency normalise a relation to first formal form (1NF)
More informationRELATIONAL DATABASE DESIGN
RELATIONAL DATABASE DESIGN g Good database design - Avoiding anomalies g Functional Dependencies g Normalization & Decomposition Using Functional Dependencies g 1NF - Atomic Domains and First Normal Form
More informationA. TRUE-FALSE: GROUP 2 PRACTICE EXAMPLES FOR THE REVIEW QUIZ:
GROUP 2 PRACTICE EXAMPLES FOR THE REVIEW QUIZ: Review Quiz will contain very similar question as below. Some questions may even be repeated. The order of the questions are random and are not in order of
More informationDatabase Normalization as a By-product of Minimum Message Length Inference
Database Normalization as a By-product of Minimum Message Length Inference David L. Dowe and Nayyar A. Zaidi Clayton School of I.T., Monash University, Clayton, Vic. 3800, Australia {david.dowe,nayyar.zaidi}@infotech.monash.edu.au
More informationRelational Database Basics Review
Relational Database Basics Review IT 4153 Advanced Database J.G. Zheng Spring 2012 Overview Database approach Database system Relational model Database development 2 File Processing Approaches Based on
More informationNormalisation 1. Chapter 4.1 V4.0. Copyright @ Napier University
Normalisation 1 Chapter 4.1 V4.0 Copyright @ Napier University Normalisation Overview discuss entity integrity and referential integrity describe functional dependency normalise a relation to first formal
More informationNormalization of Database Tables. Functional Dependency. Examples of Functional Dependencies: So Now what is Normalization? Transitive Dependencies
ISM 602 Dr. Hamid Nemati Objectives The idea Dependencies Attributes and Design Understand concepts normaization (Higher-Leve Norma Forms) Learn how to normaize tabes Understand normaization and database
More informationChapter 7: Relational Database Design
Chapter 7: Relational Database Design Database System Concepts, 5th Ed. See www.db book.com for conditions on re use Chapter 7: Relational Database Design Features of Good Relational Design Atomic Domains
More informationIntroduction to Computing. Lectured by: Dr. Pham Tran Vu t.v.pham@cse.hcmut.edu.vn
Introduction to Computing Lectured by: Dr. Pham Tran Vu t.v.pham@cse.hcmut.edu.vn Databases The Hierarchy of Data Keys and Attributes The Traditional Approach To Data Management Database A collection of
More informationThe Relational Model. Ramakrishnan&Gehrke, Chapter 3 CS4320 1
The Relational Model Ramakrishnan&Gehrke, Chapter 3 CS4320 1 Why Study the Relational Model? Most widely used model. Vendors: IBM, Informix, Microsoft, Oracle, Sybase, etc. Legacy systems in older models
More informationThe Relational Database Model
The Relational Database Model 1 Describing how to tune a relational database model would not be complete without a description of normalization. I have attempted to simplify normalization. When I attended
More informationThe Relational Data Model and Relational Database Constraints
The Relational Data Model and Relational Database Constraints Chapter Outline Relational Model Concepts Relational Model Constraints and Relational Database Schemas Update Operations and Dealing with Constraint
More informationCSCI-GA.2433-001 Database Systems Lecture 7: Schema Refinement and Normalization
CSCI-GA.2433-001 Database Systems Lecture 7: Schema Refinement and Normalization Mohamed Zahran (aka Z) mzahran@cs.nyu.edu http://www.mzahran.com View 1 View 2 View 3 Conceptual Schema At that point we
More informationLecture Notes on Database Normalization
Lecture Notes on Database Normalization Chengkai Li Department of Computer Science and Engineering The University of Texas at Arlington April 15, 2012 I decided to write this document, because many students
More informationNormalization in OODB Design
Normalization in OODB Design Byung S. Lee Graduate Programs in Software University of St. Thomas St. Paul, Minnesota bslee@stthomas.edu Abstract When we design an object-oriented database schema, we need
More informationDesigning Databases. Introduction
Designing Databases C Introduction Businesses rely on databases for accurate, up-to-date information. Without access to mission critical data, most businesses are unable to perform their normal daily functions,
More informationCarnegie Mellon Univ. Dept. of Computer Science 15-415 - Database Applications. Overview - detailed. Goal. Faloutsos CMU SCS 15-415
Faloutsos 15-415 Carnegie Mellon Univ. Dept. of Computer Science 15-415 - Database Applications Lecture #17: Schema Refinement & Normalization - Normal Forms (R&G, ch. 19) Overview - detailed DB design
More informationThe Relational Model. Why Study the Relational Model? Relational Database: Definitions. Chapter 3
The Relational Model Chapter 3 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 1 Why Study the Relational Model? Most widely used model. Vendors: IBM, Informix, Microsoft, Oracle, Sybase,
More informationData Modeling: Part 1. Entity Relationship (ER) Model
Data Modeling: Part 1 Entity Relationship (ER) Model MBA 8473 1 Cognitive Objectives (Module 2) 32. Explain the three-step process of data-driven information system (IS) development 33. Examine the purpose
More informationFundamentals of Database Design
Fundamentals of Database Design Zornitsa Zaharieva CERN Data Management Section - Controls Group Accelerators and Beams Department /AB-CO-DM/ 23-FEB-2005 Contents : Introduction to Databases : Main Database
More informationRELATIONAL DATABASE DESIGN Good Database Design Principles
Good Database Design Principles 1. no redundancy a field is stored in only one table, unless it happens to be a foreign key replication of foreign keys is permissible, because they allow two tables to
More informationC HAPTER 4 INTRODUCTION. Relational Databases FILE VS. DATABASES FILE VS. DATABASES
INRODUCION C HAPER 4 Relational Databases Questions to be addressed in this chapter: How are s different than file-based legacy systems? Why are s important and what is their advantage? What is the difference
More informationSQL DATA DEFINITION: KEY CONSTRAINTS. CS121: Introduction to Relational Database Systems Fall 2015 Lecture 7
SQL DATA DEFINITION: KEY CONSTRAINTS CS121: Introduction to Relational Database Systems Fall 2015 Lecture 7 Data Definition 2 Covered most of SQL data manipulation operations Continue exploration of SQL
More informationDBMS. Normalization. Module Title?
Normalization Database Normalization Database normalization is the process of removing redundant data from your tables in to improve storage efficiency, data integrity (accuracy and consistency), and scalability
More informationNormalization. Purpose of normalization Data redundancy Update anomalies Functional dependency Process of normalization
Normalization Purpose of normalization Data redundancy Update anomalies Functional dependency Process of normalization 1 Purpose of Normalization Normalization is a technique for producing a set of suitable
More informationEXTENDED LEARNING MODULE A
EXTENDED LEARNING MODULE A DESIGNING DATABASES AND ENTITY- RELATIONSHIP DIAGRAMMING Student Learning Outcomes 1. Identify how databases and spreadsheets are both similar and different. 2. List and describe
More informationWhy & How: Business Data Modelling. It should be a requirement of the job that business analysts document process AND data requirements
Introduction It should be a requirement of the job that business analysts document process AND data requirements Process create, read, update and delete data they manipulate data. Process that aren t manipulating
More informationSQL AND DATA. What is SQL? SQL (pronounced sequel) is an acronym for Structured Query Language, CHAPTER OBJECTIVES
C H A P T E R 1 SQL AND DATA CHAPTER OBJECTIVES In this chapter, you will learn about: Data, Databases, and the Definition of SQL Page 3 Table Relationships Page 15 The STUDENT Schema Diagram Page 37 What
More informationDatabases Model the Real World. The Entity- Relationship Model. Conceptual Design. Steps in Database Design. ER Model Basics. ER Model Basics (Contd.
The Entity- Relationship Model R &G - Chapter 2 A relationship, I think, is like a shark, you know? It has to constantly move forward or it dies. And I think what we got on our hands is a dead shark. Woody
More informationAnnouncements. SQL is hot! Facebook. Goal. Database Design Process. IT420: Database Management and Organization. Normalization (Chapter 3)
Announcements IT0: Database Management and Organization Normalization (Chapter 3) Department coin design contest deadline - February -week exam Monday, February 1 Lab SQL SQL Server: ALTER TABLE tname
More informationER modelling, Weak Entities, Class Hierarchies, Aggregation
CS344 Database Management Systems ER modelling, Weak Entities, Class Hierarchies, Aggregation Aug 2 nd - Lecture Notes (Summary) Submitted by - N. Vishnu Teja Saurabh Saxena 09010125 09010145 (Most the
More informationBusiness Intelligence: Multidimensional Data Analysis
Business Intelligence: Multidimensional Data Analysis Per Westerlund August 20, 2008 Master Thesis in Computing Science 30 ECTS Credits Abstract The relational database model is probably the most frequently
More information