DOCSLIB.ORG

Relational Database Systems 1 – Wolf-Tilo Balke – Institut Für Informationssysteme – TU Braunschweig 2

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Relational Database Systems 1 – Wolf-Tilo Balke – Institut Für Informationssysteme – TU Braunschweig 2 Overview • Homework • Normalization Relational – Functional dependencies Database Systems 1 – 2NF – 3NF Wolf-Tilo Balke – BCNF Joachim Selke – 4NF, 5NF, 6NF Institut für Informationssysteme • Denormalization Technische Universität Braunschweig www.ifis.cs.tu-bs.de Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 2 Exercise 8.1 Exercise 8.1 Hotel(hotelNo, hotelName, city) • Again, our hotel database: Room(roomNo, hotelNo → Hotel, type, price) Booking(hotelNo → Hotel/Room, guestNo → Guest, dateFrom, dateTo, roomNo → Room) Hotel(hotelNo, hotelName, city) Guest(guestNo, guestName, guestAddress) Room(roomNo, hotelNo → Hotel, type, price) Booking(hotelNo → Hotel/Room, guestNo → Guest, dateFrom, dateTo, roomNo → Room) Guest(guestNo, guestName, guestAddress) • CREATE SCHEMA hotelinfo • SET SCHEMA hotelinfo • Provide all SQL statements (in the right order!) that are necessary to create • CREATE TABLE hotel ( the table structure given above (including all primary keys and referential hotelNo INTEGER NOT NULL PRIMARY KEY, integrity), and additionally ensure the following: hotelName VARCHAR(200) NOT NULL, – All table should be contained in a new schema called hotelinfo – Allowed room types are single, double, and family city VARCHAR(100) NOT NULL) – The price of each room must be between 10 and 100 Euros – The same guest cannot have overlapping bookings at the same hotel Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 3 Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 4 Exercise 8.1 Exercise 8.1 Hotel(hotelNo, hotelName, city) Hotel(hotelNo, hotelName, city) Room(roomNo, hotelNo → Hotel, type, price) Room(roomNo, hotelNo → Hotel, type, price) Booking(hotelNo → Hotel/Room, guestNo → Guest, dateFrom, dateTo, roomNo → Room) Booking(hotelNo → Hotel/Room, guestNo → Guest, dateFrom, dateTo, roomNo → Room) Guest(guestNo, guestName, guestAddress) Guest(guestNo, guestName, guestAddress) • CREATE TABLE room ( • roomNo INTEGER NOT NULL, CREATE TABLE guest ( hotelNo INTEGER NOT NULL REFERENCES hotel, guestNo INTEGER NOT NULL PRIMARY KEY, type VARCHAR(10) NOT NULL guestName VARCHAR(200) NOT NULL, CHECK (type IN (’single’, ’double’, ’family’)), guestAddress VARCHAR(1000)) price NUMERIC(3, 2) NOT NULL CHECK (price BETWEEN 10 AND 100), PRIMARY KEY (roomNo, hotelNo)) Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 5 Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 6 Exercise 8.1 Exercise 8.2 • CREATE TABLE booking ( • The relational schema of a product database: hotelNo INTEGER NOT NULL REFERENCES hotel, guestNo INTEGER NOT NULL REFERENCES guest, – product(model, maker, price) dateFrom DATE NOT NULL, dateTo DATE NOT NULL, – pc(model → product, speed, ram, hd) roomNo INTEGER NOT NULL, – laptop(model → product, speed, ram, hd, screen) PRIMARY KEY (hotelNo, guestNo, dateFrom), FOREIGN KEY (hotelNo, roomNo) REFERENCES room, – printer(model → product, color, type) CHECK (dateFrom <= dateTo), CHECK (NOT EXISTS ( SELECT * FROM booking b1, booking b2 WHERE b1.hotelNo = b2.hotelNo AND b1.guestNo = b2.guestNo AND b1.dateFrom < b2.dateFrom AND b1.dateTo > b2.dateFrom))) Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 7 Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 8 Exercise 8.2 Exercise 8.2 – product(model, maker, price) – product(model, maker, price) – pc(model → product, speed, ram, hd) – pc(model → product, speed, ram, hd) – laptop(model → product, speed, ram, hd, screen) – laptop(model → product, speed, ram, hd, screen) – printer(model → product, color, type) – printer(model → product, color, type) • Give SQL statements to modify the database as follows: b) Store the fact that PC model 1500 is made by manufacturer A, has speed 3.1, RAM 1024, hard disk 300, and sells for 2499 Euros. a) Delete all PCs with less than 200 gigabytes of hard disk. INSERT INTO product VALUES (1500, ’A’, 2499) CREATE TABLE temp (model INTEGER) INSERT INTO pc VALUES(1500, 3.1, 1024, 300) INSERT INTO temp (SELECT model FROM pc WHERE hd < 200 DELETE FROM pc WHERE model IN (SELECT * FROM temp) DELETE FROM product WHERE model IN (SELECT * FROM temp) DROP TABLE temp (As an alternative solution, you can make the assumption that all foreign keys have been defined using ON DELETE CASCADE. Then, only the deletion from the pc table has to be performed.) Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 9 Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 10 Exercise 8.2 Exercise 8.2 – product(model, maker, price) – product(model, maker, price) – pc(model → product, speed, ram, hd) – pc(model → product, speed, ram, hd) – laptop(model → product, speed, ram, hd, screen) – laptop(model → product, speed, ram, hd, screen) – printer(model → product, color, type) – printer(model → product, color, type) c) Delete all laptops made by a manufacturer that does not make d) Manufacturer B buys manufacturer C. PCs. Change all products made by C so they are now made by B. CREATE TABLE temp (model INTEGER) UPDATE product SET maker = ’B’ WHERE maker = ’C’ INSERT INTO temp (SELECT model FROM laptop WHERE maker NOT IN e) For each PC, double the amount of hard disk and (SELECT maker FROM pc JOIN product pr ON pc.model = pr.model)) add 1024 megabytes to the amount of RAM. DELETE FROM laptop WHERE model IN (SELECT * FROM temp) DELETE FROM product WHERE model IN (SELECT * FROM temp) UPDATE pc SET (hd, ram) = (2 * hd, ram + 1024) DROP TABLE temp (Alternative solution: see above) Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 11 Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 12 Exercise 8.2 Exercise 8.2 – product(model, maker, price) – product(model, maker, price) – pc(model → product, speed, ram, hd) – pc(model → product, speed, ram, hd) – laptop(model → product, speed, ram, hd, screen) – laptop(model → product, speed, ram, hd, screen) – → – printer(model → product, color, type) printer(model product, color, type) g) Insert the facts that for every laptop there is a PC with the same f) For each laptop made by manufacturer D, add 1 inch to manufacturer, speed, RAM, hard disk, a model number that is the screen size and subtract 200 Euros from the price. 1100 less, and a price that is 500 Euros less. CREATE TABLE temp (model INTEGER) CREATE TABLE temp (model INTEGER) INSERT INTO temp INSERT INTO temp (SELECT l.model (SELECT model FROM laptop l WHERE NOT EXISTS FROM laptop l JOIN product p ON l.model = p.model (SELECT * FROM product p WHERE p.model = l.model - 1100)) WHERE maker = ’D’) INSERT INTO product UPDATE laptop SET screen = screen + 1 (SELECT t.model - 1100, maker, price - 500 FROM temp t JOIN product p ON t.model = p.model) WHERE model IN (SELECT * FROM temp) INSERT INTO pc UPDATE product SET price = price - 200 (SELECT t.model - 1100, speed, ram, hd WHERE model IN (SELECT * FROM temp) FROM temp t JOIN laptop l ON t.model = p.model) DROP TABLE temp DROP TABLE temp Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 13 Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 14 Exercise 8.3 Exercise 8.3 – marks(studentid, score) • A relation containing exam scores: – marks(studentid, score) • Write SQL queries to do the following: • We wish to assign grades to students based on a) Display the grade for each student, based on the marks relation. scores as follows: SELECT studentid, – Grade F if score < 40, CASE – grade C if 40 ≤ score < 60, WHEN score < 40 THEN ’F’ – grade B if 60 ≤ score < 80, and WHEN score < 60 THEN ’C’ WHEN score < 80 THEN ’B’ – grade A if 80 ≤ score. ELSE ’A’ END FROM marks Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 15 Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 16 Exercise 8.3 Exercise 8.4 – marks(studentid, score) • The SQL-92 standard provides an n-ary operation • Write SQL queries to do the following: called COALESCE, which is defined as follows: a) Find the number of students with each grade. WITH grades(studentid, grade) AS COALESCE(A1, A2, ..., An) returns the first nonnull (SELECT studentid, Ai in the list A1, A2, ..., An and returns null if all of CASE WHEN score < 40 THEN ’F’ A1, A2, ..., An are null. WHEN score < 60 THEN ’C’ WHEN score < 80 THEN ’B’ • Show how to express the COALESCE operation ELSE ’A’ using the CASE operation. END AS grade FROM marks) SELECT grade, COUNT(*) AS count FROM grades GROUP BY grade Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 17 Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 18 Exercise 8.4 9.1 Introduction • Show how to express the COALESCE operation • Up to now, we have learned ... using the CASE operation. – ... how the relational model works. – COALESCE(A1, A2, ..., An) is equivalent to the following – ... how it is implemented in current RDBMS. CASE operation with searched WHEN-clause: – ... how to create relational databases (SQL DDL). CASE – ... how to define constraints
Load more

Recommended publications
  • Database Normalization
    Outline Data Redundancy Normalization and Denormalization Normal Forms Database Management Systems Database Normalization Malay Bhattacharyya Assistant Professor Machine Intelligence Unit and Centre for Artificial Intelligence and Machine Learning Indian Statistical Institute, Kolkata February, 2020 Malay Bhattacharyya Database Management Systems Outline Data Redundancy Normalization and Denormalization Normal Forms 1 Data Redundancy 2 Normalization and Denormalization 3 Normal Forms First Normal Form Second Normal Form Third Normal Form Boyce-Codd Normal Form Elementary Key Normal Form Fourth Normal Form Fifth Normal Form Domain Key Normal Form Sixth Normal Form Malay Bhattacharyya Database Management Systems These issues can be addressed by decomposing the database { normalization forces this!!! Outline Data Redundancy Normalization and Denormalization Normal Forms Redundancy in databases Redundancy in a database denotes the repetition of stored data Redundancy might cause various anomalies and problems pertaining to storage requirements: Insertion anomalies: It may be impossible to store certain information without storing some other, unrelated information. Deletion anomalies: It may be impossible to delete certain information without losing some other, unrelated information. Update anomalies: If one copy of such repeated data is updated, all copies need to be updated to prevent inconsistency. Increasing storage requirements: The storage requirements may increase over time. Malay Bhattacharyya Database Management Systems Outline Data Redundancy Normalization and Denormalization Normal Forms Redundancy in databases Redundancy in a database denotes the repetition of stored data Redundancy might cause various anomalies and problems pertaining to storage requirements: Insertion anomalies: It may be impossible to store certain information without storing some other, unrelated information. Deletion anomalies: It may be impossible to delete certain information without losing some other, unrelated information.
    [Show full text]
  • Project Join Normal Form
    Project Join Normal Form Karelallegedly.Witch-hunt is floatiest Interrupted and reedier and mar and Joab receptively perissodactyl unsensitised while Kenn herthumblike alwayswhaps Quiglyveerretile whileforlornly denationalizes Sebastien and ranging ropedand passaged. his some creditworthiness. madeleine Xi are the specialisation, and any problem ofhaving to identify a candidate keysofa relation withthe original style from another way for project join may not need to become a result in the contrary, we proposed informal definition Define join normal form to understand and normalization helps eliminate repeating groups and deletion anomalies unavoidable, authorization and even relations? Employeeprojectstoring natural consequence of project join dependency automatically to put the above with a project join of decisions is. Remove all tables to convert the project join. The normal form if f r does not dependent on many records project may still exist. First three cks: magna cumm laude honors degree to first, you get even harder they buy, because each row w is normalized tables for. Before the join dependency, joins are atomic form if we will remove? This normal forms. This exam covers all the material for databases Make sure. That normal forms of normalization procedureconsists ofapplying a default it. You realize your project join normal form of joins in sql statements add to be. Thus any project manager is normalization forms are proceeding steps not sufficient to form the er model used to be a composite data. Student has at least three attributes ofeach relation, today and their can be inferred automatically. That normal forms of join dependency: many attributes and only. Where all candidate key would have the employee tuple u if the second normal form requires multiple times by dividing the database structure.
    [Show full text]
  • Session 7 – Main Theme
    Database Systems Session 7 – Main Theme Functional Dependencies and Normalization Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical Sciences Presentation material partially based on textbook slides Fundamentals of Database Systems (6th Edition) by Ramez Elmasri and Shamkant Navathe Slides copyright © 2011 and on slides produced by Zvi Kedem copyight © 2014 1 Agenda 1 Session Overview 2 Logical Database Design - Normalization 3 Normalization Process Detailed 4 Summary and Conclusion 2 Session Agenda . Logical Database Design - Normalization . Normalization Process Detailed . Summary & Conclusion 3 What is the class about? . Course description and syllabus: » http://www.nyu.edu/classes/jcf/CSCI-GA.2433-001 » http://cs.nyu.edu/courses/spring15/CSCI-GA.2433-001/ . Textbooks: » Fundamentals of Database Systems (6th Edition) Ramez Elmasri and Shamkant Navathe Addition Wesley ISBN-10: 0-1360-8620-9, ISBN-13: 978-0136086208 6th Edition (04/10) 4 Icons / Metaphors Information Common Realization Knowledge/Competency Pattern Governance Alignment Solution Approach 55 Agenda 1 Session Overview 2 Logical Database Design - Normalization 3 Normalization Process Detailed 4 Summary and Conclusion 6 Agenda . Informal guidelines for good design . Functional dependency . Basic tool for analyzing relational schemas . Informal Design Guidelines for Relation Schemas . Normalization: . 1NF, 2NF, 3NF, BCNF, 4NF, 5NF • Normal Forms Based on Primary Keys • General Definitions of Second and Third Normal Forms • Boyce-Codd Normal Form • Multivalued Dependency and Fourth Normal Form • Join Dependencies and Fifth Normal Form 7 Logical Database Design . We are given a set of tables specifying the database » The base tables, which probably are the community (conceptual) level . They may have come from some ER diagram or from somewhere else .
    [Show full text]
  • Unit-3 Schema Refinement and Normalisation
    DATA BASE MANAGEMENT SYSTEMS UNIT-3 SCHEMA REFINEMENT AND NORMALISATION Unit 3 contents at a glance: 1. Introduction to schema refinement, 2. functional dependencies, 3. reasoning about FDs. 4. Normal forms: 1NF, 2NF, 3NF, BCNF, 5. properties of decompositions, 6. normalization, 7. schema refinement in database design(Refer Text Book), 8. other kinds of dependencies: 4NF, 5NF, DKNF 9. Case Studies(Refer text book) . 1. Schema Refinement: The Schema Refinement refers to refine the schema by using some technique. The best technique of schema refinement is decomposition. Normalisation or Schema Refinement is a technique of organizing the data in the database. It is a systematic approach of decomposing tables to eliminate data redundancy and undesirable characteristics like Insertion, Update and Deletion Anomalies. Redundancy refers to repetition of same data or duplicate copies of same data stored in different locations. Anomalies: Anomalies refers to the problems occurred after poorly planned and normalised databases where all the data is stored in one table which is sometimes called a flat file database. 1 DATA BASE MANAGEMENT SYSTEMS Anomalies or problems facing without normalization(problems due to redundancy) : Anomalies refers to the problems occurred after poorly planned and unnormalised databases where all the data is stored in one table which is sometimes called a flat file database. Let us consider such type of schema – Here all the data is stored in a single table which causes redundancy of data or say anomalies as SID and Sname are repeated once for same CID . Let us discuss anomalies one by one. Due to redundancy of data we may get the following problems, those are- 1.insertion anomalies : It may not be possible to store some information unless some other information is stored as well.
    [Show full text]
  • Relation Normalization
    Introduction to Database Management Systems Relation Normalization Why Normalization? Functional Dependencies. First, Second, and Third Normal Forms. Boyce/Codd Normal Form. Fourth and Fifth Normal Form. No loss Decomposition. Summary CIS Relation Normalization 1 Why Normalization? An ill-structured relation contains redundant data Data redundancy causes modification anomalies: Insertion anomalies -- Suppose we want to enter SCUBA as an activity that costs $100, we can’t until a student signs up for it Update anomalies -- If we change the price of swimming for student 150, there is no guarantee that student 200 will pay the new price Deletion anomalies -- If we delete Student 100, we lose not only the fact that he/she is a skier, but also the fact that skiing costs $200 Normalization is the process used to remove modification anomalies ACTIVITY SID Activity Fee How can this table be changed 100 Skiing 200 to fix these problems??? 150 Swimming 50 175 Squash 50 200 Swimming 50 CIS Relation Normalization 2 Dave McDonald, CIS, GSU 10-1 Introduction to Database Management Systems Why Normalization... Course SID Name Grade Course# Text Major Dept s1 Joseph A CIS8110 b1 CIS CIS s1 Joseph B CIS8120 b2 CIS CIS s1 Joseph A CIS8140 b5 CIS CIS s2 Alice A CIS8110 b1 CS MCS s2 Alice A CIS8140 b5 CS MCS s3 Tom B CIS8110 b1 Acct Acct s3 Tom B CIS8140 b5 Acct Acct s3 Tom A CIS8680 b1 Acct Acct Is there any redundant data? Insertion anomalies? Update anomalies? Deletion anomalies? CIS Relation Normalization 3 Functional Dependencies Given two attributes, X and Y, of a relation R, Y is functionally dependent on X iff each X value must always occur with the same Y value in R.
    [Show full text]
  • Functional Dependencies and Normalization
    Database Systems Session 7 – Main Theme Functional Dependencies and Normalization Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical Sciences Presentation material partially based on textbook slides Fundamentals of Database Systems (7th Edition) by Ramez Elmasri and Shamkant Navathe Slides copyright © 2016 1 Agenda 1 Session Overview 2 Functional Dependencies & Normalization for RDBs 3 RDB Design Algorithms and Further Dependencies 4 Summary and Conclusion 2 Session Agenda . Functional Dependencies and Normalization for RDBs . RDB Design Algorithms and Further Dependencies . Summary & Conclusion 3 What is the class about? . Course description and syllabus: » http://www.nyu.edu/classes/jcf/CSCI-GA.2433-001 » http://cs.nyu.edu/courses/spring16/CSCI-GA.2433-001/ . Textbooks: » Fundamentals of Database Systems (7th Edition) Ramez Elmasri and Shamkant Navathe Pearson ISBN-10: 0133970779, ISBN-13: 978-0133970777 7th Edition (06/18/15) 4 Icons / Metaphors Information Common Realization Knowledge/Competency Pattern Governance Alignment Solution Approach 55 Agenda 1 Session Overview 2 Functional Dependencies & Normalization for RDBs 3 RDB Design Algorithms and Further Dependencies 4 Summary and Conclusion 6 Session Outline (1/3) . 1 Informal Design Guidelines for Relational Databases » 1.1 Semantics of the Relation Attributes » 1.2 Redundant Information in Tuples and Update Anomalies » 1.3 Null Values in Tuples » 1.4 Spurious Tuples . 2 Functional Dependencies (FDs) » 2.1 Definition of Functional Dependency 7 Session Outline (2/3) . 3 Normal Forms Based on Primary Keys » 3.1 Normalization of Relations » 3.2 Practical Use of Normal Forms » 3.3 Definitions of Keys and Attributes Participating in Keys » 3.4 First Normal Form » 3.5 Second Normal Form » 3.6 Third Normal Form .
    [Show full text]
  • Database Design Lecture 11 Higher Normal Forms
    Database Management Systems Part III: Database Design Lecture 11 Higher Normal Forms 1 Contents ▪ Introduction ▪ Multivalued Dependencies ▪ Fourth Normal Form ▪ Join Dependencies ▪ Fifth Normal Form ▪ Normalization Procedure Summarized ▪ Other Normal Forms 2 Introduction ▪ The concept of functional dependency is the most important type of dependency in relational database design theory and normal forms based on functional dependencies. ▪ However, in many cases, relations have constraints that cannot be specified as functional dependencies. ▪ This constraint is specified by a multivalued dependency. 3 Multivalued Dependencies ▪ Multivalued dependency occurs when the two attributes in a table are independent of each other but both depend on a third attribute. ▪ A multivalued dependency consists of at least two attributes that are dependent on a third attribute that is why it always requires at least three attributes. 4 Multivalued Dependencies (Cont.) ▪ Let R be a relation, and let A, B, and C be arbitrary subsets of the set of attributes of R. ▪Then, we say that B is multidependent on A – in symbols, A B if and only if the set of B-values matching a given (A-value, C- value) pair in R depends only on the A-value and is independent of the C-value. 5 Multivalued Dependencies (Cont.) Theorem (Fagin) ▪ Let R{A,B,C} be a relation, where A, B, and C are sets of attributes. ▪ Then, R is equal to the join of its projections on {A,B} and {A,C} if and only if R satisfies the MVD A B | C 6 Multivalued Dependencies (Cont.) Example ▪ Suppose there is a MEMBER MEMBER relation as shown in the table.
    [Show full text]
  • Unit 1 Relational Model Issues Er Model
    1 UNIT 1 RELATIONAL MODEL ISSUES ER Model - Normalization – Query Processing – Query Optimization - Transaction Processing - Concurrency Control – Recovery - Database Tuning ER MODEL ER modeling is a top-down approach to database design that begins by identifying the important data called entities and relationships between the data that must be represented in the model. ER modeling is an important technique for any database designer to master and forms the basis of the methodology. There are a number of different notations that can be used to represent each concept diagrammatically which is known as Unified Modeling Language (UML). UML is the successor to a number of object-oriented analysis and design methods introduced in the 1980s and 1990s. The Object Management Group (OMG) is currently looking at the standardization of UML and it is anticipated that UML will be the de facto standard modeling language. Entity Types o A group of objects with the same properties, which are identified by the enterprise as having an independent existence. o The basic concept of the ER model is the entity type, which represents a group of ‘objects’in the ‘real world’ with the same properties. o An entity type has an independent existence and can be objects with a physical (or ‘real’) existence or objects with a conceptual (or ‘abstract’) existence, Physical existence Staff part Property supplier Customer product Conceptual existence Viewing sale Inspection work experience o Each uniquely identifiable object of an entity type is referred to simply as an entity occurrence. o Examples for entity types: . Staff, Branch, PropertyForRent, and PrivateOwner o Diagrammatic representation of entity types Each entity type is shown as a rectangle labeled with the name of the entity, which isnormally a singular noun.
    [Show full text]
  • DBMS Chapter Three IS304
    DBMS Chapter Three IS304 Database Normalization-Comp. Contents 4. Boyce Codd Normal Form (BCNF) 5. Fourth Normal Form (4NF) 6. Fifth Normal Form (5NF) 7. Sixth Normal Form (6NF) 1 DBMS Chapter Three IS304 4. Boyce Codd Normal Form (BCNF) In the first part of chapter three, we demonstrated how 2NF and 3NF disallow partial and transitive dependencies on the primary key of a relation, respectively. Relations that have these types of dependencies may suffer from the update anomalies. However, the definition of 2NF and 3NF, respectively, do not consider whether such dependencies remain on other candidate keys of a relation, if any exist. Later we presented general definitions for 2NF and 3NF that disallow partial and transitive dependencies on any candidate key of a relation, respectively. Application of the general definitions of 2NF and 3NF may identify additional redundancy caused by dependencies that violate one or more candidate keys. However, despite these additional constraints, dependencies can still exist that will cause redundancy to be present in 3NF relations. This weakness in 3NF, resulted in the presentation of a stronger normal form called Boyce–Codd Normal Form (Codd, 1974). BCNF A relation is in BCNF, if and only if, every determinant is a candidate key. To test whether a relation is in BCNF, we identify all the determinants and make sure that they are candidate keys. Recall that a determinant is an attribute, or a group of attributes, on which some other attribute is fully functionally dependent. The difference between 3NF and BCNF is that for a functional dependency A→B, 3NF allows this dependency in a relation if B is a primary-key attribute and A is not a candidate key, whereas BCNF insists that for this dependency to remain in a relation, A must be a candidate key.
    [Show full text]
  • Database Systems [R17a0551] Lecture Notes Malla Reddy
    DATABASE SYSTEMS [R17A0551] LECTURE NOTES B.TECH II YEAR – II SEM(R17) (2018-19) DEPARTMENT OF ECE MALLA REDDY COLLEGE OF ENGINEERING & TECHNOLOGY (Autonomous Institution – UGC, Govt. of India) Recognized under 2(f) and 12 (B) of UGC ACT 1956 (Affiliated to JNTUH, Hyderabad, Approved by AICTE - Accredited by NBA & NAAC – ‘A’ Grade - ISO 9001:2015 Certified) Maisammaguda, Dhulapally (Post Via. Hakimpet), Secunderabad – 500100, Telangana State, India MALLA REDDY COLLEGE OF ENGINEERING AND TECHNOLOGY II Year B.Tech ECE-II Sem L T/P/D C 3 -/-/- 3 OPEN ELECTIVE - I (R17A0551) DATABASE SYSTEMS OBJECTIVES 1. To understand the basic concepts and the applications of database systems 2. To Master the basics of SQL and construct queries using SQL 3. To understand the relational database design principles 4. To become familiar with the basic issues of transaction processing and concurrency control 5. To become familiar with database storage structures and access techniques. UNIT I: INTRODUCTION Data- Database: File Processing System Vs DBMS, History, Characteristic-Abstraction levels,Architecture of a database, Functional components of a DBMS.DBMS Languages-Database users and DBA. UNIT II: DATABASE DESIGN ER Model: Objects, Attributes and its Type. Entity set and Relationship set-Design Issues of ER model-Constraints. Keys- primary key, Super key, candidate keys. Introduction to relational model-Tabular, Representation of Various ER Schemas. ER Diagram Notations- Goals of ER Diagram- Weak Entity Set- Views, Triggers. UNIT III: STRUCTURED QUERY LANGUAGE SQL: Overview, The Form of Basic SQL Query -UNION, INTERSECT, and EXCEPT– join operations: equi join and non equi join-Nested queries - correlated and uncorrelated- Aggregate Functions-Null values, GROUPBY- HAVING Clause.
    [Show full text]
  • Basics of Functional Dependencies and Normalization for Relational
    CHAPTER 14 Basics of Functional Dependencies and Normalization for Relational Pearson India Education Services Pvt. Ltd Databases 2017 Copyright © Fundamentals of Database Systems , 7e Authors: Elmasri and Navathe Chapter Outline 1 Informal Design Guidelines for Relational Databases 1.1 Semantics of the Relation Attributes 1.2 Redundant Information in Tuples and Update Anomalies 1.3 Null Values in Tuples 1.4 Spurious Tuples 2 Functional Dependencies (FDs) Pearson Pearson India Education Services Pvt. Ltd 2.1 Definition of Functional Dependency 2017 Copyright Copyright © Fundamentals of Database Systems , 7e Authors: Elmasri and Navathe Chapter Outline 3 Normal Forms Based on Primary Keys 3.1 Normalization of Relations 3.2 Practical Use of Normal Forms 3.3 Definitions of Keys and Attributes Participating in Keys 3.4 First Normal Form 3.5 Second Normal Form 3.6 Third Normal Form Pearson Pearson India Education Services Pvt. Ltd 4 General Normal Form Definitions for 2NF and 3NF (For 2017 Multiple Candidate Keys) Copyright Copyright © 5 BCNF (Boyce-Codd Normal Form) Fundamentals of Database Systems , 7e Authors: Elmasri and Navathe Chapter Outline 6 Multivalued Dependency and Fourth Normal Form 7 Join Dependencies and Fifth Normal Form Pearson Pearson India Education Services Pvt. Ltd 2017 Copyright Copyright © Fundamentals of Database Systems , 7e Authors: Elmasri and Navathe 1. Informal Design Guidelines for Relational Databases (1) What is relational database design? The grouping of attributes to form "good" relation
    [Show full text]
  • A Functional Dependency
    Functional Dependencies, Schema Refinement, and Normalization for Relational Databases CSC 375, Fall 2019 Chapter 19 Science is the knowledge of consequences, and dependence of one fact upon another. Thomas Hobbes (1588-1679) Review: Database Design • Requirements Analysis § user needs; what must database do? • Conceptual Design § high level descr (often done w/ER model) • Logical Design § translate ER into DBMS data model • Schema Refinement § consistency, normalization • Physical Design - indexes, disk layout • Security Design - who accesses what 2 Related Readings… • Check the following two papers on the course webpage § Decomposition of A Relation Scheme into Boyce-Codd Normal Form, D-M. Tsou § A Simple Guide to Five Normal Forms in Relational Database Theory, W. Kent 3 Informal Design Guidelines for Relation Schemas § Measures of quality § Making sure attribute semantics are clear § Reducing redundant information in tuples § Reducing NULL values in tuples § Disallowing possibility of generating spurious tuples 4 What is the Problem? • Consider relation obtained (call it SNLRHW) Hourly_Emps(ssn, name, lot, rating, hrly_wage, hrs_worked) S N L R W H 123-22-3666 Attishoo 48 8 10 40 231-31-5368 Smiley 22 8 10 30 131-24-3650 Smethurst 35 5 7 30 434-26-3751 Guldu 35 5 7 32 612-67-4134 Madayan 35 8 10 40 • What if we know that rating determines hrly_wage? 5 What is the Problem? S N L R W H 123-22-3666 Attishoo 48 8 10 40 231-31-5368 Smiley 22 8 10 30 131-24-3650 Smethurst 35 5 7 30 434-26-3751 Guldu 35 5 7 32 612-67-4134 Madayan 35 8 10
    [Show full text]