Relational Data Model

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "Relational Data Model"

Transcription

1 CS4710 Introduction to Database Systems Relational Data Model Instructor: Yi-Shin Chen Office: EECS Office Hour: Tu. 1-2PM, Th. 3-4pm Why Study the Relational Model? Most widely used model. Vendors: IBM, Informix, Microsoft, Oracle, Sybase, etc. Recent competitor: object-oriented model ObjectStore, Versant, Ontos A synthesis emerging: object-relational model Informix Universal Server, UniSQL, O2, Oracle, DB2 2007/3/27 Introduction to Database Systems 2 1

2 Relational Model Concepts The relational Model of Data is based on the concept of a Relation A Relation is a mathematical concept based on the ideas of sets The strength of the relational approach to data management comes from the formal foundation provided by the theory of relations 2007/3/27 Introduction to Database Systems 3 Relational Model Concepts (Contd.) The model was first proposed by Dr. E.F. Codd of IBM in 1970 in the following paper: "A Relational Model for Large Shared Data Banks," Communications of the ACM, June 1970 ACM Turing Award 2007/3/27 Introduction to Database Systems 4 2

3 Evolution of Data Management E.F. Codd outlined the relational model Give Database users high-level set-oriented data access operations Relational Databases && Client- Server Computing Uniform representation 1985: first standardized of SQL Unexpected benefit Client-Server Because of SQL, ODBC Parallel processing Relational operators naturally support pipeline and partition parallelism Graphical User Interface Easy to render a relation Oracle, Informix, Ingres Multimedia Databases Richer data types OO databases Unifying procedures and data (Universal Server) Projects that push the limits NASA EOS/DIS projects /3/27 Introduction to Database Systems 5 Relational Data Model Relational data model represents the database as a collection of tables, termed relations, each with a unique name (not to be confused with the relationships in ER model). E.g.: Courses: Course ID CS Name Advanced Database Systems Instructor Yi-Shin Chen Time M3M4W3 CS Operations System Tai-Yi Huang M3M4W2 CS Pattern Recognition Chaur-Chin Chen M7M8T6 A column of a table represents an attribute Each value corresponds to an attribute or a field A row (also termed a or a ) in a table represents a collection of related values 2007/3/27 Introduction to Database Systems 6 3

4 Mathematical Concept of Relation The concept of table the mathematical concept of relation Given a relation with attributes ( ) The domain of this relation is A domain may have a data-type or a format defined for it. The phone_numbers may have a format: (dd)-ddd-dddd where each d is a decimal digit. E.g., Dates have various formats such as month_name, date, year or yyyy-mm-dd, or dd mm,yyyy etc. The relation (or table) is a subset of this domain E.g., Student(S#: string(ldddddd), name: string(30), BD: date(yyyy-mm-dd)) Domain: Let t refers to a tuple in the relation, the value of an attribute contained in t can be accessed by: t[attr-name] E.g., t[s#], or t[bd] 2007/3/27 Introduction to Database Systems 7 Mathematical Concept of Relation (Contd.) Database schema: The logical design of the data The Schema of a Relation: R (A 1, A 2,...A n ) Relation schema R is defined over attributes A 1, A 2,...A n Database instance The data in the database at a given instant in time Course ID Name Instructor Time CS Advanced Database Systems Yi-Shin Chen M3M4W3 CS Operations System Tai-Yi Huang M3M4W2 CS Pattern Recognition Chaur-Chin Chen M7M8T6 2007/3/27 Introduction to Database Systems 8 4

5 Definition Summary Informal Terms Formal Terms Relation Attribute/Domain Tuple Domain Schema of a Relation 2007/3/27 Introduction to Database Systems 9 Characteristics Of Relations Ordering of tuples in a relation r(r): The tuples are NOT considered to be ORDERED, even though they appear to be in the tabular form. Ordering of attributes in a relation schema R (and of values within each tuple): We will consider the attributes in R(A1, A2,..., An) and the values in t=<v1, v2,..., vn> to be ordered. However, a more general alternative definition of relation does not require this ordering Values in a tuple: All values are considered atomic (indivisible). A special null value is used to represent values that are unknown or inapplicable to certain tuples 2007/3/27 Introduction to Database Systems 10 5

6 Relational Integrity Constraints Constraints are conditions that must hold on all valid relation instances. There are three main types of constraints: Key constraints Entity integrity constraints Referential integrity constraints 2007/3/27 Introduction to Database Systems 11 Various Types of Constraints Domain constraints: Value of each attribute A must be an atomic value from the domain for that attribute E.g., Age: integer; 4 is acceptable and 4.3 is not Key constraints: All tuples in a relation must be distinct No two tuples can have the same Combination of values for all their attributes Superkey, candidate key, and primary key 2007/3/27 Introduction to Database Systems 12 6

7 Key Constraints Superkey of R A set of attributes SK of R such that no two tuples in any valid relation instance r(r) will have the same value for SK. That is, for any distinct tuples t1 and t2 in r(r), t1[sk] t2[sk]. Candidate key of R A "minimal" superkey; that is, a superkey K such that removal of any attribute from K results in a set of attributes that is not a superkey. Example: The CAR relation schema: CAR(State, Reg#, SerialNo, Make, Model, Year) has two keys Key1 = {State, Reg#}, Key2 = {SerialNo}, which are also superkeys. {SerialNo, Make} is a superkey but not a candidate key If a relation has several candidate keys, one is chosen arbitrarily to be the primary key. The primary key attributes are underlined 2007/3/27 Introduction to Database Systems 13 Example 2007/3/27 Introduction to Database Systems 14 7

8 Entity Integrity Constraint No primary key value can be null Entity Integrity: The primary key attributes PK of each relation schema R in S cannot have null values in any tuple of r(r) This is because primary key values are used to identify the individual tuples. t[pk] null for any tuple t in r(r) Note: Other attributes of R may be similarly constrained to disallow null values, even though they are not members of the primary key 2007/3/27 Introduction to Database Systems 15 Issues Different attribute names refer to the same concept Cannot be forced to have the same name Same attribute names might refer to different concepts Course Faculty Course ID Name Instructor# Faculty# Name Dept. Some sort of regulation (or constraint) required 2007/3/27 Introduction to Database Systems 16 8

9 Referential Integrity Constraint A tuple in one relation that refers to another relation must refer to an existing tuple in that relation, or null E.g., value of Instructor# for Course must match the Faculty# value of some tuple in Faculty Set of attributes foreign key (FK) in R1 is foreign key of R1 if Attributes in FK have the same domain as the primary key attributes PK of relation R2 A value of FK in a tuple t1 of R1 either occurs as a value of PK for some tuple t2 in R2 or is null Course Course ID Name Instructor# Faculty Faculty# Name Supervisor# A foreign key can refer to its own relation Circular referential integrity constraints are allowed 2007/3/27 Introduction to Database Systems 17 Other Types of Constraints Semantic Integrity Constraints: Based on application semantics and cannot be expressed by the model E.g., the max. no. of hours per employee for all projects he or she works on is 56 hrs per week A constraint specification language may have to be used to express these SQL-99 allows triggers and ASSERTIONS to allow for some of these 2007/3/27 Introduction to Database Systems 18 9

10 COMPANY Example 2007/3/27 Introduction to Database Systems 19 COMPANY Example (Contd.) 2007/3/27 Introduction to Database Systems 20 10

11 COMPANY Example (Contd.) 2007/3/27 Introduction to Database Systems 21 ER-to-Relational Mapping ER-to-Relational Mapping Algorithm Step 1: Mapping of Regular (Strong) Entity Types Step 2: Mapping of Weak Entity Types Step 3: Mapping of Binary M:N Relationship Types Step 4: Mapping of Binary 1:1 Relation Types Step 5: Mapping of Binary 1:N Relationship Types Step 6: Mapping of Multivalued attributes Step 7: Mapping of Composite attributes Step 8: Mapping of High-Level Entities (Optional) Combine/Spilt Tables Mapping EER Model Constructs to Relations Step 9: Options for Mapping Specialization or Generalization Step 10: Mapping of Union Types (Categories) 2007/3/27 Introduction to Database Systems 22 11

12 Step 1: Mapping of Strong Entity Types For each strong entity set Each becomes a (table) Each attribute becomes a The identifying attribute becomes the If the chosen key of E is composite, the set of simple attributes that form it will together form the primary key of R SID Name CID Time Student Enrolled Class 2007/3/27 Introduction to Database Systems 23 Step 2: Mapping of Weak Entity Types For each weak entity set Each becomes a ; Each attribute becomes a The primary key of this relation comes from: The primary key of the owner entity set The identifying attribute of this weak entity set AID Balance TID Date Amount Account has Transaction 2007/3/27 Introduction to Database Systems 24 12

13 Step 3: Mapping of Binary M:N Relationship Types For each M:N relationship set Each becomes a relation Each attribute becomes a column The primary keys of associated entity sets become the of this relation SID Name CID Time Student Enrolled Class 2007/3/27 Introduction to Database Systems 25 Step 4: Mapping of Binary 1:1 Relation Types For each 1:1 relationship set Each becomes a relation; Each attribute becomes a column Pick the primary key from set as primary key; the primary keys of others become non-key columns SID Name AID Dep# 1 1 Student Advise Advisor 2007/3/27 Introduction to Database Systems 26 13

14 Step 5: Mapping of Binary 1:N Relationship Types For each 1:N relationship set Each becomes a relation; Each attribute becomes a column The primary key of entity set becomes the primary key The primary key of entity set becomes a non-key column SID Name AID Dep# Student Advise N 1 Advisor 2007/3/27 Introduction to Database Systems 27 Step 6: Mapping of Multivalued Attributes For each multivalued attribute Each becomes a relation; Each attribute becomes a column The primary key of this relation comes from: The primary key of SID Name Address Major Student 2007/3/27 Introduction to Database Systems 28 14

15 Step 7: Mapping of Composite Attributes For each composite attribute Each becomes a relation; Each value becomes a column The primary key of the owner entity set becomes the primary key Street City State Zip code SID Name Address Major Student 2007/3/27 Introduction to Database Systems 29 Step 8: Mapping of High-Level Entities For each high-level entity set Each becomes a relation; Each attribute becomes a column Does it have its own identifier? No follow the same procedures as relationship sets Yes Use its identifier as primary key; the primary keys of its associated entity sets as non-key columns SID Name CID Time Student Enrolled Class 2007/3/27 Introduction to Database Systems 30 15

16 Combine/Spilt Tables (Optional) Remove one-column tables Use referential integrity instead Combine tables with the same primary key Careful! It might result in lower normal form Spilt a table into multiple tables, to maximize the operational efficiency The above procedures should be done examining the properties/characteristics/behaviors of the tables and data!! 2007/3/27 Introduction to Database Systems 31 Enforce Referential Integrity Consider the following example: Class Student SID Name CID Time CID Time SID Name Student Enrolled Class Enrolled SID CID What should be done if an Enrolled tuple with a non-existent student id is inserted? What should be done if a Student tuple is deleted? Delete all Enrolled tuples that refer to it Disallow deletion of a Student tuple that is referred to Set SID in Enrolled tuples that refer to it to a default SID Set SID in Enrolled tuples that refer to it to a special value null, denoting unknown or inapplicable What should be done if primary key of Student tuple is updated? 2007/3/27 Introduction to Database Systems 32 16

17 Summary Of Mapping Constructs And Constraints Table 7.1 Correspondence between ER and Relational Models ER Model Relational Model Entity type Entity relation 1:1 or 1:N relationship type Foreign key (or relationship relation) M:N relationship type Relationship relation and two foreign keys n-ary relationship type Relationship relation and n foreign keys Simple attribute Attribute Composite attribute Set of simple component attributes Multivalued attribute Relation and foreign key Value set Domain Key attribute Primary (or secondary) key 2007/3/27 Introduction to Database Systems 33 Step 9: Options for Mapping Specialization (Option 1) One table for superclass + one table for each subclasses Each table consists of Its corresponding attributes Primary key of the superclass Sex Name ID Address DoB Person O Employee Alumnus Student Salary Class Major 2007/3/27 Introduction to Database Systems 34 17

18 Step 9: Options for Mapping Specialization (Option 2) Same as option 1, but without creating a table for the superclass Only if specialization is both disjoint and total Sex Name ID Address DoB Person d Employee Alumnus Student Salary Class Major 2007/3/27 Introduction to Database Systems 35 Step 9: Options for Mapping Specialization (Option 3) A singles table including: All the attributes of the superclass and all subclasses An extra type attribute t to indicate the subclass to which each tuple belongs Only if specialization is disjoint Name ID Sex Employee d Job type Secretary Faculty Technician Typing Speed Dept Specialty 2007/3/27 Introduction to Database Systems 36 18

19 Step 9: Options for Mapping Specialization (Option 4) Same as option 3 except there are m Boolean type attributes, one for each subclass This option can support overlap specialization Name ID Sex Employee o Job type Secretary Faculty Technician Typing Speed Dept Specialty 2007/3/27 Introduction to Database Systems 37 Step 10: Mapping of Union Types (Categories) One table for the category + one table for each superclasses Each table consists of Its corresponding attributes Primary key of the category Investment Sex ID Name Name ID Company Person Bank ID U Owner 2007/3/27 Introduction to Database Systems 38 19

20 FIGURE 7.1 The ER conceptual schema diagram for the COMPANY database. COMPANY Example 2007/3/27 Introduction to Database Systems 39 COMPANY Example (Contd.) FIGURE 7.2 Result of mapping the COMPANY ER schema into a relational schema. 2007/3/27 Introduction to Database Systems 40 20

21 JobType Example FIGURE 4.4 EER diagram notation for an attribute-defined specialization on JobType. 2007/3/27 Introduction to Database Systems 41 JobType Example (Contd.) FIGURE 7.4 Options for mapping specialization or generalization. (a) Mapping the EER schema in Figure 4.4 using option 8A. 2007/3/27 Introduction to Database Systems 42 21

22 UNIVERSITY Example FIGURE 4.7 A specialization lattice with multiple inheritance for a UNIVERSITY database. 2007/3/27 Introduction to Database Systems 43 UNIVERSITY Example (Contd.) FIGURE 7.5 Mapping the EER specialization lattice in Figure 4.6 using multiple options. 2007/3/27 Introduction to Database Systems 44 22

23 OWNER Example FIGURE 4.8 Two categories (union types): OWNER and REGISTERED_VEHICLE. 2007/3/27 Introduction to Database Systems 45 OWNER Example (Contd.) FIGURE 7.6 Mapping the EER categories (union types) in Figure 4.7 to relations. 2007/3/27 Introduction to Database Systems 46 23

24 Informal Design Guidelines for Relational Databases GUIDELINE 1: Informally, each tuple in a relation should represent one entity or relationship instance Attributes of different entities should not be mixed in the same relation Only foreign keys should be used to refer to other entities Entity and relationship attributes should be kept apart as much as possible. Bottom Line: Design a schema that can be explained easily relation by relation. The semantics of attributes should be easy to interpret 2007/3/27 Introduction to Database Systems 47 Informal Design Guidelines (Contd.) Mixing attributes of multiple entities may cause problems Information is stored redundantly wasting storage Problems with update anomalies Insertion anomalies Deletion anomalies Modification anomalies 2007/3/27 Introduction to Database Systems 48 24

25 Update Anomalies Consider the relation: EMP_PROJ ( Emp#, Proj#, Ename, Pname, No_hours) Update Anomaly: Changing the name of project number P1 from Billing to Customer-Accounting may cause this update to be made for all 100 employees working on project P1 Insert Anomaly: Cannot insert a project unless an employee is assigned to Inversely - Cannot insert an employee unless an he/she is assigned to a project. Delete Anomaly: When a project is deleted, it will result in deleting all the employees who work on that project. Alternately, if an employee is the sole employee on a project, deleting that employee would result in deleting the corresponding project. 2007/3/27 Introduction to Database Systems 49 Informal Design Guidelines (Contd.) GUIDELINE 2: Design a schema that does not suffer from the insertion, deletion and update anomalies If there are any present, then note them so that applications can be made to take them into account 2007/3/27 Introduction to Database Systems 50 25

26 Informal Design Guidelines (Contd.) GUIDELINE 3: Relations should be designed such that their tuples will have as few NULL values as possible Attributes that are NULL frequently could be placed in separate relations (with the primary key) Reasons for nulls: attribute not applicable or invalid attribute value unknown (may exist) value known to exist, but unavailable 2007/3/27 Introduction to Database Systems 51 Informal Design Guidelines (Contd.) Bad designs for a relational database may result in erroneous results for certain JOIN operations The "lossless join" property is used to guarantee meaningful results for join operations GUIDELINE 4: The relations should be designed to satisfy the lossless join condition. No spurious tuples should be generated by doing a natural-join of any relations. 2007/3/27 Introduction to Database Systems 52 26

27 Spurious Tuples There are two important properties of decompositions: (a) non-additive or losslessness of the corresponding join (b) preservation of the functional dependencies. Note that property (a) is extremely important and cannot be sacrificed Property (b) is less stringent and may be sacrificed 2007/3/27 Introduction to Database Systems 53 Functional Dependencies Functional dependencies (FDs) are used to specify formal measures of the "goodness" of relational designs X Y holds if whenever two tuples have the same value for X, they must have the same value for Y For any two tuples t1 and t2 in any relation instance r(r): X Y in R specifies a constraint on all relation instances r(r) FDs are derived from the real-world constraints on the attributes 2007/3/27 Introduction to Database Systems 54 27

28 Examples of FD constraints Social security number determines employee name Project number determines project name and location Employee SSN and project number determines the hours per week that the employee works on the project 2007/3/27 Introduction to Database Systems 55 Inference Rules Given a set of FDs F, we can infer additional FDs that hold whenever the FDs in F hold Armstrong's inference rules: IR1. (Reflexive) If Y subset-of X, then X Y IR2. (Augmentation) If X -> Y, then XZ YZ (Notation: XZ stands for X U Z) IR3. (Transitive) If X Y and Y Z, then X Z IR1, IR2, IR3 form a sound and complete set of inference rules 2007/3/27 Introduction to Database Systems 56 28

29 Equivalence of Sets of FDs Two sets of FDs F and G are equivalent if: - every FD in F can be inferred from G, and - every FD in G can be inferred from F Hence, F and G are equivalent if F + =G + Definition: F covers G if every FD in G can be inferred from F (i.e., if G + subset-of F + ) F and G are equivalent if F covers G and G covers F There is an algorithm for checking equivalence of sets of FDs 2007/3/27 Introduction to Database Systems 57 Minimal Sets of FDs A set of FDs is minimal if it satisfies the following conditions: (1) Every dependency in F has a single attribute for its RHS. (2) We cannot remove any dependency from F and have a set of dependencies that is equivalent to F. (3) We cannot replace any dependency X A in F with a dependency Y A, where Y proper-subset-of X ( Y subset-of X) and still have a set of dependencies that is equivalent to F Every set of FDs has an equivalent minimal set There can be several equivalent minimal sets There is no simple algorithm for computing a minimal set of FDs that is equivalent to a set F of FDs To synthesize a set of relations, we assume that we start with a set of dependencies that is a minimal set 2007/3/27 Introduction to Database Systems 58 29

30 Normalization of Relations Normalization: The process of decomposing unsatisfactory "bad" relations by breaking up their attributes into smaller relations Normal form: Condition using keys and FDs of a relation to certify whether a relation schema is in a particular normal form 2007/3/27 Introduction to Database Systems 59 Normalization of Relations (Contd.) 2NF, 3NF, BCNF based on keys and FDs of a relation schema 4NF based on keys, multi-valued dependencies 5NF based on keys, join dependencies Additional properties may be needed to ensure a good relational design 2007/3/27 Introduction to Database Systems 60 30

31 Practical Use of Normal Forms Normalization is carried out in practice so that the resulting designs are of high quality and meet the desirable properties The practical utility of these normal forms becomes questionable when the constraints on which they are based are hard to understand or to detect The database designers need not normalize to the highest possible normal form Usually up to 3NF, BCNF or 4NF Denormalization: the process of storing the join of higher normal form relations as a base relation which is in a lower normal form 2007/3/27 Introduction to Database Systems 61 Review: Definitions of Keys A superkey of a relation schema R = {A 1, A 2,..., A n } is a set of attributes S subset-of R with the property that no two tuples t 1 and t 2 in any legal relation state r of R will have t 1 [S] = t 2 [S] A key K is a superkey with the additional property that removal of any attribute from K will cause K not to be a superkey any more. 2007/3/27 Introduction to Database Systems 62 31

32 Review: Definitions of Keys (Contd.) If a relation schema has more than one key, each is called a candidate key. One of the candidate keys is arbitrarily designated to be the primary key, and the others are called secondary keys. A Prime attribute must be a member of some candidate key A Nonprime attribute is not a prime attribute that is, it is not a member of any candidate key 2007/3/27 Introduction to Database Systems 63 First Normal Form All occurrences of a record type must contain the same number of fields Disallows composite attributes, multivalued attributes, and nested relations; attributes whose values for an individual tuple are non-atomic 2007/3/27 Introduction to Database Systems 64 32

33 Normalization into 1NF 2007/3/27 Introduction to Database Systems 65 Second Normal Form Non-key field cannot be a subset of the primary key Uses the concepts of FDs, primary key A relation schema R is in second normal form (2NF) if every nonprime attribute A in R is fully functionally dependent on the primary key Full functional dependency A FD Y Z where removal of any attribute from Y means the FD does not hold any more E.g.: {SSN, PNUMBER} -> HOURS is a full FD since {SSN, PNUMBER} -> ENAME is not a full FD (it is called a partial dependency ) since 2007/3/27 Introduction to Database Systems 66 33

34 Normalization into 2NF 2007/3/27 Introduction to Database Systems 67 Third Normal Form All attributes that are not dependent upon the primary key must be eliminated A relation schema R is in third normal form (3NF) if it is in 2NF and no non-prime attribute A in R is transitively dependent on the primary key Transitive functional dependency A FD X Z that can be derived from two FDs Examples: SSN -> DMGRSSN is a transitive FD since X Y and Y Z SSN -> ENAME is non-transitive since there is no set of attributes X where 2007/3/27 Introduction to Database Systems 68 34

35 Normalization into 3NF 2007/3/27 Introduction to Database Systems 69 BCNF (Boyce-Codd Normal Form) A relation schema R is in Boyce-Codd Normal Form (BCNF) if whenever an FD X A holds in R, then X is a superkey of R Each normal form is strictly stronger than the previous one Every 2NF relation is in 1NF Every 3NF relation is in 2NF Every BCNF relation is in 3NF There exist relations that are in 3NF but not in BCNF The goal is to have each relation in BCNF (or 3NF) 2007/3/27 Introduction to Database Systems 70 35

36 3NF Example But Not in BCNF 2007/3/27 Introduction to Database Systems 71 Fourth Normal Form A record type should not contain two or more independent multi-values facts about an entity A relation schema R is in 4NF with respect to a set of dependencies F (that includes functional dependencies and multivalued dependencies) if, for every nontrivial multivalued dependency X Y in F+, X is a superkey for R 2007/3/27 Introduction to Database Systems 72 36

37 Normalization into 4NF 2007/3/27 Introduction to Database Systems 73 Fifth Normal Form A record type cannot be reconstructed from several smaller record types A relation schema R is in fifth normal form (5NF) (or Project-Join Normal Form (PJNF)) with respect to a set F of functional, multivalued, and join dependencies if, for every nontrivial join dependency JD(R 1, R 2,..., R n ) in F + (that is, implied by F), every R i is a superkey of R. 2007/3/27 Introduction to Database Systems 74 37

38 Normalization into 5NF 2007/3/27 Introduction to Database Systems 75 Summary of Five Normal Forms 1. All occurrences of a record type must contain the same number of fields 2. Non-key field cannot be a subset of the primary key 3. All attributes that are not dependent upon the primary key must be eliminated 4. A record type should not contain two or more independent multi-values facts about an entity 5. A record type cannot be reconstructed from several smaller record types 2007/3/27 Introduction to Database Systems 76 38

39 Five Normal Form (Contd.) Employee Skill Language Part Warehouse Quantity Warehouse-Address Employee Department Location Agent Company Product Smith Ford Car. Smith Ford truck. Smith GM car. Jones Ford Car 2007/3/27 Introduction to Database Systems 77 39

Chapter 10 Functional Dependencies and Normalization for Relational Databases

Chapter 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 information

Theory of Relational Database Design and Normalization

Theory 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 information

Theory of Relational Database Design and Normalization

Theory 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 information

Chapter 10. Functional Dependencies and Normalization for Relational Databases

Chapter 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 information

Chapter 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. 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 information

The Relational Model. Why Study the Relational Model? Relational Database: Definitions. Chapter 3

The 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 information

The Relational Data Model and Relational Database Constraints

The 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 information

CS 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 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 information

The Relational Model. Ramakrishnan&Gehrke, Chapter 3 CS4320 1

The 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 information

Chapter 10, Functional Dependencies and Normalization for Relational Databases

Chapter 10, Functional Dependencies and Normalization for Relational Databases Chapter 10, Functional Dependencies and Normalization for Relational Databases We need some formal measure of why the choice of attributes for a relation schema may be better than another. Functional dependencies

More information

The Relational Model. Why Study the Relational Model? Relational Database: Definitions

The Relational Model. Why Study the Relational Model? Relational Database: Definitions The Relational Model Database Management Systems, R. Ramakrishnan and J. Gehrke 1 Why Study the Relational Model? Most widely used model. Vendors: IBM, Microsoft, Oracle, Sybase, etc. Legacy systems in

More information

Database Management System

Database 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 information

Functional Dependency and Normalization for Relational Databases

Functional 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 information

The Relational Model. Why Study the Relational Model?

The Relational Model. Why Study the Relational Model? The Relational Model Chapter 3 Instructor: Vladimir Zadorozhny vladimir@sis.pitt.edu Information Science Program School of Information Sciences, University of Pittsburgh 1 Why Study the Relational Model?

More information

Chapter 15 Basics of Functional Dependencies and Normalization for Relational Databases

Chapter 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 information

COSC344 Database Theory and Applications. Lecture 9 Normalisation. COSC344 Lecture 9 1

COSC344 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 information

EECS 647: Introduction to Database Systems

EECS 647: Introduction to Database Systems EECS 647: Introduction to Database Systems Instructor: Luke Huan Spring 2013 Administrative Take home background survey is due this coming Friday The grader of this course is Ms. Xiaoli Li and her email

More information

Lecture 6. SQL, Logical DB Design

Lecture 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 information

Chapter 5: FUNCTIONAL DEPENDENCIES AND NORMALIZATION FOR RELATIONAL DATABASES

Chapter 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 information

CS2Bh: Current Technologies. Introduction to XML and Relational Databases. The Relational Model. The relational model

CS2Bh: Current Technologies. Introduction to XML and Relational Databases. The Relational Model. The relational model CS2Bh: Current Technologies Introduction to XML and Relational Databases Spring 2005 The Relational Model CS2 Spring 2005 (LN6) 1 The relational model Proposed by Codd in 1970. It is the dominant data

More information

Schema Refinement, Functional Dependencies, Normalization

Schema 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 information

Database Design and Normal Forms

Database 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 information

1 the relational data model The relational model of data was introduced by E.F. Codd (1970). 1.1 relational model concepts The relational model repres

1 the relational data model The relational model of data was introduced by E.F. Codd (1970). 1.1 relational model concepts The relational model repres database systems formal definitions of the relational data model [03] s. yurttaοs 1 1 the relational data model The relational model of data was introduced by E.F. Codd (1970). 1.1 relational model concepts

More information

Schema Design and Normal Forms Sid Name Level Rating Wage Hours

Schema Design and Normal Forms Sid Name Level Rating Wage Hours Entity-Relationship Diagram Schema Design and Sid Name Level Rating Wage Hours Database Management Systems, 2 nd Edition. R. Ramakrishnan and J. Gehrke 1 Database Management Systems, 2 nd Edition. R. Ramakrishnan

More information

Relational Database Design

Relational Database Design Relational Database Design To generate a set of relation schemas that allows - to store information without unnecessary redundancy - to retrieve desired information easily Approach - design schema in appropriate

More information

CSC 742 Database Management Systems

CSC 742 Database Management Systems CSC 742 Database Management Systems Topic #4: Data Modeling Spring 2002 CSC 742: DBMS by Dr. Peng Ning 1 Phases of Database Design Requirement Collection/Analysis Functional Requirements Functional Analysis

More information

Relational Database Design Theory

Relational Database Design Theory Relational Database Design Theory Informal guidelines for good relational designs Functional dependencies Normal forms and normalization 1NF, 2NF, 3NF BCNF, 4NF, 5NF Inference rules on functional dependencies

More information

Database Design. Marta Jakubowska-Sobczak IT/ADC based on slides prepared by Paula Figueiredo, IT/DB

Database 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 information

Chapter 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. 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 information

Why Is This Important? Schema Refinement and Normal Forms. The Evils of Redundancy. Functional Dependencies (FDs) Example (Contd.)

Why Is This Important? Schema Refinement and Normal Forms. The Evils of Redundancy. Functional Dependencies (FDs) Example (Contd.) Why Is This Important? Schema Refinement and Normal Forms Chapter 19 Many ways to model a given scenario in a database How do we find the best one? We will discuss objective criteria for evaluating database

More information

Outline. Data Modeling. Conceptual Design. ER Model Basics: Entities. ER Model Basics: Relationships. Ternary Relationships. Yanlei Diao UMass Amherst

Outline. Data Modeling. Conceptual Design. ER Model Basics: Entities. ER Model Basics: Relationships. Ternary Relationships. Yanlei Diao UMass Amherst Outline Data Modeling Yanlei Diao UMass Amherst v Conceptual Design: ER Model v Relational Model v Logical Design: from ER to Relational Slides Courtesy of R. Ramakrishnan and J. Gehrke 1 2 Conceptual

More information

Normalization in Database Design

Normalization 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 information

Enhanced-ER Data Model

Enhanced-ER Data Model CS4710 Introduction to Database Systems Enhanced-ER Data Model Instructor: Yi-Shin Chen Office: EECS 3201 Email: yishin@cs.nthu.edu.tw Office Hour: Tu. 1-2PM, Th. 3-4pm Motivation ER data model is useful

More information

Database Design and Normalization

Database 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 information

Data Modeling. Database Systems: The Complete Book Ch. 4.1-4.5, 7.1-7.4

Data Modeling. Database Systems: The Complete Book Ch. 4.1-4.5, 7.1-7.4 Data Modeling Database Systems: The Complete Book Ch. 4.1-4.5, 7.1-7.4 Data Modeling Schema: The structure of the data Structured Data: Relational, XML-DTD, etc Unstructured Data: CSV, JSON But where does

More information

Limitations of E-R Designs. Relational Normalization Theory. Redundancy and Other Problems. Redundancy. Anomalies. Example

Limitations of E-R Designs. Relational Normalization Theory. Redundancy and Other Problems. Redundancy. Anomalies. Example Limitations of E-R Designs Relational Normalization Theory Chapter 6 Provides a set of guidelines, does not result in a unique database schema Does not provide a way of evaluating alternative schemas Normalization

More information

A. TRUE-FALSE: GROUP 2 PRACTICE EXAMPLES FOR THE REVIEW QUIZ:

A. 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 information

LiTH, Tekniska högskolan vid Linköpings universitet 1(7) IDA, Institutionen för datavetenskap Juha Takkinen 2007-05-24

LiTH, Tekniska högskolan vid Linköpings universitet 1(7) IDA, Institutionen för datavetenskap Juha Takkinen 2007-05-24 LiTH, Tekniska högskolan vid Linköpings universitet 1(7) IDA, Institutionen för datavetenskap Juha Takkinen 2007-05-24 1. A database schema is a. the state of the db b. a description of the db using a

More information

Normalization for Relational DBs

Normalization for Relational DBs Chapter 7 Functional Dependencies & Normalization for Relational DBs Truong Quynh Chi tqchi@cse.hcmut.edu.vn Spring- 2013 Top-Down Database Design Mini-world Requirements E1 R Relation schemas Conceptual

More information

COMP 378 Database Systems Notes for Chapter 7 of Database System Concepts Database Design and the Entity-Relationship Model

COMP 378 Database Systems Notes for Chapter 7 of Database System Concepts Database Design and the Entity-Relationship Model COMP 378 Database Systems Notes for Chapter 7 of Database System Concepts Database Design and the Entity-Relationship Model The entity-relationship (E-R) model is a a data model in which information stored

More information

Reducing ER Schema to Relational Schema

Reducing ER Schema to Relational Schema Reducing ER Schema to Relational Schema Excerpt from Chapter 3, Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 1 Logical DB Design: ER to Relational Entity sets to tables: ssn name Employees

More information

Functional Dependencies and Normalization

Functional Dependencies and Normalization Functional Dependencies and Normalization 5DV119 Introduction to Database Management Umeå University Department of Computing Science Stephen J. Hegner hegner@cs.umu.se http://www.cs.umu.se/~hegner Functional

More information

The Entity-Relationship Model

The Entity-Relationship Model The Entity-Relationship Model Chapter 2 Instructor: Vladimir Zadorozhny vladimir@sis.pitt.edu Information Science Program School of Information Sciences, University of Pittsburgh 1 Database: a Set of Relations

More information

Fundamentals of Database Systems, 4 th Edition By Ramez Elmasri and Shamkant Navathe. Table of Contents. A. Short Table of Contents

Fundamentals of Database Systems, 4 th Edition By Ramez Elmasri and Shamkant Navathe. Table of Contents. A. Short Table of Contents Fundamentals of Database Systems, 4 th Edition By Ramez Elmasri and Shamkant Navathe Table of Contents A. Short Table of Contents (This Includes part and chapter titles only) PART 1: INTRODUCTION AND CONCEPTUAL

More information

Relational Normalization: Contents. Relational Database Design: Rationale. Relational Database Design. Motivation

Relational Normalization: Contents. Relational Database Design: Rationale. Relational Database Design. Motivation Relational Normalization: Contents Motivation Functional Dependencies First Normal Form Second Normal Form Third Normal Form Boyce-Codd Normal Form Decomposition Algorithms Multivalued Dependencies and

More information

2. Conceptual Modeling using the Entity-Relationship Model

2. Conceptual Modeling using the Entity-Relationship Model ECS-165A WQ 11 15 Contents 2. Conceptual Modeling using the Entity-Relationship Model Basic concepts: entities and entity types, attributes and keys, relationships and relationship types Entity-Relationship

More information

Ques 1. Define dbms and file management system? Ans- Database management system (DBMS) A file management system

Ques 1. Define dbms and file management system? Ans- Database management system (DBMS) A file management system UNIT-1 Ques 1. Define dbms and file management system? Ans- Database management system (DBMS) is a collection of interrelated data and a set of programs to access those data. Some of the very well known

More information

Databases -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 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 information

Week 11: Normal Forms. Logical Database Design. Normal Forms and Normalization. Examples of Redundancy

Week 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 information

Schema Refinement and Normalization

Schema Refinement and Normalization Schema Refinement and Normalization Module 5, Lectures 3 and 4 Database Management Systems, R. Ramakrishnan 1 The Evils of Redundancy Redundancy is at the root of several problems associated with relational

More information

Normalization in OODB Design

Normalization 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 information

3. Relational Model and Relational Algebra

3. Relational Model and Relational Algebra ECS-165A WQ 11 36 3. Relational Model and Relational Algebra Contents Fundamental Concepts of the Relational Model Integrity Constraints Translation ER schema Relational Database Schema Relational Algebra

More information

Chapter 7: Relational Database Design

Chapter 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 information

CS143 Notes: Normalization Theory

CS143 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 information

BCA. Database Management System

BCA. 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 information

Comp 5311 Database Management Systems. 5. Functional Dependencies

Comp 5311 Database Management Systems. 5. Functional Dependencies Comp 5311 Database Management Systems 5. Functional Dependencies 1 Functional Dependencies (FD) - Definition Let R be a relation scheme and X, Y be sets of attributes in R. A functional dependency from

More information

Relational Database Design: FD s & BCNF

Relational Database Design: FD s & BCNF CS145 Lecture Notes #5 Relational Database Design: FD s & BCNF Motivation Automatic translation from E/R or ODL may not produce the best relational design possible Sometimes database designers like to

More information

Fundamentals of Database Design

Fundamentals 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 information

Design of Relational Database Schemas

Design 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 information

DATABASE NORMALIZATION

DATABASE 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 information

Database Design Overview. Conceptual Design ER Model. Entities and Entity Sets. Entity Set Representation. Keys

Database Design Overview. Conceptual Design ER Model. Entities and Entity Sets. Entity Set Representation. Keys Database Design Overview Conceptual Design. The Entity-Relationship (ER) Model CS430/630 Lecture 12 Conceptual design The Entity-Relationship (ER) Model, UML High-level, close to human thinking Semantic

More information

There are five fields or columns, with names and types as shown above.

There are five fields or columns, with names and types as shown above. 3 THE RELATIONAL MODEL Exercise 3.1 Define the following terms: relation schema, relational database schema, domain, attribute, attribute domain, relation instance, relation cardinality, andrelation degree.

More information

Schema Refinement & Normalization Theory

Schema Refinement & Normalization Theory Schema Refinement & Normalization Theory Functional Dependencies Week 11-1 1 What s the Problem Consider relation obtained (call it SNLRHW) Hourly_Emps(ssn, name, lot, rating, hrly_wage, hrs_worked) What

More information

DATABASE MANAGEMENT SYSTEMS. Question Bank:

DATABASE MANAGEMENT SYSTEMS. Question Bank: DATABASE MANAGEMENT SYSTEMS Question Bank: UNIT 1 1. Define Database? 2. What is a DBMS? 3. What is the need for database systems? 4. Define tupule? 5. What are the responsibilities of DBA? 6. Define schema?

More information

Normalization. Functional Dependence. Normalization. Normalization. GIS Applications. Spring 2011

Normalization. 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 information

The Relational Data Model: Structure

The Relational Data Model: Structure The Relational Data Model: Structure 1 Overview By far the most likely data model in which you ll implement a database application today. Of historical interest: the relational model is not the first implementation

More information

Designing relational schemas Anomalies caused by data redundancies Functional Dependencies Reasoning about FDs Normal Forms

Designing relational schemas Anomalies caused by data redundancies Functional Dependencies Reasoning about FDs Normal Forms Today s Lecture Designing relational schemas Anomalies caused by data redundancies Functional Dependencies Reasoning about FDs Normal Forms Winter 2003 1 R ecom m en ded R eadi n g s Chapter 19 All sections

More information

The Entity-Relationship Model. Steps in Database Design

The Entity-Relationship Model. Steps in Database Design The Entity-Relationship Model Steps in Database Design 1) Requirement Analysis Identify the data that needs to be stored data requirements Identify the operations that need to be executed on the data functional

More information

Databases and BigData

Databases and BigData Eduardo Cunha de Almeida eduardo.almeida@uni.lu Outline of the course Introduction Database Systems (E. Almeida) Distributed Hash Tables and P2P (C. Cassagnes) NewSQL (D. Kim and J. Meira) NoSQL (D. Kim)

More information

Normalization of Database

Normalization 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 information

Review Entity-Relationship Diagrams and the Relational Model. Data Models. Review. Why Study the Relational Model? Steps in Database Design

Review Entity-Relationship Diagrams and the Relational Model. Data Models. Review. Why Study the Relational Model? Steps in Database Design Review Entity-Relationship Diagrams and the Relational Model CS 186, Fall 2007, Lecture 2 R & G, Chaps. 2&3 Why use a DBMS? OS provides RAM and disk A relationship, I think, is like a shark, you know?

More information

CS2Bh: Current Technologies. Introduction to XML and Relational Databases. Introduction to Databases. Why databases? Why not use XML?

CS2Bh: Current Technologies. Introduction to XML and Relational Databases. Introduction to Databases. Why databases? Why not use XML? CS2Bh: Current Technologies Introduction to XML and Relational Databases Spring 2005 Introduction to Databases CS2 Spring 2005 (LN5) 1 Why databases? Why not use XML? What is missing from XML: Consistency

More information

Lecture 2 Normalization

Lecture 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 information

Announcements. SQL is hot! Facebook. Goal. Database Design Process. IT420: Database Management and Organization. Normalization (Chapter 3)

Announcements. 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 information

RELATIONAL DATABASE DESIGN

RELATIONAL 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 information

ER & EER to Relational Mapping. Chapter 9 1

ER & EER to Relational Mapping. Chapter 9 1 ER & EER to Relational Mapping Chapter 9 1 Figure 3.2 ER schema diagram for the company database. Fname Minit Lname Number Name Address N 1 WORKS_FOR Name Locations Sex Salary Ssn Bdate EMPLOYEE NumberOfEmployees

More information

Conceptual Design Using the Entity-Relationship (ER) Model

Conceptual Design Using the Entity-Relationship (ER) Model Conceptual Design Using the Entity-Relationship (ER) Model Module 5, Lectures 1 and 2 Database Management Systems, R. Ramakrishnan 1 Overview of Database Design Conceptual design: (ER Model is used at

More information

Database Management Systems. Redundancy and Other Problems. Redundancy

Database Management Systems. Redundancy and Other Problems. Redundancy Database Management Systems Winter 2004 CMPUT 391: Database Design Theory or Relational Normalization Theory Dr. Osmar R. Zaïane Lecture 2 Limitations of Relational Database Designs Provides a set of guidelines,

More information

1.264 Lecture 10. Data normalization

1.264 Lecture 10. Data normalization 1.264 Lecture 10 Data normalization Next class: Read Murach chapters 1-3. Exercises due after class Make sure you ve downloaded and run the.sql file to create the database we ll be using in the next two

More information

Chapter 9: Normalization

Chapter 9: Normalization 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

More information

Course Notes on From Entity-Relationship Schemas to Relational Schemas

Course Notes on From Entity-Relationship Schemas to Relational Schemas Course Notes on From Entity-Relationship Schemas to Relational Schemas The chapter deals with practical database design: the construction of a relational schema from an E-R schema this stage of database

More information

Database Design Methodology

Database Design Methodology Database Design Methodology Three phases Database Design Methodology Logical database Physical database Constructing a model of the information used in an enterprise on a specific data model but independent

More information

The Entity-Relationship Model

The Entity-Relationship Model The Entity-Relationship Model 221 After completing this chapter, you should be able to explain the three phases of database design, Why are multiple phases useful? evaluate the significance of the Entity-Relationship

More information

Database Systems. Lecture 1: Introduction

Database Systems. Lecture 1: Introduction Database Systems Lecture 1: Introduction General Information Professor: Leonid Libkin Contact: libkin@ed.ac.uk Lectures: Tuesday, 11:10am 1 pm, AT LT4 Website: http://homepages.inf.ed.ac.uk/libkin/teach/dbs09/index.html

More information

Review: Participation Constraints

Review: Participation Constraints Review: Participation Constraints Does every department have a manager? If so, this is a participation constraint: the participation of Departments in Manages is said to be total (vs. partial). Every did

More information

SQL DDL. DBS Database Systems Designing Relational Databases. Inclusion Constraints. Key Constraints

SQL DDL. DBS Database Systems Designing Relational Databases. Inclusion Constraints. Key Constraints DBS Database Systems Designing Relational Databases Peter Buneman 12 October 2010 SQL DDL In its simplest use, SQL s Data Definition Language (DDL) provides a name and a type for each column of a table.

More information

MCQs~Databases~Relational Model and Normalization http://en.wikipedia.org/wiki/database_normalization

MCQs~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 information

DATABASE DESIGN: NORMALIZATION NOTE & EXERCISES (Up to 3NF)

DATABASE 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 information

Exercise 1: Relational Model

Exercise 1: Relational Model Exercise 1: Relational Model 1. Consider the relational database of next relational schema with 3 relations. What are the best possible primary keys in each relation? employ(person_name, street, city)

More information

Normalisation to 3NF. Database Systems Lecture 11 Natasha Alechina

Normalisation 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 information

Introduction to Database Design. Overview of Database Design

Introduction to Database Design. Overview of Database Design Introduction to Database Design Chapter 2 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 1 Overview of Database Design Requirements Analysis The very first step in designing a database

More information

ER modelling, Weak Entities, Class Hierarchies, Aggregation

ER 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 information

Database Design. Database Design I: The Entity-Relationship Model. Entity Type (con t) Chapter 4. Entity: an object that is involved in the enterprise

Database Design. Database Design I: The Entity-Relationship Model. Entity Type (con t) Chapter 4. Entity: an object that is involved in the enterprise Database Design Database Design I: The Entity-Relationship Model Chapter 4 Goal: specification of database schema Methodology: Use E-R R model to get a high-level graphical view of essential components

More information

Functional Dependencies and Finding a Minimal Cover

Functional 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 information

Bridge from Entity Relationship modeling to creating SQL databases, tables, & relations

Bridge from Entity Relationship modeling to creating SQL databases, tables, & relations 1 Topics for this week: 1. Good Design 2. Functional Dependencies 3. Normalization Readings for this week: 1. E&N, Ch. 10.1-10.6; 12.2 2. Quickstart, Ch. 3 3. Complete the tutorial at http://sqlcourse2.com/

More information

Fundamentals of Database System

Fundamentals 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 information

Chapter 7 Data Modeling Using the Entity- Relationship (ER) Model

Chapter 7 Data Modeling Using the Entity- Relationship (ER) Model Chapter 7 Data Modeling Using the Entity- Relationship (ER) Model Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 7 Outline Using High-Level Conceptual Data Models for

More information

Mapping Data Models to a Relational Database

Mapping Data Models to a Relational Database Mapping Data Models to a Relational Database Time to dovetail two prior topics: data modeling (E-R, UML) and the relational data model (structure, algebra) To recap, this is how they relate: The data model

More information

DATABASE SYSTEMS. Chapter 7 Normalisation

DATABASE 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 information

A Tool for Generating Relational Database Schema from EER Diagram

A Tool for Generating Relational Database Schema from EER Diagram A Tool for Generating Relational Schema from EER Diagram Lisa Simasatitkul and Taratip Suwannasart Abstract design is an important activity in software development. EER diagram is one of diagrams, which

More information