This document provides an overview of relational database design and normalization. It discusses the goals of database design as generating schemas without unnecessary redundancy and allowing easy data retrieval. Normalization aims to design schemas in a desirable normal form, such as Boyce-Codd normal form (BCNF) or third normal form (3NF). The document introduces key concepts like functional dependencies, normal forms, decomposition, and closure of functional dependencies, which are used to determine if a schema is properly normalized and how to decompose schemas if necessary.
The document discusses various concepts in entity-relationship (E-R) modeling including: weak entity sets and how their primary keys are formed; reducing E-R diagrams to relational schemas; extended E-R features like specialization, generalization, and aggregation; and differences between E-R diagrams and UML class diagrams. Key symbols used in E-R notation are also summarized.
The document discusses several key design issues in entity-relationship (ER) database schemas including:
1) Distinguishing between entities and attributes and how they are modeled, such as whether a phone number is an attribute of employees or its own entity.
2) Modeling relationships between entities as either binary or ternary relationships and how ternary relationships can be broken down into multiple binary relationships.
3) Relationship design considerations like whether a relationship such as an employee working in a department should allow for multiple time periods or just one.
3 data modeling using the entity-relationship (er) modelKumar
This document provides an overview of the key concepts in entity-relationship (ER) modeling for database design. It begins with an outline of the database design process and an example database application for a company (COMPANY). It then defines the core components of ER modeling, including entities, attributes, relationships, relationship types, and ER diagrams. The document presents the initial ER design for the COMPANY database and refines it by introducing relationships. It also covers additional concepts like weak entity types, constraints, and recursive relationships. The overall summary provides a high-level introduction to ER modeling concepts and how they are applied to design a sample database schema.
Fundamentals of database system - Data Modeling Using the Entity-Relationshi...Mustafa Kamel Mohammadi
In this chapter you will learn
Relational data model concepts
What is entity?
What is attribute and it’s types
What is relationship?
What is an Entity-Relationship data model?
Relational data model constraints
Characteristics of relation
The document provides an overview of entity-relationship (ER) modeling concepts including:
- Entity sets represent collections of real-world objects or concepts that share common properties
- Relationship sets represent associations between entity sets
- ER diagrams use graphical symbols like rectangles, diamonds, and lines to represent entity sets, relationship sets, and attributes
- Mapping cardinalities define the number of entities in one set that can be associated with entities in another set through a relationship
- Keys uniquely identify entities and relationships and primary keys are selected from candidate keys
Chapter-3 Data Modeling Using the Entity-Relationship ModelRaj vardhan
The document describes conceptual database design using the entity-relationship (ER) model. It discusses key concepts of the ER model including entities, attributes, relationships, and relationship constraints. An example ER diagram is presented for a COMPANY database with entities for employees, departments, and projects. Relationships include employees working for departments and departments controlling projects. The summary provides an overview of the important concepts and examples covered in the document related to conceptual database design using the ER model.
Data Modeling Using the EntityRelationship (ER) Modelsontumax
The document provides an overview of entity-relationship (ER) modeling and the ER diagram notation. It discusses key ER modeling concepts like entities, attributes, relationships, and relationship constraints. An example database schema for a company is used to illustrate these concepts. The example requirements are analyzed to identify entity types, relationship types, and refine the initial design. Notation for displaying entity types, relationships, and constraints in ER diagrams is also described.
Bsc cs ii-dbms- u-iii-data modeling using e.r. model (entity relationship model)Rai University
This document provides an overview of entity relationship (ER) modeling and relational databases. It defines key concepts in ER modeling like entities, attributes, relationships and keys. It also explains relational database concepts like tables, rows, columns, primary keys, and relationships between tables. The document concludes by discussing some limitations of relational databases for scientific applications.
The document discusses various concepts in entity-relationship (E-R) modeling including: weak entity sets and how their primary keys are formed; reducing E-R diagrams to relational schemas; extended E-R features like specialization, generalization, and aggregation; and differences between E-R diagrams and UML class diagrams. Key symbols used in E-R notation are also summarized.
The document discusses several key design issues in entity-relationship (ER) database schemas including:
1) Distinguishing between entities and attributes and how they are modeled, such as whether a phone number is an attribute of employees or its own entity.
2) Modeling relationships between entities as either binary or ternary relationships and how ternary relationships can be broken down into multiple binary relationships.
3) Relationship design considerations like whether a relationship such as an employee working in a department should allow for multiple time periods or just one.
3 data modeling using the entity-relationship (er) modelKumar
This document provides an overview of the key concepts in entity-relationship (ER) modeling for database design. It begins with an outline of the database design process and an example database application for a company (COMPANY). It then defines the core components of ER modeling, including entities, attributes, relationships, relationship types, and ER diagrams. The document presents the initial ER design for the COMPANY database and refines it by introducing relationships. It also covers additional concepts like weak entity types, constraints, and recursive relationships. The overall summary provides a high-level introduction to ER modeling concepts and how they are applied to design a sample database schema.
Fundamentals of database system - Data Modeling Using the Entity-Relationshi...Mustafa Kamel Mohammadi
In this chapter you will learn
Relational data model concepts
What is entity?
What is attribute and it’s types
What is relationship?
What is an Entity-Relationship data model?
Relational data model constraints
Characteristics of relation
The document provides an overview of entity-relationship (ER) modeling concepts including:
- Entity sets represent collections of real-world objects or concepts that share common properties
- Relationship sets represent associations between entity sets
- ER diagrams use graphical symbols like rectangles, diamonds, and lines to represent entity sets, relationship sets, and attributes
- Mapping cardinalities define the number of entities in one set that can be associated with entities in another set through a relationship
- Keys uniquely identify entities and relationships and primary keys are selected from candidate keys
Chapter-3 Data Modeling Using the Entity-Relationship ModelRaj vardhan
The document describes conceptual database design using the entity-relationship (ER) model. It discusses key concepts of the ER model including entities, attributes, relationships, and relationship constraints. An example ER diagram is presented for a COMPANY database with entities for employees, departments, and projects. Relationships include employees working for departments and departments controlling projects. The summary provides an overview of the important concepts and examples covered in the document related to conceptual database design using the ER model.
Data Modeling Using the EntityRelationship (ER) Modelsontumax
The document provides an overview of entity-relationship (ER) modeling and the ER diagram notation. It discusses key ER modeling concepts like entities, attributes, relationships, and relationship constraints. An example database schema for a company is used to illustrate these concepts. The example requirements are analyzed to identify entity types, relationship types, and refine the initial design. Notation for displaying entity types, relationships, and constraints in ER diagrams is also described.
Bsc cs ii-dbms- u-iii-data modeling using e.r. model (entity relationship model)Rai University
This document provides an overview of entity relationship (ER) modeling and relational databases. It defines key concepts in ER modeling like entities, attributes, relationships and keys. It also explains relational database concepts like tables, rows, columns, primary keys, and relationships between tables. The document concludes by discussing some limitations of relational databases for scientific applications.
This document discusses entity-relationship (E-R) modeling concepts including entity sets, relationship sets, E-R diagrams, keys, attributes, weak entity sets, specialization, generalization, aggregation, and converting an E-R schema to tables. It provides examples and definitions for each concept in 2-3 sentences.
The document discusses how to convert ER diagrams to relational databases. It explains that each entity set maps to a table, while relationship sets can map to tables or be represented within other tables by adding attributes. It also covers handling special cases like one-to-one/many relationships, composite attributes, and specialization/aggregation. The document provides SQL commands for creating tables, adding constraints, and altering or dropping tables during the conversion process.
The document provides an overview of the Entity Relationship (ER) model, which is a conceptual data modeling technique for describing and visualizing entities and their relationships. The key aspects summarized are:
- The ER model consists of entities, relationships between entities, and attributes that describe entities. Entities can be physical or conceptual objects.
- Relationships associate entities and have mapping cardinalities like one-to-one, one-to-many, many-to-one, many-to-many.
- Entities have attributes that can be simple/atomic, composite, single-valued, multi-valued, stored or derived. Primary keys uniquely identify entities.
This document provides an overview of key concepts in entity-relationship modeling including entities, attributes, relationships, constraints, weak entities, and class hierarchies. It defines entities as objects in the real world that can be uniquely identified by a set of attributes. Relationships associate entities and can be one-to-one, one-to-many, many-to-one, or many-to-many. Constraints specify how entities can participate in relationships. Weak entities cannot be uniquely identified without attributes from a related strong entity. Class hierarchies allow entities to be classified into subclasses that inherit attributes.
This document provides an overview of entity-relationship (ER) modeling concepts including entity sets, relationship sets, attributes, keys, ER diagrams, specialization, generalization, aggregation, and design issues. It defines core ER concepts like entities, relationships, and attributes. It describes how ER diagrams visually represent these concepts using symbols like rectangles for entities and diamonds for relationships. It also covers advanced topics such as weak entities, cardinalities, and converting non-binary relationships to binary form.
- The document discusses entity-relationship (E-R) modeling concepts including entity sets, relationship sets, attributes, keys, E-R diagrams, mapping cardinalities, and design issues when converting between binary and non-binary relationships.
- It provides examples of how to represent various relationship types like one-to-one, one-to-many, many-to-one, and many-to-many using E-R diagrams with lines and arrows to show cardinality constraints.
- Guidelines are given for choosing between entity sets vs attributes and relationship sets, and converting non-binary relationships to binary form while preserving semantics.
In software engineering, an entity–relationship model (ER model) is a data model for describing the data or information aspects of a business domain or its process requirements
This document discusses the components of an entity-relationship diagram including entities, attributes, relationships, and constraints. An entity-relationship diagram is a conceptual data model that shows entities, attributes, and relationships. The diagram defines entities, attributes, and three types of relationships: one-to-one, one-to-many, and many-to-many. It also covers cardinality and participation constraints that specify the minimum and maximum number of relationships allowed.
The document provides an overview of entity-relationship (E-R) modeling concepts including:
- Entity sets represent collections of real-world entities that share common properties
- Relationship sets define associations between entity sets
- Attributes provide additional information about entities and relationships
- Keys uniquely identify entities and relationships
- Cardinalities constrain how entities can participate in relationships
- E-R diagrams visually depict entity sets, attributes, relationships and constraints.
FellowBuddy.com is an innovative platform that brings students together to share notes, exam papers, study guides, project reports and presentation for upcoming exams.
We connect Students who have an understanding of course material with Students who need help.
Benefits:-
# Students can catch up on notes they missed because of an absence.
# Underachievers can find peer developed notes that break down lecture and study material in a way that they can understand
# Students can earn better grades, save time and study effectively
Our Vision & Mission – Simplifying Students Life
Our Belief – “The great breakthrough in your life comes when you realize it, that you can learn anything you need to learn; to accomplish any goal that you have set for yourself. This means there are no limits on what you can be, have or do.”
Like Us - https://www.facebook.com/FellowBuddycom
Data Modeling and Database Design 2nd Edition by Umanath Scamell Solution Manualendokayle
link full download: https://testbankstudy.com/product/data-modeling-and-database-design-2nd-edition-by-umanath-scamell-solution-manual/
Language: English
ISBN-10: 1285085256
ISBN-13: 978-1285085258
ISBN-13: 9781285085258
This document provides an overview of entity-relationship (ER) modeling concepts for database design. It defines key ER modeling concepts like entities, attributes, entity types, relationships, relationship types, weak entities, and constraints. It also explains how to represent these concepts in ER diagrams. As an example, it analyzes the requirements for a sample COMPANY database and designs the initial entity types and relationship types that would be represented in an ER diagram for this database.
This presentation discusses the relationship between schema and entity-relationship (E-R) diagrams. It defines key E-R diagram symbols like entities, attributes, and relationships. It then provides examples of how to represent one-to-one, one-to-many, many-to-one, and many-to-many relationships between tables in a relational database through E-R diagrams. Finally, it shows how to design an E-R diagram from a given schema involving bus routes, drivers, schedules, and their relationships.
This document outlines the algorithm for mapping an entity-relationship (EER) model to a relational database schema. It consists of 9 steps:
1) Regular entity types are mapped to relations with their attributes and a primary key.
2) Weak entity types are mapped to relations with owner keys as foreign keys.
3) Binary 1:1 relationships map to foreign keys or merged relations.
4) Binary 1:N relationships map relations with foreign keys.
5) Binary M:N relationships map to relations with foreign keys as primary keys.
6) Multivalued attributes map to relations with foreign keys.
7) N-ary relationships map to relations with foreign keys.
8)
The document discusses how to transform an entity-relationship (ER) diagram into a set of relational tables by representing entities as tables, relationships as links between tables, and enforcing constraints like primary keys and foreign keys. Key steps include representing entities as tables with a primary key, relationships as links between tables with foreign keys, normalizing the tables, and merging the results. Constraints like primary keys must be unique and non-redundant, while foreign keys enforce referential integrity by linking to primary keys.
The document discusses data modeling and the entity-relationship model. It defines key concepts like entities, attributes, relationships, and cardinalities. Entities have attributes and can be connected through relationships. Relationships can be one-to-one, one-to-many, many-to-one, or many-to-many depending on how many entities can be associated with each other. The entity-relationship model is useful for conceptual database design and represents these concepts visually in diagrams.
The document discusses the Entity-Relationship (E-R) model, which was proposed by Dr. Peter Chen in the 1970s as a way to model real-world entities and their relationships. The E-R model uses entities, attributes, and relationships, and allows these concepts to be visually represented in E-R diagrams using basic graphical symbols like rectangles, ellipses, and diamonds. The document also covers E-R modeling concepts like keys, entity types, relationship types, participation constraints, and weak entity sets.
Data modeling using the entity relationship modelJafar Nesargi
The document describes key concepts in entity relationship modeling including entity types, attributes, relationships, keys, and constraints. It provides an example database application to track employees, departments, and projects within a company. It then defines entity types for departments, projects, employees, and dependents with their attributes. It also describes relationship types, cardinalities, roles, and other modeling constructs used to design the conceptual schema.
The document provides an overview of entity-relationship (ER) modeling concepts including entities, attributes, relationships, and ER diagram notation. It then presents an example database application for a company (COMPANY) and defines the entity types, relationship types, and attributes that would be included in an ER diagram for the COMPANY database schema. Key concepts covered include entities, attributes, relationships, cardinalities, participation constraints, and weak entity types.
The document discusses relational database design and normalization. It covers first normal form, functional dependencies, and decomposition. The goal of normalization is to avoid data redundancy and anomalies. First normal form requires attributes to be atomic. Functional dependencies specify relationships between attributes that must be preserved. Decomposition breaks relations into smaller relations while maintaining lossless join properties. Higher normal forms like Boyce-Codd normal form and third normal form further reduce redundancy.
The document discusses relational database design and normalization. It covers topics like functional dependencies, normal forms like first normal form, Boyce-Codd normal form and third normal form. The goal of normalization is to organize data in a database to avoid insertion, deletion and update anomalies. Normalization techniques like decomposition are used to divide tables and isolate data to achieve higher normal forms.
This document discusses database normalization and functional dependencies. It provides examples of 1st, 2nd, and 3rd normal forms. It defines key concepts like functional dependencies, candidate keys, closure of attribute sets, minimal covers, and extraneous attributes. An example of a supplier-parts database is used to illustrate 2nd normal form. Functional dependencies indicate that city and status are not fully functionally dependent on the primary key, so the relation is not in 2nd normal form.
This document discusses entity-relationship (E-R) modeling concepts including entity sets, relationship sets, E-R diagrams, keys, attributes, weak entity sets, specialization, generalization, aggregation, and converting an E-R schema to tables. It provides examples and definitions for each concept in 2-3 sentences.
The document discusses how to convert ER diagrams to relational databases. It explains that each entity set maps to a table, while relationship sets can map to tables or be represented within other tables by adding attributes. It also covers handling special cases like one-to-one/many relationships, composite attributes, and specialization/aggregation. The document provides SQL commands for creating tables, adding constraints, and altering or dropping tables during the conversion process.
The document provides an overview of the Entity Relationship (ER) model, which is a conceptual data modeling technique for describing and visualizing entities and their relationships. The key aspects summarized are:
- The ER model consists of entities, relationships between entities, and attributes that describe entities. Entities can be physical or conceptual objects.
- Relationships associate entities and have mapping cardinalities like one-to-one, one-to-many, many-to-one, many-to-many.
- Entities have attributes that can be simple/atomic, composite, single-valued, multi-valued, stored or derived. Primary keys uniquely identify entities.
This document provides an overview of key concepts in entity-relationship modeling including entities, attributes, relationships, constraints, weak entities, and class hierarchies. It defines entities as objects in the real world that can be uniquely identified by a set of attributes. Relationships associate entities and can be one-to-one, one-to-many, many-to-one, or many-to-many. Constraints specify how entities can participate in relationships. Weak entities cannot be uniquely identified without attributes from a related strong entity. Class hierarchies allow entities to be classified into subclasses that inherit attributes.
This document provides an overview of entity-relationship (ER) modeling concepts including entity sets, relationship sets, attributes, keys, ER diagrams, specialization, generalization, aggregation, and design issues. It defines core ER concepts like entities, relationships, and attributes. It describes how ER diagrams visually represent these concepts using symbols like rectangles for entities and diamonds for relationships. It also covers advanced topics such as weak entities, cardinalities, and converting non-binary relationships to binary form.
- The document discusses entity-relationship (E-R) modeling concepts including entity sets, relationship sets, attributes, keys, E-R diagrams, mapping cardinalities, and design issues when converting between binary and non-binary relationships.
- It provides examples of how to represent various relationship types like one-to-one, one-to-many, many-to-one, and many-to-many using E-R diagrams with lines and arrows to show cardinality constraints.
- Guidelines are given for choosing between entity sets vs attributes and relationship sets, and converting non-binary relationships to binary form while preserving semantics.
In software engineering, an entity–relationship model (ER model) is a data model for describing the data or information aspects of a business domain or its process requirements
This document discusses the components of an entity-relationship diagram including entities, attributes, relationships, and constraints. An entity-relationship diagram is a conceptual data model that shows entities, attributes, and relationships. The diagram defines entities, attributes, and three types of relationships: one-to-one, one-to-many, and many-to-many. It also covers cardinality and participation constraints that specify the minimum and maximum number of relationships allowed.
The document provides an overview of entity-relationship (E-R) modeling concepts including:
- Entity sets represent collections of real-world entities that share common properties
- Relationship sets define associations between entity sets
- Attributes provide additional information about entities and relationships
- Keys uniquely identify entities and relationships
- Cardinalities constrain how entities can participate in relationships
- E-R diagrams visually depict entity sets, attributes, relationships and constraints.
FellowBuddy.com is an innovative platform that brings students together to share notes, exam papers, study guides, project reports and presentation for upcoming exams.
We connect Students who have an understanding of course material with Students who need help.
Benefits:-
# Students can catch up on notes they missed because of an absence.
# Underachievers can find peer developed notes that break down lecture and study material in a way that they can understand
# Students can earn better grades, save time and study effectively
Our Vision & Mission – Simplifying Students Life
Our Belief – “The great breakthrough in your life comes when you realize it, that you can learn anything you need to learn; to accomplish any goal that you have set for yourself. This means there are no limits on what you can be, have or do.”
Like Us - https://www.facebook.com/FellowBuddycom
Data Modeling and Database Design 2nd Edition by Umanath Scamell Solution Manualendokayle
link full download: https://testbankstudy.com/product/data-modeling-and-database-design-2nd-edition-by-umanath-scamell-solution-manual/
Language: English
ISBN-10: 1285085256
ISBN-13: 978-1285085258
ISBN-13: 9781285085258
This document provides an overview of entity-relationship (ER) modeling concepts for database design. It defines key ER modeling concepts like entities, attributes, entity types, relationships, relationship types, weak entities, and constraints. It also explains how to represent these concepts in ER diagrams. As an example, it analyzes the requirements for a sample COMPANY database and designs the initial entity types and relationship types that would be represented in an ER diagram for this database.
This presentation discusses the relationship between schema and entity-relationship (E-R) diagrams. It defines key E-R diagram symbols like entities, attributes, and relationships. It then provides examples of how to represent one-to-one, one-to-many, many-to-one, and many-to-many relationships between tables in a relational database through E-R diagrams. Finally, it shows how to design an E-R diagram from a given schema involving bus routes, drivers, schedules, and their relationships.
This document outlines the algorithm for mapping an entity-relationship (EER) model to a relational database schema. It consists of 9 steps:
1) Regular entity types are mapped to relations with their attributes and a primary key.
2) Weak entity types are mapped to relations with owner keys as foreign keys.
3) Binary 1:1 relationships map to foreign keys or merged relations.
4) Binary 1:N relationships map relations with foreign keys.
5) Binary M:N relationships map to relations with foreign keys as primary keys.
6) Multivalued attributes map to relations with foreign keys.
7) N-ary relationships map to relations with foreign keys.
8)
The document discusses how to transform an entity-relationship (ER) diagram into a set of relational tables by representing entities as tables, relationships as links between tables, and enforcing constraints like primary keys and foreign keys. Key steps include representing entities as tables with a primary key, relationships as links between tables with foreign keys, normalizing the tables, and merging the results. Constraints like primary keys must be unique and non-redundant, while foreign keys enforce referential integrity by linking to primary keys.
The document discusses data modeling and the entity-relationship model. It defines key concepts like entities, attributes, relationships, and cardinalities. Entities have attributes and can be connected through relationships. Relationships can be one-to-one, one-to-many, many-to-one, or many-to-many depending on how many entities can be associated with each other. The entity-relationship model is useful for conceptual database design and represents these concepts visually in diagrams.
The document discusses the Entity-Relationship (E-R) model, which was proposed by Dr. Peter Chen in the 1970s as a way to model real-world entities and their relationships. The E-R model uses entities, attributes, and relationships, and allows these concepts to be visually represented in E-R diagrams using basic graphical symbols like rectangles, ellipses, and diamonds. The document also covers E-R modeling concepts like keys, entity types, relationship types, participation constraints, and weak entity sets.
Data modeling using the entity relationship modelJafar Nesargi
The document describes key concepts in entity relationship modeling including entity types, attributes, relationships, keys, and constraints. It provides an example database application to track employees, departments, and projects within a company. It then defines entity types for departments, projects, employees, and dependents with their attributes. It also describes relationship types, cardinalities, roles, and other modeling constructs used to design the conceptual schema.
The document provides an overview of entity-relationship (ER) modeling concepts including entities, attributes, relationships, and ER diagram notation. It then presents an example database application for a company (COMPANY) and defines the entity types, relationship types, and attributes that would be included in an ER diagram for the COMPANY database schema. Key concepts covered include entities, attributes, relationships, cardinalities, participation constraints, and weak entity types.
The document discusses relational database design and normalization. It covers first normal form, functional dependencies, and decomposition. The goal of normalization is to avoid data redundancy and anomalies. First normal form requires attributes to be atomic. Functional dependencies specify relationships between attributes that must be preserved. Decomposition breaks relations into smaller relations while maintaining lossless join properties. Higher normal forms like Boyce-Codd normal form and third normal form further reduce redundancy.
The document discusses relational database design and normalization. It covers topics like functional dependencies, normal forms like first normal form, Boyce-Codd normal form and third normal form. The goal of normalization is to organize data in a database to avoid insertion, deletion and update anomalies. Normalization techniques like decomposition are used to divide tables and isolate data to achieve higher normal forms.
This document discusses database normalization and functional dependencies. It provides examples of 1st, 2nd, and 3rd normal forms. It defines key concepts like functional dependencies, candidate keys, closure of attribute sets, minimal covers, and extraneous attributes. An example of a supplier-parts database is used to illustrate 2nd normal form. Functional dependencies indicate that city and status are not fully functionally dependent on the primary key, so the relation is not in 2nd normal form.
This document provides an overview of relational database design concepts including normal forms and decomposition. It begins with an outline of topics to be covered such as algorithms for functional dependencies, decomposition using multi-valued dependencies, normal forms, and modeling temporal data. The document then reviews Boyce-Codd normal form and provides examples of testing for and decomposing relations into BCNF. It also introduces third normal form and covers testing for and decomposing relations into 3NF. Finally, it briefly discusses multi-valued dependencies and compares BCNF and 3NF.
This document provides an introduction to relational database design and normalization. The goal of normalization is to avoid data redundancy and anomalies. Examples of anomalies include insertion anomalies where new data cannot be added without existing data, and deletion anomalies where deleting data also deletes other related data. The document discusses functional dependencies and normal forms to help guide the decomposition of relations into multiple normalized relations while preserving data integrity and dependencies.
The document discusses various normal forms of database relations including 1NF, 2NF, 3NF, BCNF, 4NF and 5NF. It defines key concepts like functional dependencies, multi-valued dependencies, join dependencies, transitive dependencies and different types of anomalies. Various examples are provided to illustrate normalization techniques to decompose relations to higher normal forms by removing partial, transitive and non-trivial dependencies.
The document discusses functional dependencies and database normalization. It provides examples of functional dependencies and explains key concepts like:
- Functional dependencies define relationships between attributes in a relation.
- Armstrong's axioms are properties used to derive functional dependencies.
- Decomposition aims to eliminate redundancy and anomalies by breaking relations into smaller, normalized relations while preserving information and dependencies.
- A decomposition is lossless if it does not lose any information, and dependency preserving if the original dependencies can be maintained on the decomposed relations.
The document discusses database normalization and relational design. It defines key concepts like functional dependencies, normal forms (1NF, 2NF, 3NF, BCNF), and normalization. The goal of normalization is to decompose relations to eliminate update anomalies and redundancy. Normalization involves breaking relations into smaller relations based on their keys and functional dependencies until they satisfy a certain normal form like BCNF. The document provides examples of functional dependencies, update anomalies, and how to decompose a relation in 3NF that is not in BCNF.
1. The document discusses guidelines for designing relational databases, including avoiding redundant data and update anomalies through normalization.
2. It introduces the concepts of functional dependencies and keys to define normal forms like 1NF, 2NF, 3NF and BCNF.
3. The goal of normalization is to decompose relations into smaller relations in higher normal forms to reduce anomalies and inconsistencies that can occur from modifications to the database.
The document discusses Boyce-Codd normal form (BCNF) and third normal form (3NF). It begins by defining BCNF, providing an example of a relation that is not in BCNF and its lossless-join decomposition into relations that are in BCNF. It then discusses testing relations for BCNF and outlines algorithms for decomposing a relation into BCNF and 3NF. The key differences between BCNF and 3NF are that 3NF allows some redundancy but ensures dependency preservation, while BCNF eliminates redundancy but may not preserve dependencies.
The document discusses advanced database normalization theory including multivalued dependencies, join dependencies, and domain-key normal form. It defines inference rules for deducing implied dependencies, explains how to normalize a schema to higher normal forms like project-join normal form using dependencies, and gives examples of applying these concepts and normalization rules.
This document discusses database normalization and functional dependencies. It defines functional dependencies and describes how to identify them. The goals of normalization are to avoid redundant data, ensure relationships between attributes are represented, and facilitate checking updates. Normalization is done in steps to produce relations in first normal form, second normal form, third normal form and higher. Functional dependencies are used to test for superkeys and check if other dependencies are implied. The document also covers closure of attribute sets and computing the canonical cover of a set of dependencies.
This document discusses relational database design and functional dependencies. It covers topics like normal forms, decomposition using functional dependencies, closure of functional dependencies, and different types of functional dependencies like trivial, non-trivial, transitive, and multivalued dependencies. Examples are provided to illustrate concepts like lossy decomposition and closure of a set of functional dependencies.
The document discusses relational database design and normalization. It covers informal design guidelines, functional dependencies, and different normal forms including 1NF, 2NF, 3NF and BCNF. Keys, attributes, and normalization are formally defined. Examples are provided to illustrate update anomalies and how to normalize relations to higher normal forms by decomposing them based on functional dependencies.
This document discusses relational database design and normalization. It introduces first normal form, which requires that attribute domains be atomic. Functional dependencies are defined as constraints specifying that values in one attribute determine values in another. Normalization aims to avoid redundancy and capture relationships between attributes. The closure of a set of functional dependencies and attribute sets are computed to help analyze dependencies and determine candidate keys.
This document discusses relational database design and normalization. It introduces key concepts like functional dependencies, normal forms including first, second, third and Boyce-Codd normal form. Normalization aims to decompose relations into good forms to avoid redundancy and anomalies. Functional dependencies are used to test relations and determine dependencies between attributes. The closure of functional dependencies and attribute sets are computed to help determine candidate keys and whether dependencies hold. A canonical cover represents a minimal set of dependencies.
The document provides an overview of functional dependencies and database normalization. It discusses four informal design guidelines for relational databases: 1) design relations so their meaning is clear, 2) avoid anomalies, 3) avoid null values, and 4) avoid spurious tuples. It then covers functional dependencies, inference rules, equivalence, and normal forms including 1NF, 2NF, 3NF and BCNF. The goals of normalization are also summarized as reducing redundancy, anomalies, and producing high quality schemas. Examples are provided to illustrate each concept.
This document discusses relational database design and normalization. It introduces concepts like first normal form, functional dependencies, and decomposition. The goal of normalization is to decompose relations into good forms based on functional dependencies, avoiding redundancy and inconsistencies. Normal forms like second, third, and Boyce-Codd normal form are defined to evaluate relation designs and guide decompositions into lossless and dependency-preserving forms.
This document provides an overview of data modeling and SQL. It introduces key concepts in relational databases including relations, schemas, tuples, domains, keys, and referential integrity. It also describes the relational data model including the structure of relations, attributes, and relation instances. Finally, it covers the relational algebra including operations like select, project, join, union, difference, and rename that form the basis for SQL queries. The document uses examples from a banking domain to illustrate these concepts.
This document provides an overview of resolution in propositional logic. It introduces resolution as a new rule of inference that allows inferring a resolvent clause from two clauses. It describes how to convert arbitrary well-formed formulas into conjunctions of clauses to use with resolution. Resolution refutations are discussed as a way to decide logical entailments by attempting to derive the empty clause. Various strategies for conducting resolution refutation searches more efficiently are also covered, including ordering strategies and refinement strategies. Finally, the document defines Horn clauses and their special properties that allow for linear-time deduction algorithms.
This document provides an overview of the Propositional Calculus. It discusses:
- The language of propositional calculus using atoms, connectives, and well-formed formulas
- Rules of inference like modus ponens, conjunction introduction, and disjunction introduction
- Defining proofs and theorems based on applying rules of inference
- Semantics by associating logical elements with truth values under interpretations
- Important concepts like validity, equivalence, entailment, and the soundness and completeness of rules of inference.
- The propositional satisfiability (PSAT) problem and solving techniques like exhaustive search and GSAT.
This document discusses adversarial search techniques for two-agent games with perfect information. It introduces the minimax procedure and how it recursively assigns values to nodes in a game tree by maximizing the value for the maximizing agent and minimizing for the minimizing agent. The alpha-beta pruning technique is described which improves search efficiency by pruning subtrees that cannot alter the minimax value of the root. Examples of applying minimax and alpha-beta to tic-tac-toe are provided. The document also discusses handling games of chance using expectimax search and learning effective evaluation functions from self-play.
This document discusses different approaches to solving constraint satisfaction problems including assignment problems. It provides examples of the eight queens problem and constraint propagation techniques. Constructive methods start with no assignments and add values satisfying constraints, while heuristic repair starts with a proposed solution and changes it to violate fewer constraints. Function optimization techniques like hill climbing and simulated annealing are also discussed.
The document discusses different methods for reinforcement learning, including learning heuristic functions from experiences, learning in explicit and implicit graphs, using rewards instead of goals for tasks, and different algorithms like temporal difference learning and value iteration that help agents learn optimal policies by assigning credit to relevant state-action pairs.
The document describes planning techniques in artificial intelligence, including STRIPS planning systems, forward and backward search methods, and partial-order planning. It discusses how STRIPS uses operators to describe state changes and searches for a sequence of actions to reach a goal state. Backward search methods work by regressing goals through operators to produce subgoals. Partial-order planning searches a plan space by transforming incomplete plans into more articulated plans until finding an executable plan.
This document provides an overview of the Situation Calculus, a formal logic framework for representing states, actions, and how actions transform states. It describes key components of the Situation Calculus including: (1) representing states as constants and using predicates to describe state properties, (2) representing actions and how they change state properties using effect axioms, (3) using frame axioms to represent properties that don't change with actions, and (4) generating plans by proving the existence of goal states and extracting the actions. Challenges with the approach include dealing with ramifications of actions and specifying all relevant preconditions and qualifications.
The document provides an overview of learning Bayes networks from data. It discusses learning the structure and conditional probability tables (CPTs) of a Bayes network given training data. When the network structure is known, the CPTs can be directly estimated from sample statistics in the training data, handling both cases of complete and missing data using techniques like expectation-maximization. When the structure is unknown, scoring metrics like minimum description length are used to search the space of possible structures to find the best fitting network. Dynamic decision networks extend this framework to model sequential decision making problems.
This document outlines probabilistic inference in Bayes networks. It begins with a review of probability theory concepts like joint probability, marginal probability, conditional probability, and Bayes' rule. It then discusses probabilistic inference in Bayes networks, including causal/top-down inference using evidence to determine probabilities, diagnostic/bottom-up inference using effects to determine causes, and "explaining away" where additional evidence makes other probabilities less certain. The document also covers uncertain evidence, D-separation to determine conditional independence, and inference techniques in polytrees.
This document discusses representing commonsense knowledge. It describes commonsense knowledge as everyday facts that most people understand, like objects falling when dropped or fish needing water. Representing all commonsense knowledge is difficult as there are no defined boundaries and some concepts cannot be described with sentences alone. The document outlines research areas in representing objects, materials, space, time, and physical processes. It also discusses knowledge representation using semantic networks and frames to organize taxonomic hierarchies and relationships between objects, properties, and categories in a graph structure. Nonmonotonic reasoning is also discussed for handling exceptions to default inferences.
Rule-based expert systems use facts and rules to achieve expert-level competence in solving problems. They consist of a knowledge base containing facts and rules, an inference engine that manipulates the knowledge base to deduce information, and an explanation subsystem. Rule-based systems apply logical rules to the known facts to determine unknown information. Inductive logic programming learns rules by generalizing from examples to cover positive instances while avoiding negative ones.
The document discusses knowledge-based systems and their ability to reason over extensive knowledge bases. It addresses the theoretical problems of soundness, completeness, and tractability when using logical reasoning systems. Horn clauses and PROLOG are introduced as more efficient ways to perform inference compared to full predicate calculus. Different methods for reasoning including forward chaining and truth and assumption-based maintenance are also summarized.
This document discusses resolution in predicate calculus. It covers topics like unification, predicate calculus resolution, converting well-formed formulas to clause form, using resolution to prove theorems, and answer extraction. It also discusses the equality predicate and paramodulation inference rule. The document provides examples to illustrate various concepts and techniques in resolution-based automated theorem proving in first-order logic.
This document provides an outline and overview of key concepts in resolution in predicate calculus, including:
- Unification, which allows resolving clauses that have matching but complementary literals
- Converting formulas to clause form by eliminating quantifiers and connectives
- Using resolution to prove theorems by deriving the empty clause
- The equality predicate and paramodulation, an inference rule used with resolution when equality is present
The document describes these concepts over multiple sections and provides examples to illustrate predicate calculus resolution.
The document discusses the predicate calculus and its use for representing knowledge. It introduces the motivation and basic components of the predicate calculus language, including terms, well-formed formulas, and quantifiers. It explains the semantics of the language including interpretations, models, and the semantics of quantifiers. Finally, it provides examples of how predicate calculus can be used to conceptualize and represent knowledge about the world.
This document discusses various heuristic search algorithms including A*, iterative-deepening A*, and recursive best-first search. It begins by introducing the concept of using evaluation functions to guide best-first search and preferentially expand nodes with lower heuristic values. It then presents the general graph search algorithm and describes how A* specifically reorders nodes using an evaluation function that considers path cost and estimated cost to the goal. Consistency conditions for the heuristic function are discussed which guarantee A* finds optimal solutions.
This document discusses uninformed search algorithms. It outlines breadth-first search, depth-first search, and iterative deepening search. Breadth-first search finds the shortest path but uses exponential memory. Depth-first search uses linear memory but may explore large parts of the search space without finding the goal. Iterative deepening search combines the benefits of depth-first search and guarantees of finding the shortest solution like breadth-first search.
This document discusses different approaches to implementing agents, including memory-based vs computation-based implementations. A computation-based approach reduces memory requirements by specifying computations rather than anticipating all possible situations. These computations can potentially be learned to allow the agent to handle unforeseen environments. State-space graphs are proposed to model environments as nodes connected by operators representing actions and their effects. Search algorithms like breadth-first search can be applied to state-space graphs to find sequences of operators or plans to reach goal states.
This document discusses computer vision and robot vision. It describes early work using artificial neural networks to allow a robot to steer a vehicle based on camera images (ALVINN system). The document outlines the two main stages of robot vision: image processing and scene analysis. Image processing transforms raw images, e.g. through averaging, edge enhancement, and region finding algorithms. Scene analysis extracts task-specific information by interpreting lines, curves, and applying model-based approaches to reconstruct scenes from primitive 3D objects. Stereo vision obtains depth information through triangulation using two camera images.
The document discusses state machines and how they can be used to model agents that interact with an environment. A state machine represents the state of the environment using feature vectors and computes actions based on the current state. It can improve accuracy by taking into account previous states and actions. The document provides examples of how state machines can be used to model boundary-following robots and how neural networks like the Elman network can learn state representations. It also discusses other representations like iconic models and artificial potential fields, as well as blackboard systems for problem solving.
2. Roadmap of This Lecture
Features of Good Relational Design
Atomic Domains and First Normal Form
Decomposition Using Functional Dependencies
Functional Dependency Theory
Algorithms for Functional Dependencies
2
3. Goal of Design
Generate a set of relational schemas that
Do not have unnecessary redundancies;
Allow easy retrieval of data.
General approach is to design schemas that are in a desireable
normal form.
We may need more info about the real world enterprise than what’s in
the E-R diagram.
3
4. Larger Schemas?
Suppose we combine instructor and department into inst_dept
(No connection to relationship set inst_dept)
Result is possible repetition of information
4
5. A Combined Schema Without Repetition
Consider combining relations
sec_class(sec_id, building, room_number) and
section(course_id, sec_id, semester, year)
into one relation
section(course_id, sec_id, semester, year,
building, room_number)
No repetition in this case
5
6. What About Smaller Schemas?
Suppose we had started with inst_dept. How would we know to split up
(decompose) it into instructor and department?
6
7. Decomposition
Write a rule “if there were a schema (dept_name, building, budget), then
dept_name would be a candidate key”
Denote as a functional dependency:
dept_name building, budget
In inst_dept, because dept_name is not a candidate key, the building
and budget of a department may have to be repeated.
This indicates the need to decompose inst_dept
Not all decompositions are good. Suppose we decompose
employee(ID, name, street, city, salary) into
employee1 (ID, name)
employee2 (name, street, city, salary)
The next slide shows how we lose information -- we cannot reconstruct
the original employee relation -- and so, this is a lossy decomposition.
7
9. Example of Lossless-Join Decomposition
Lossless join decomposition
Decomposition of R = (A, B, C)
R1 = (A, B) R2 = (B, C)
A B
1
2
A
B
1
2
r B,C(r)
A (r) B (r)
A B
1
2
C
A
B
B
1
2
C
A
B
C
A
B
A,B(r)
9
10. First Normal Form
Domain is atomic if its elements are considered to be indivisible units
Examples of non-atomic domains:
Set of names, composite attributes
Identification numbers like CS101 that can be broken up into
parts
A relational schema R is in first normal form if the domains of all
attributes of R are atomic
Non-atomic values complicate storage and encourage redundant
(repeated) storage of data
Example: Set of accounts stored with each customer, and set of
owners stored with each account
We assume all relations are in first normal form (and revisit this
later in Object Based Databases)
10
11. First Normal Form (Cont’d)
Atomicity is actually a property of how the elements of the domain are
used.
Example: Strings would normally be considered indivisible
Suppose that students are given roll numbers which are strings of
the form CS0012 or EE1127
If the first two characters are extracted to find the department, the
domain of roll numbers is not atomic.
Doing so is a bad idea: leads to encoding of information in
application program rather than in the database.
11
12. Goal — Devise a Theory for the Following
Decide whether a particular relation R is in “good” form.
In the case that a relation R is not in “good” form, decompose it into a
set of relations {R1, R2, ..., Rn} such that
each relation is in good form
the decomposition is a lossless-join decomposition
Our theory is based on:
functional dependencies
multivalued dependencies
12
13. Functional Dependencies
Constraints on the set of legal relations.
Require that the value for a certain set of attributes determines
uniquely the value for another set of attributes.
A functional dependency is a generalization of the notion of a key.
13
14. Functional Dependencies (Cont.)
Let R be a relation schema
R and R
The functional dependency
holds on R if and only if for any legal relations r(R), whenever any
two tuples t1 and t2 of r agree on the attributes , they also agree
on the attributes . That is,
t1[] = t2 [] t1[ ] = t2 [ ]
Example: Consider r(A,B ) with the following instance of r.
On this instance, A B does NOT hold, but B A does hold.
1 4
1 5
3 7
14
15. Functional Dependencies (Cont.)
K is a superkey for relation schema R if and only if K R
K is a candidate key for R if and only if
K R, and
for no K, R
Functional dependencies allow us to express constraints that cannot be
expressed using superkeys. Consider the schema:
inst_dept (ID, name, salary, dept_name, building, budget ).
We expect these functional dependencies to hold:
dept_name building
and ID building
but would not expect the following to hold:
dept_name salary
15
16. Use of Functional Dependencies
We use functional dependencies to:
test relations to see if they are legal under a given set of functional
dependencies.
If a relation r is legal under a set F of functional dependencies, we
say that r satisfies F.
specify constraints on the set of legal relations
We say that F holds on R if all legal relations on R satisfy the set
of functional dependencies F.
Note: A specific instance of a relation schema may satisfy a functional
dependency even if the functional dependency does not hold on all legal
instances.
For example, a specific instance of instructor may, by chance, satisfy
name ID.
16
17. Functional Dependencies (Cont.)
A functional dependency is trivial if it is satisfied by all instances of a
relation
Example:
ID, name ID
name name
In general, is trivial if
17
18. Closure of a Set of Functional
Dependencies
Given a set F of functional dependencies, there are certain other
functional dependencies that are logically implied by F.
For example: If A B and B C, then we can infer that A C
The set of all functional dependencies logically implied by F is the
closure of F.
We denote the closure of F by F+.
F+ is a superset of F.
18
19. Boyce-Codd Normal Form
is trivial (i.e., )
is a superkey for R
A relation schema R is in BCNF with respect to a set F of
functional dependencies if for all functional dependencies in F+ of
the form
where R and R, at least one of the following holds:
Example schema not in BCNF:
instr_dept (ID, name, salary, dept_name, building, budget )
because dept_name building, budget
holds on instr_dept, but dept_name is not a superkey
19
20. Decomposing a Schema into BCNF
Suppose we have a schema R and a non-trivial dependency
causes a violation of BCNF.
We decompose R into:
• ( U )
• ( R - ( - ) )
In our example,
= dept_name
= building, budget
and inst_dept is replaced by
( U ) = ( dept_name, building, budget )
( R - ( - ) ) = ( ID, name, salary, dept_name )
20
21. BCNF and Dependency Preservation
Constraints, including functional dependencies, are costly to check in
practice unless they pertain to only one relation
If it is sufficient to test only those dependencies on each individual
relation of a decomposition in order to ensure that all functional
dependencies hold, then that decomposition is dependency
preserving.
That is no need to test a b where a is in one relation and b is in
another.
Because it is not always possible to achieve both BCNF and
dependency preservation, we consider a weaker normal form, known
as third normal form.
21
22. Third Normal Form
A relation schema R is in third normal form (3NF) if for all:
in F+
at least one of the following holds:
is trivial (i.e., )
is a superkey for R
Each attribute A in – is contained in a candidate key for R.
(NOTE: each attribute may be in a different candidate key)
If a relation is in BCNF it is in 3NF (since in BCNF one of the first two
conditions above must hold).
Third condition is a minimal relaxation of BCNF to ensure dependency
preservation (will see why later).
22
23. Goals of Normalization
Let R be a relation schema with a set F of functional dependencies.
Decide whether a relation schema R is in “good” form.
In the case that a relation schema R is not in “good” form,
decompose it into a set of relation schemas {R1, R2, ..., Rn} such that
each relation schema is in good form
the decomposition is a lossless-join decomposition
Preferably, the decomposition should be dependency preserving.
23
24. How good is BCNF?
There are database schemas in BCNF that do not seem to be
sufficiently normalized
Consider a relation
inst_info (ID, child_name, phone)
where an instructor may have more than one phone and can have
multiple children
ID child_name phone
99999
99999
99999
99999
David
David
William
William
512-555-1234
512-555-4321
512-555-1234
512-555-4321
inst_info
24
25. There are no non-trivial functional dependencies and therefore the
relation is in BCNF
Insertion anomalies – i.e., if we add a phone 981-992-3443 to 99999,
we need to add two tuples
(99999, David, 981-992-3443)
(99999, William, 981-992-3443)
How good is BCNF? (Cont.)
25
26. Therefore, it is better to decompose inst_info into:
This suggests the need for higher normal forms, such as Fourth
Normal Form (4NF), which we shall see later.
How good is BCNF? (Cont.)
ID child_name
99999
99999
99999
99999
David
David
William
Willian
inst_child
ID phone
99999
99999
99999
99999
512-555-1234
512-555-4321
512-555-1234
512-555-4321
inst_phone
26
27. Functional-Dependency Theory
We now consider the formal theory that tells us which functional
dependencies are implied logically by a given set of functional
dependencies.
We then develop algorithms to generate lossless decompositions into
BCNF and 3NF
We then develop algorithms to test if a decomposition is dependency-
preserving
27
28. Closure of a Set of Functional
Dependencies
We can find F+, the closure of F, by repeatedly applying
Armstrong’s Axioms:
if , then (reflexivity)
if , then (augmentation)
if , and , then (transitivity)
These rules are
sound (generate only functional dependencies that actually hold),
and
complete (generate all functional dependencies that hold).
28
29. Example
R = (A, B, C, G, H, I)
F = { A B
A C
CG H
CG I
B H}
some members of F+
A H
by transitivity from A B and B H
AG I
by augmenting A C with G, to get AG CG
and then transitivity with CG I
CG HI
by augmenting CG I to infer CG CGI,
and augmenting of CG H to infer CGI HI,
and then transitivity
29
30. Procedure for Computing F+
To compute the closure of a set of functional dependencies F:
F + = F
repeat
for each functional dependency f in F+
apply reflexivity and augmentation rules on f
add the resulting functional dependencies to F +
for each pair of functional dependencies f1and f2 in F +
if f1 and f2 can be combined using transitivity
then add the resulting functional dependency to F +
until F + does not change any further
NOTE: We shall see an alternative procedure for this task later
30
31. Closure of Functional Dependencies
(Cont.)
Additional rules:
If holds and holds, then holds (union)
If holds, then holds and holds
(decomposition)
If holds and holds, then holds
(pseudotransitivity)
The above rules can be inferred from Armstrong’s axioms.
31
32. Closure of Attribute Sets
Given a set of attributes , define the closure of under F (denoted
by +) as the set of attributes that are functionally determined by
under F
Algorithm to compute +, the closure of under F
result := ;
while (changes to result) do
for each in F do
begin
if result then result := result
end
32
33. Example of Attribute Set Closure
R = (A, B, C, G, H, I)
F = {A B
A C
CG H
CG I
B H}
(AG)+
1. result = AG
2. result = ABCG (A C and A B)
3. result = ABCGH (CG H and CG ABCG)
4. result = ABCGHI (CG I and CG ABCGH)
Is AG a candidate key?
1. Is AG a super key?
1. Does AG R? == Is (AG)+ R
2. Is any subset of AG a superkey?
1. Does A R? == Is (A)+ R
2. Does G R? == Is (G)+ R
33
34. Uses of Attribute Closure
There are several uses of the attribute closure algorithm:
Testing for superkey:
To test if is a superkey, we compute +, and check if + contains
all attributes of R.
Testing functional dependencies
To check if a functional dependency holds (or, in other
words, is in F+), just check if +.
That is, we compute + by using attribute closure, and then check
if it contains .
Is a simple and cheap test, and very useful
Computing closure of F
For each R, we find the closure +, and for each S +, we
output a functional dependency S.
34
35. Canonical Cover
Sets of functional dependencies may have redundant dependencies
that can be inferred from the others
For example: A C is redundant in: {A B, B C, A C}
Parts of a functional dependency may be redundant
E.g.: on RHS: {A B, B C, A CD} can be simplified
to
{A B, B C, A D}
E.g.: on LHS: {A B, B C, AC D} can be simplified
to
{A B, B C, A D}
Intuitively, a canonical cover of F is a “minimal” set of functional
dependencies equivalent to F, having no redundant dependencies or
redundant parts of dependencies
35
36. Extraneous Attributes
Consider a set F of functional dependencies and the functional
dependency in F.
Attribute A is extraneous in if A
and F logically implies (F – { }) {( – A) }.
Attribute A is extraneous in if A
and the set of functional dependencies
(F – { }) { ( – A)} logically implies F.
Note: implication in the opposite direction is trivial in each of the
cases above, since a “stronger” functional dependency always
implies a weaker one
Example: Given F = {A C, AB C }
B is extraneous in AB C because {A C, AB C} logically
implies A C (I.e. the result of dropping B from AB C).
Example: Given F = {A C, AB CD}
C is extraneous in AB CD since AB C can be inferred from
A C, and then by union rule AB CD.
36
37. Testing if an Attribute is Extraneous
Consider a set F of functional dependencies and the functional
dependency in F.
To test if attribute A is extraneous in
1. compute ({} – A)+ using the dependencies in F
2. check that ({} – A)+ contains ; if it does, A is extraneous in
To test if attribute A is extraneous in
1. compute + using only the dependencies in
F’ = (F – { }) { ( – A)},
2. check that + contains A; if it does, A is extraneous in
37
38. Canonical Cover
A canonical cover for F is a set of dependencies Fc such that
F logically implies all dependencies in Fc, and
Fc logically implies all dependencies in F, and
No functional dependency in Fc contains an extraneous attribute, and
Each left side of functional dependency in Fc is unique.
To compute a canonical cover for F:
repeat
Use the union rule to replace any dependencies in F
1 1 and 1 2 with 1 1 2
Find a functional dependency with an
extraneous attribute either in or in
/* Note: test for extraneous attributes done using Fc, not F */
If an extraneous attribute is found, delete it from
until F does not change
Note: Union rule may become applicable after some extraneous attributes
have been deleted, so it has to be re-applied
38
39. Computing a Canonical Cover
R = (A, B, C)
F = {A BC
B C
A B
AB C}
Combine A BC and A B into A BC
Set is now {A BC, B C, AB C}
A is extraneous in AB C
Check if the result of deleting A from AB C is implied by the other
dependencies
Yes: in fact, B C is already present!
Set is now {A BC, B C}
C is extraneous in A BC
Check if A C is logically implied by A B and the other dependencies
Yes: using transitivity on A B and B C.
– Can use attribute closure of A in more complex cases
The canonical cover is: A B
B C
39
40. Lossless-join Decomposition
For the case of R = (R1, R2), we require that for all possible relations r
on schema R
r = R1 (r ) R2 (r )
A decomposition of R into R1 and R2 is lossless join if at least one of
the following dependencies is in F+:
R1 R2 R1
R1 R2 R2
The above functional dependencies are a sufficient condition for
lossless join decomposition; the dependencies are a necessary
condition only if all constraints are functional dependencies
40
41. Example
R = (A, B, C)
F = {A B, B C)
Can be decomposed in two different ways
R1 = (A, B), R2 = (B, C)
Lossless-join decomposition:
R1 R2 = {B} and B BC
Dependency preserving
R1 = (A, B), R2 = (A, C)
Lossless-join decomposition:
R1 R2 = {A} and A AB
Not dependency preserving
(cannot check B C without computing R1 R2)
41
42. Dependency Preservation
Let Fi be the set of dependencies in F + that include only attributes
in Ri.
A decomposition is dependency preserving, if
(F1 F2 … Fn )+ = F +
If it is not, then checking updates for violation of functional
dependencies may require computing joins, which is
expensive.
42
43. Testing for Dependency Preservation
To check if a dependency is preserved in a decomposition of R
into R1, R2, …, Rn we apply the following test (with attribute closure
done with respect to F)
result =
while (changes to result) do
for each Ri in the decomposition
t = (result Ri)+ Ri
result = result t
If result contains all attributes in , then the functional dependency
is preserved.
We apply the test on all dependencies in F to check if a
decomposition is dependency preserving
This procedure takes polynomial time, instead of the exponential time
required to compute F+ and (F1 F2 … Fn)+
43
44. Example
R = (A, B, C )
F = {A B
B C}
Key = {A}
R is not in BCNF
Decomposition R1 = (A, B), R2 = (B, C)
R1 and R2 in BCNF
Lossless-join decomposition
Dependency preserving
44