Other Dependencies and Normal Forms
16.6 Other Dependencies and Normal Forms
We already introduced another type of dependency called join dependency (JD) in Section 15.7. It arises when a relation is decomposable into a set of projected rela- tions that can be joined back to yield the original relation. After defining JD, we defined the fifth normal form based on it in Section 15.7. In the present section we will introduce some other types of dependencies that have been identified.
16.6.1 Inclusion Dependencies
Inclusion dependencies were defined in order to formalize two types of interrela- tional constraints:
The foreign key (or referential integrity) constraint cannot be specified as a functional or multivalued dependency because it relates attributes across relations.
The constraint between two relations that represent a class/subclass relation- ship (see Chapters 8 and 9) also has no formal definition in terms of the functional, multivalued, and join dependencies.
Definition. An inclusion dependency R.X < S.Y between two sets of attrib- utes—X of relation schema R, and Y of relation schema S—specifies the con-
straint that, at any specific time when r is a relation state of R and s a relation state of S, we must have
π X (r(R)) ⊆ π Y (s(S)) The ⊆ (subset) relationship does not necessarily have to be a proper subset.
Obviously, the sets of attributes on which the inclusion dependency is specified—X of R and Y of S—must have the same number of attributes. In addition, the
domains for each pair of corresponding attributes should be compatible. For exam- ple, if X = {A 1 ,A 2 , ..., A n } and Y = {B 1 ,B 2 , ..., B n }, one possible correspondence is to have dom(A i ) compatible with dom(B i ) for 1 ≤ i ≤ n. In this case, we say that A i corresponds to B i .
For example, we can specify the following inclusion dependencies on the relational schema in Figure 15.1:
DEPARTMENT.Dmgr_ssn < EMPLOYEE.Ssn WORKS_ON.Ssn < EMPLOYEE.Ssn EMPLOYEE.Dnumber < DEPARTMENT.Dnumber
PROJECT.Dnum < DEPARTMENT.Dnumber WORKS_ON.Pnumber < PROJECT.Pnumber
DEPT_LOCATIONS.Dnumber < DEPARTMENT.Dnumber All the preceding inclusion dependencies represent referential integrity
constraints . We can also use inclusion dependencies to represent class/subclass
572 Chapter 16 Relational Database Design Algorithms and Further Dependencies
relationships . For example, in the relational schema of Figure 9.6, we can specify the following inclusion dependencies:
EMPLOYEE.Ssn < PERSON.Ssn ALUMNUS.Ssn < PERSON.Ssn STUDENT.Ssn < PERSON.Ssn
As with other types of dependencies, there are inclusion dependency inference rules (IDIRs). The following are three examples:
IDIR1 (reflexivity): R.X < R.X.
IDIR2 (attribute correspondence): If R.X < S.Y, where X = {A 1 ,A 2 , ..., A n } and Y = {B 1 ,B 2 , ..., B n } and A i corresponds to B i , then R.A i < S.B i for 1 ≤ i ≤ n.
IDIR3 (transitivity): If R.X < S.Y and S.Y < T.Z, then R.X < T.Z. The preceding inference rules were shown to be sound and complete for inclusion
dependencies. So far, no normal forms have been developed based on inclusion dependencies.
16.6.2 Template Dependencies
Template dependencies provide a technique for representing constraints in relations that typically have no easy and formal definitions. No matter how many types of dependencies we develop, some peculiar constraint may come up based on the semantics of attributes within relations that cannot be represented by any of them. The idea behind template dependencies is to specify a template—or example—that defines each constraint or dependency.
There are two types of templates: tuple-generating templates and constraint- generating templates. A template consists of a number of hypothesis tuples that are meant to show an example of the tuples that may appear in one or more relations. The other part of the template is the template conclusion. For tuple-generating templates, the conclusion is a set of tuples that must also exist in the relations if the hypothesis tuples are there. For constraint-generating templates, the template con- clusion is a condition that must hold on the hypothesis tuples. Using constraint- generating templates, we are able to define semantic constraints—those that are beyond the scope of the relational model in terms of its data definition language and notation.
Figure 16.5 shows how we may define functional, multivalued, and inclusion dependencies by templates. Figure 16.6 shows how we may specify the constraint that an employee’s salary cannot be higher than the salary of his or her direct supervisor on the relation schema EMPLOYEE in Figure 3.5.
16.6 Other Dependencies and Normal Forms 573
Figure 16.5
Templates for some common type of dependencies. (a) Template for functional dependency X → Y.
(b) Template for the multivalued dependency X → → Y. (c) Template for the inclusion dependency R.X < S.Y.
(a)
R = {A, B, C, D}
Hypothesis a 1 b 1 c 1 d 1 X = {A, B} a 1 b 1 c 2 d 2 Y = {C, D}
Hypothesis a 1 b 1 c 1 d 1 X = {A, B} a 1 b 1 c 2 d 2 Y = {C}
Conclusion
(c)
X = {C, D} Hypothesis
R = {A, B, C, D}
S = {E, F, G}
a 1 b 1 c 1 d 1 Y = {E, F} Conclusion
Figure 16.6
Templates for the constraint that an employee’s salary must be less than the supervisor’s salary.
EMPLOYEE = {Name, Ssn, . . . , Salary, Supervisor_ssn}
Hypothesis
Conclusion
c<f
574 Chapter 16 Relational Database Design Algorithms and Further Dependencies
16.6.3 Functional Dependencies Based on Arithmetic
Functions and Procedures
Sometimes some attributes in a relation may be related via some arithmetic func- tion or a more complicated functional relationship. As long as a unique value of Y is associated with every X, we can still consider that the FD X → Y exists. For example, in the relation
ORDER_LINE ( Order# , Item# , Quantity , Unit_price , Extended_price , Discounted_price )
each tuple represents an item from an order with a particular quantity, and the price per unit for that item. In this relation, ( Quantity , Unit_price )→ Extended_price by the formula
Extended_price = Unit_price * Quantity. Hence, there is a unique value for Extended_price for every pair ( Quantity , Unit_price ),
and thus it conforms to the definition of functional dependency. Moreover, there may be a procedure that takes into account the quantity discounts,
the type of item, and so on and computes a discounted price for the total quantity ordered for that item. Therefore, we can say
( Item# , Quantity , Unit_price ) → Discounted_price , or ( Item# , Quantity , Extended_price ) → Discounted_price.
To check the above FD, a more complex procedure COMPUTE_TOTAL_PRICE may have to be called into play. Although the above kinds of FDs are technically present in most relations, they are not given particular attention during normalization.
16.6.4 Domain-Key Normal Form
There is no hard-and-fast rule about defining normal forms only up to 5NF. Historically, the process of normalization and the process of discovering undesir- able dependencies were carried through 5NF, but it has been possible to define stricter normal forms that take into account additional types of dependencies and constraints. The idea behind domain-key normal form (DKNF) is to specify (theo- retically, at least) the ultimate normal form that takes into account all possible types of dependencies and constraints. A relation schema is said to be in DKNF if all con- straints and dependencies that should hold on the valid relation states can be enforced simply by enforcing the domain constraints and key constraints on the relation. For a relation in DKNF, it becomes very straightforward to enforce all data- base constraints by simply checking that each attribute value in a tuple is of the appropriate domain and that every key constraint is enforced.
However, because of the difficulty of including complex constraints in a DKNF rela- tion, its practical utility is limited, since it may be quite difficult to specify general integrity constraints. For example, consider a relation CAR ( Make , Vin# ) (where Vin#
16.7 Summary 575
Country ) (where Country is the country of manufacture). A general constraint may be of the following form: If the Make is either ‘Toyota’ or ‘Lexus,’ then the first character of the Vin# is a ‘J’ if the country of manufacture is ‘Japan’; if the Make is ‘Honda’ or ‘Acura,’ the second character of the Vin# is a ‘J’ if the country of manufacture is ‘Japan.’ There is no simplified way to represent such constraints short of writing a proce- dure (or general assertions) to test them. The procedure COMPUTE_TOTAL_PRICE above is an example of such procedures needed to enforce an appropriate integrity constraint.
Parts
» Fundamentals_of_Database_Systems,_6th_Edition
» Characteristics of the Database Approach
» Advantages of Using the DBMS Approach
» A Brief History of Database Applications
» Schemas, Instances, and Database State
» The Three-Schema Architecture
» The Database System Environment
» Centralized and Client/Server Architectures for DBMSs
» Classification of Database Management Systems
» Domains, Attributes, Tuples, and Relations
» Key Constraints and Constraints on NULL Values
» Relational Databases and Relational Database Schemas
» Integrity, Referential Integrity, and Foreign Keys
» Update Operations, Transactions, and Dealing with Constraint Violations
» SQL Data Definition and Data Types
» Specifying Constraints in SQL
» The SELECT-FROM-WHERE Structure of Basic SQL Queries
» Ambiguous Attribute Names, Aliasing, Renaming, and Tuple Variables
» Substring Pattern Matching and Arithmetic Operators
» INSERT, DELETE, and UPDATE Statements in SQL
» Comparisons Involving NULL and Three-Valued Logic
» Nested Queries, Tuples, and Set/Multiset Comparisons
» The EXISTS and UNIQUE Functions in SQL
» Joined Tables in SQL and Outer Joins
» Grouping: The GROUP BY and HAVING Clauses
» Discussion and Summary of SQL Queries
» Specifying General Constraints as Assertions in SQL
» Introduction to Triggers in SQL
» Specification of Views in SQL
» View Implementation, View Update, and Inline Views
» Schema Change Statements in SQL
» Sequences of Operations and the RENAME Operation
» The UNION, INTERSECTION, and MINUS Operations
» The CARTESIAN PRODUCT (CROSS PRODUCT) Operation
» Variations of JOIN: The EQUIJOIN and NATURAL JOIN
» Additional Relational Operations
» Examples of Queries in Relational Algebra
» The Tuple Relational Calculus
» The Domain Relational Calculus
» Using High-Level Conceptual Data Models
» Entity Types, Entity Sets, Keys, and Value Sets
» Relationship Types, Relationship Sets, Roles, and Structural Constraints
» ER Diagrams, Naming Conventions, and Design Issues
» Example of Other Notation: UML Class Diagrams
» Relationship Types of Degree Higher than Two
» Subclasses, Superclasses, and Inheritance
» Constraints on Specialization and Generalization
» Specialization and Generalization Hierarchies
» Modeling of UNION Types Using Categories
» A Sample UNIVERSITY EER Schema, Design Choices, and Formal Definitions
» Data Abstraction, Knowledge Representation, and Ontology Concepts
» ER-to-Relational Mapping Algorithm
» Discussion and Summary of Mapping for ER Model Constructs
» Mapping EER Model Constructs
» The Role of Information Systems
» The Database Design and Implementation Process
» Use of UML Diagrams as an Aid to Database Design Specification 6
» Rational Rose: A UML-Based Design Tool
» Automated Database Design Tools
» Introduction to Object-Oriented Concepts and Features
» Object Identity, and Objects versus Literals
» Complex Type Structures for Objects and Literals
» Encapsulation of Operations and Persistence of Objects
» Type Hierarchies and Inheritance
» Other Object-Oriented Concepts
» Object-Relational Features: Object Database Extensions to SQL
» Overview of the Object Model of ODMG
» Built-in Interfaces and Classes in the Object Model
» Atomic (User-Defined) Objects
» Extents, Keys, and Factory Objects
» The Object Definition Language ODL
» Differences between Conceptual Design of ODB and RDB
» Mapping an EER Schema to an ODB Schema
» Query Results and Path Expressions
» Overview of the C++ Language Binding in the ODMG Standard
» Structured, Semistructured, and Unstructured Data
» XML Hierarchical (Tree) Data Model
» Well-Formed and Valid XML Documents and XML DTD
» XPath: Specifying Path Expressions in XML
» XQuery: Specifying Queries in XML
» Extracting XML Documents from
» Database Programming: Techniques
» Retrieving Single Tuples with Embedded SQL
» Retrieving Multiple Tuples with Embedded SQL Using Cursors
» Specifying Queries at Runtime Using Dynamic SQL
» SQLJ: Embedding SQL Commands in Java
» Retrieving Multiple Tuples in SQLJ Using Iterators
» Database Programming with SQL/CLI Using C
» JDBC: SQL Function Calls for Java Programming
» Database Stored Procedures and SQL/PSM
» PHP Variables, Data Types, and Programming Constructs
» Overview of PHP Database Programming
» Imparting Clear Semantics to Attributes in Relations
» Redundant Information in Tuples and Update Anomalies
» Normal Forms Based on Primary Keys
» General Definitions of Second and Third Normal Forms
» Multivalued Dependency and Fourth Normal Form
» Join Dependencies and Fifth Normal Form
» Inference Rules for Functional Dependencies
» Minimal Sets of Functional Dependencies
» Properties of Relational Decompositions
» Dependency-Preserving Decomposition
» Dependency-Preserving and Nonadditive (Lossless) Join Decomposition into 3NF Schemas
» Problems with NULL Values and Dangling Tuples
» Discussion of Normalization Algorithms and Alternative Relational Designs
» Further Discussion of Multivalued Dependencies and 4NF
» Other Dependencies and Normal Forms
» Memory Hierarchies and Storage Devices
» Hardware Description of Disk Devices
» Magnetic Tape Storage Devices
» Placing File Records on Disk
» Files of Unordered Records (Heap Files)
» Files of Ordered Records (Sorted Files)
» External Hashing for Disk Files
» Hashing Techniques That Allow Dynamic File Expansion
» Other Primary File Organizations
» Parallelizing Disk Access Using RAID Technology
» Types of Single-Level Ordered Indexes
» Some General Issues Concerning Indexing
» Algorithms for External Sorting
» Implementing the SELECT Operation
» Implementing the JOIN Operation
» Algorithms for PROJECT and Set
» Notation for Query Trees and Query Graphs
» Heuristic Optimization of Query Trees
» Catalog Information Used in Cost Functions
» Examples of Cost Functions for SELECT
» Examples of Cost Functions for JOIN
» Example to Illustrate Cost-Based Query Optimization
» Factors That Influence Physical Database Design
» Physical Database Design Decisions
» An Overview of Database Tuning in Relational Systems
» Transactions, Database Items, Read and Write Operations, and DBMS Buffers
» Why Concurrency Control Is Needed
» Transaction and System Concepts
» Desirable Properties of Transactions
» Serial, Nonserial, and Conflict-Serializable Schedules
» Testing for Conflict Serializability of a Schedule
» How Serializability Is Used for Concurrency Control
» View Equivalence and View Serializability
» Types of Locks and System Lock Tables
» Guaranteeing Serializability by Two-Phase Locking
» Dealing with Deadlock and Starvation
» Concurrency Control Based on Timestamp Ordering
» Multiversion Concurrency Control Techniques
» Validation (Optimistic) Concurrency
» Granularity of Data Items and Multiple Granularity Locking
» Using Locks for Concurrency Control in Indexes
» Other Concurrency Control Issues
» Recovery Outline and Categorization of Recovery Algorithms
» Caching (Buffering) of Disk Blocks
» Write-Ahead Logging, Steal/No-Steal, and Force/No-Force
» Transaction Rollback and Cascading Rollback
» NO-UNDO/REDO Recovery Based on Deferred Update
» Recovery Techniques Based on Immediate Update
» The ARIES Recovery Algorithm
» Recovery in Multidatabase Systems
» Introduction to Database Security Issues 1
» Discretionary Access Control Based on Granting and Revoking Privileges
» Mandatory Access Control and Role-Based Access Control for Multilevel Security
» Introduction to Statistical Database Security
» Introduction to Flow Control
» Encryption and Public Key Infrastructures
» Challenges of Database Security
» Distributed Database Concepts 1
» Types of Distributed Database Systems
» Distributed Database Architectures
» Data Replication and Allocation
» Example of Fragmentation, Allocation, and Replication
» Query Processing and Optimization in Distributed Databases
» Overview of Transaction Management in Distributed Databases
» Overview of Concurrency Control and Recovery in Distributed Databases
» Current Trends in Distributed Databases
» Distributed Databases in Oracle 13
» Generalized Model for Active Databases and Oracle Triggers
» Design and Implementation Issues for Active Databases
» Examples of Statement-Level Active Rules
» Time Representation, Calendars, and Time Dimensions
» Incorporating Time in Relational Databases Using Tuple Versioning
» Incorporating Time in Object-Oriented Databases Using Attribute Versioning
» Temporal Querying Constructs and the TSQL2 Language
» Spatial Database Concepts 24
» Multimedia Database Concepts
» Clausal Form and Horn Clauses
» Datalog Programs and Their Safety
» Evaluation of Nonrecursive Datalog Queries
» Introduction to Information Retrieval
» Types of Queries in IR Systems
» Evaluation Measures of Search Relevance
» Web Analysis and Its Relationship to Information Retrieval
» Analyzing the Link Structure of Web Pages
» Approaches to Web Content Analysis
» Trends in Information Retrieval
» Data Mining as a Part of the Knowledge
» Goals of Data Mining and Knowledge Discovery
» Types of Knowledge Discovered during Data Mining
» Market-Basket Model, Support, and Confidence
» Frequent-Pattern (FP) Tree and FP-Growth Algorithm
» Other Types of Association Rules
» Approaches to Other Data Mining Problems
» Commercial Data Mining Tools
» Data Modeling for Data Warehouses
» Difficulties of Implementing Data Warehouses
» Grouping, Aggregation, and Database Modification in QBE
Show more