Database Management System

Transcription

1 Database Management System Normalization (Unit - IV) NORMALIZATION While designing a database out of an entity relationship model, the main problem existing in that raw database is redundancy. Redundancy is storing the same data item in more one place. A redundancy creates several problems like the following: 1. Extra storage space: storing the same data in many places takes large amount of disk space. 2. Entering same data more than once during data insertion. 3. Deleting data from more than one place during deletion. 4. Modifying data in more than one place. 5. Anomalies may occur in the database if insertion, deletion, modification etc. are no done properly. It creates inconsistency and unreliability in the database. To solve this problem, the raw database needs to be normalized. This is a step by step process of removing different kinds of redundancy and anomaly at each step. At each step a specific rule is followed to remove specific kind of impurity in order to give the database a slim and clean look. Un-Normalized Form (UNF) If a table contains non-atomic values at each row, it is said to be in UNF. An atomic value is something that can not be further decomposed. A non-atomic value, as the name suggests, can be further decomposed and simplified. Consider the following table: Emp-Id Emp-Name Month Sales Bank-Id Bank-Name E01 AA Jan 1000 B01 SBI Feb 1200 Mar 850 E02 BB Jan 2200 B02 UTI Feb 2500 E03 CC Jan 1700 B01 SBI Feb 1800 Mar 1850 Apr 1725 In the sample table above, there are multiple occurrences of rows under each key Emp-Id. Although considered to be the primary key, Emp- Id cannot give us the unique identification facility for any single row. Further, each primary key points to a variable length record (3 for E01, 2 for E02 and 4 for E03). First Normal Form (1NF) A relation is said to be in 1NF if it contains no non-atomic values and each row can provide a unique combination of values. The above table in UNF can be processed to create the following table in 1NF. Emp-Name Month Sales Bank-Id Bank-Name Emp-Id E01 AA Jan 1000 B01 SBI E01 AA Feb 1200 B01 SBI Page 1 of 11

2 E01 AA Mar 850 B01 SBI E02 BB Jan 2200 B02 UTI E02 BB Feb 2500 B02 UTI E03 CC Jan 1700 B01 SBI E03 CC Feb 1800 B01 SBI E03 CC Mar 1850 B01 SBI E03 CC Apr 1725 B01 SBI As you can see now, each row contains unique combination of values. Unlike in UNF, this relation contains only atomic values, i.e. the rows can not be further decomposed, so the relation is now in 1NF. Second Normal Form (2NF) A relation is said to be in 2NF f if it is already in 1NF and each and every attribute fully depends on the primary key of the relation. Speaking inversely, if a table has some attributes which is not dependant on the primary key of that table, then it is not in 2NF. Let us explain. Emp-Id is the primary key of the above relation. Emp-Name, Month, Sales and Bank-Name all depend upon Emp-Id. But the attribute Bank-Name depends on Bank-Id, which is not the primary key of the table. So the table is in 1NF, but not in 2NF. If this position can be removed into another related relation, it would come to 2NF. Emp-Id Emp-Name Month Sales Bank-Id E01 AA JAN 1000 B01 E01 AA FEB 1200 B01 E01 AA MAR 850 B01 E02 BB JAN 2200 B02 E02 BB FEB 2500 B02 E03 CC JAN 1700 B01 E03 CC FEB 1800 B01 E03 CC MAR 1850 B01 E03 CC APR 1726 B01 Bank-Id Bank-Name B01 SBI B02 UTI After removing the portion into another relation we store lesser amount of data in two relations without any loss information. There is also a significant reduction in redundancy. Third Normal Form (3NF) A relation is said to be in 3NF, if it is already in 2NF and there exists no transitive dependency in that relation. Speaking inversely, if a table contains transitive dependency, then it is not in 3NF, and the table must be split to bring it into 3NF. What is a transitive dependency? Within a relation if we see A B [B depends on A] Page 2 of 11

3 And B C [C depends on B] Then we may derive A C[C depends on A] Such derived dependencies hold well in most of the situations. For example if we have Roll Marks And Marks Grade Then we may safely derive Roll Grade. This third dependency was not originally specified but we have derived it. The derived dependency is called a transitive dependency when such dependency becomes improbable. For example we have been given Roll City And City STDCode If we try to derive Roll STDCode it becomes a transitive dependency, because obviously the STDCode of a city cannot depend on the roll number issued by a school or college. In such a case the relation should be broken into two, each containing one of these two dependencies: Roll City And City STD code Boyce-Code Normal Form (BCNF) A relationship is said to be in BCNF if it is already in 3NF and the left hand side of every dependency is a candidate key. A relation which is in 3NF is almost always in BCNF. These could be same situation when a 3NF relation may not be in BCNF the following conditions are found true. 1. The candidate keys are composite. 2. There are more than one candidate keys in the relation. 3. There are some common attributes in the relation. Professor Code Department Head of Dept. Percent Time P1 Physics Ghosh 50 P1 Mathematics Krishnan 50 P2 Chemistry Rao 25 P2 Physics Ghosh 75 P3 Mathematics Krishnan 100 Consider, as an example, the above relation. It is assumed that: 1. A professor can work in more than one department 2. The percentage of the time he spends in each department is given. 3. Each department has only one Head of Department. Page 3 of 11

4 The relation diagram for the above relation is given as the following: The given relation is in 3NF. Observe, however, that the names of Dept. and Head of Dept. are duplicated. Further, if Professor P2 resigns, rows 3 and 4 are deleted. We lose the information that Rao is the Head of Department of Chemistry. The normalization of the relation is done by creating a new relation for Dept. and Head of Dept. and deleting Head of Dept. form the given relation. The normalized relations are shown in the following. Professor Code Department Percent Time P1 Physics 50 P1 Mathematics 50 P2 Chemistry 25 P2 Physics 75 P3 Mathematics 100 Head of Dept. Department Physics Ghosh Mathematics Krishnan Chemistry Rao See the dependency diagrams for these new relations. Page 4 of 11

5 Fourth Normal Form (4NF) When attributes in a relation have multi-valued dependency, further Normalization to 4NF and 5NF are required. Let us first find out what multi-valued dependency is. A multi-valued dependency is a typical kind of dependency in which each and every attribute within a relation depends upon the other, yet none of them is a unique primary key. We will illustrate this with an example. Consider a vendor supplying many items to many projects in an organization. The following are the assumptions: 1. A vendor is capable of supplying many items. 2. A project uses many items. 3. A vendor supplies to many projects. 4. An item may be supplied by many vendors. A multi valued dependency exists here because all the attributes depend upon the other and yet none of them is a primary key having unique value. Vendor Code Item Code Project No. V1 I1 P1 V1 I2 P1 V1 I1 P3 V1 I2 P3 V2 I2 P1 V2 I3 P1 V3 I1 P2 V3 I1 P3 The given relation has a number of problems. For example: 1. If vendor V1 has to supply to project P2, but the item is not yet decided, then a row with a blank for item code has to be introduced. 2. The information about item I1 is stored twice for vendor V3. Observe that the relation given is in 3NF and also in BCNF. It still has the problem mentioned above. The problem is reduced by expressing this relation as two relations in the Fourth Normal Form (4NF). A relation is in 4NF if it has no more than one independent multi valued dependency or one independent multi valued dependency with a functional dependency. The table can be expressed as the two 4NF relations given as following. The fact that vendors are capable of supplying certain items and that they are assigned to supply for some projects in independently specified in the 4NF relation. Vendor-Supply Item Code Vendor Code V1 I1 V1 I2 V2 I2 V2 I3 V3 I1 Vendor-Project Project No. Page 5 of 11

6 Vendor Code V1 V1 V2 V3 P1 P3 P1 P2 Fifth Normal Form (5NF) These relations still have a problem. While defining the 4NF we mentioned that all the attributes depend upon each other. While creating the two tables in the 4NF, although we have preserved the dependencies between Vendor Code and Item code in the first table and Vendor Code and Item code in the second table, we have lost the relationship between Item Code and Project No. If there were a primary key then this loss of dependency would not have occurred. In order to revive this relationship we must add a new table like the following. Please note that during the entire process of normalization, this is the only step where a new table is created by joining two attributes, rather than splitting them into separate tables. Project No. Item Code P1 11 P1 12 P2 11 P3 11 P3 13 Let us finally summarize the normalization steps we have discussed so far. Input Relation Transformation Output Relation All Relations Eliminate variable length record. Remove multi-attribute lines in table. 1NF 1NF Relation Remove dependency of non-key attributes on part of a multi-attribute key. 2NF 2NF Remove dependency of non-key attributes on other non-key attributes. 3NF 3NF Remove dependency of an attribute of a multi attribute key on an attribute of another (overlapping) multiattribute BCNF key. BCNF Remove more than one independent multi-valued dependency from relation by splitting relation. 4NF 4NF Add one relation relating attributes with multi-valued dependency. 5NF Functional Dependency A functional dependency occurs when one attribute in a relation uniquely determines another attribute. This can be written A -> B which would be the same as stating "B is functionally dependent upon A." e.g. In a table listing employee characteristics including Social Security Number (SSN) and name, it can be said that name is functionally dependent upon SSN (or SSN -> name) because an employee's name can be uniquely determined from their SSN. However, the reverse statement (name -> SSN) is not true because more than one employee can have the same name but different SSNs. Types of functional dependencies 1. Trivial Functional Dependencies - A trivial functional dependency occurs when you describe a functional dependency of an attribute on a collection of attributes that includes the original attribute. For example, {A, B} -> B is a trivial functional dependency, as is {name, SSN} - > SSN. This type of functional dependency is called trivial because it can be derived from common sense. It is obvious that if you already know the value of B, then the value of B can be uniquely determined by that knowledge. 2. Full Functional Dependencies - A full functional dependency occurs when you already meet the requirements for a functional dependency and the set of attributes on the left side of the functional dependency statement cannot be reduced any farther. For example, {SSN, age} -> Page 6 of 11

7 name is a functional dependency, but it is not a full functional dependency because you can remove age from the left side of the statement without impacting the dependency relationship. 3. Transitive Dependencies - Transitive dependencies occur when there is an indirect relationship that causes a functional dependency. For example, A -> C is a transitive dependency when it is true only because both A -> B and B -> C are true. 4. Multivalued Dependencies - Multivalued dependencies occur when the presence of one or more rows in a table implies the presence of one or more other rows in that same table. For example, imagine a car company that manufactures many models of car, but always makes both red and blue colors of each model. If you have a table that contains the model name, color and year of each car the company manufactures, there is a multivalued dependency in that table. If there is a row for a certain model name and year in blue, there must also be a similar row corresponding to the red version of that same car. Importance of Dependencies Database dependencies are important to understand because they provide the basic building blocks used in database normalization. For example: For a table to be in second normal form (2NF), there must be no case of a non-prime attribute in the table that is functionally dependendent upon a subset of a candidate key. For a table to be in third normal form (3NF), every non-prime attribute must have a non-transitive functional dependency on every candidate key. For a table to be in Boyce-Codd Normal Form (BCNF), every functional dependency (other than trivial dependencies) must be on a superkey. For a table to be in fourth normal form (4NF), it must have no multivalued dependencies. Closure Let a relation R have some functional dependencies F specified. The closure of F (usually written as F++) is the set of all functional dependencies that may be logically derived from F. Often F is the set of most obvious and important functional dependencies and F+, the closure, is the set of all the functional dependencies including F and those that can be deduced from F. The closure is important and may, for example, be needed in finding one or more candidate keys of the relation. Decomposition Decomposition is the process of breaking a large table into a collection of small tables. This is done in order to reduce the redundancy and complexity of the large table. Lossless-join Decomposition It can also be called Nonadditive. If you decompose a relation R into relations R1 and R2 you will guarantee a Lossless-Join if R1 R2 = R Let R be a relation schema. Let F be a set of functional dependencies on R. Let R1 and R2 form a decomposition of R. The decomposition is a lossless-join decomposition of R if at least one of the following functional dependencies are in F+ (where F+ stands for the closure for every attribute in F): Page 7 of 11

8 R1 R2 R1 R1 R2 R2 Example: Let R = (A, B, C, D) be the relation schema, with A, B, C and D attributes. Let F = {A BC} be the set of functional dependencies. Decomposition into R1= (A, B, C) and R2 = (A, D) is lossless under F because R1 R2 = (A) and A ABC so R1 R2 R1. Dependency Preservation The relation schema R = {A1, A2,, An} is to be decomposed into a set D of relation schemas, D = {R1, R2,.., Rm}. The decomposition is said to satisfy the attribute preservation condition if R = {A1, A2,, An} = R1 U R2 U U Rn. Query optimization Query optimization is a function of many relational database management systems in which multiple query plans for satisfying a query are examined and a good query plan is identified. Cost based query optimizers evaluate the resource footprint of various query plans and use this as the basis for plan selection. Typically the resources which are costed are CPU path length, amount of disk buffer space, disk storage service time, and interconnect usage between units of parallelism. The set of query plans examined is formed by examining possible access paths (e.g., primary index access, secondary index access, full file scan) and various relational table join techniques (e.g., merge join, hash join, product join). There are two types of optimization. 1. Logical optimization - This type consists of logical optimization which generates a sequence of relational algebra to solve the query. 2. Physical optimization Physical optimization is used to determine the optimized query by carrying out each operation. Distributed Database System A distributed database system is a collection of sites, connected together through some kind of communication network, in which i. Each site is a full database system in its own right, but ii. The sites have agreed to work together so that a user at any site can access data anywhere in the network exactly as if the data were all stored at the user s own site. Distributed database is a kind of virtual database, whose component parts are physically stored in a number of distinct real databases at a number of distinct sites. The distributed databases can be classified as homogenous or heterogeneous. In a homogenous distributed database, all sites have identical database management software, are aware of one another, and agree to co-operate in processing user s requests. In a heterogeneous database, different sites use different schemas and different database management system software. The sites may not be aware of one another and they may provide only limited facilities for co-operation in transaction processing. Advantages of distributed system 1. Sharing Users at a given site are able to access data stored at other sites at the same time retain control over the data at their own site. 2. Availability and reliability Even when a portion of system i.e. local site is down, the system remains available. With replicated data, the failure of one site still allows access to the replicated copy of the data from another site. The remaining sites continue to function. The greater accessibility enhances the reliability of the system. 3. Incremental growth As the organization grows, new sites can be added with little or no upheaval. 4. Parallel evaluation A query involving data from several sites can be subdivided into subqueries and the parts evaluated in parallel. 5. Improved performance A distributed DBMS fragments the database by keeping the data closer the where it is needed most. Data localization reduces the contention for CPU and I/O services and simultaneously reduces access delays involved in wide area networks. When a large database is distributed over multiple sites, smaller databases exist at each site. As a result, local queries and transactions accessing data at a single site have better performance because of the smaller local databases. Disadvantages of distributed databases Disadvantages of distributed databases are its cost and complexity. Methods to store data in distributed database systems There are two approaches to store data in distributed database systems: Page 8 of 11

9 1. Replication The systems maintains several identical replicas (copies) of the relation and stores each replica at different site. The most extreme case is replication of the whole database at every site in the distributed system, thus creating a fully replicated distributed database. 2. Fragmentation The system partitions the relation into several fragments and stores fragments at a different site. Advantages of data replication There are following advantages of replication : 1. Availability Of one of the sites containing relation R fails, then the relation R can be found in another site. Thus, the system can continue to process queries involving R, despite the failure of one site. 2. Increased parallelism If the majority of accesses to the relation R result in only reading of the relation, then several sites can process queries involving R in parallel. The more replicas of R, the greater the chance that the needed data will be found in the site where the transaction in executing. Hence, data replication minimizes movement of data between sites. Disadvantages of data replication 1. The full replication can slow down update operations drastically, since a single logical update must be performed on every copy of the database to keep the copies consistent. 2. Full replication makes the concurrency control and recovery techniques more expensive than if there were no replication. Data fragmentation Efficiency may increase from a strategy that implements a partitioned database. Data fragmentation applies to relational database systems. It refers to ways in which relations can be subdivided and distributed among network sites. There are basically three approaches for data fragmentation: 1. Horizontal fragmentation 2. Vertical fragmentation 3. Mixed fragmentation Comparison between distributed database and client server database In a distributed database, the data is stored at several geographical dispersed sites connected together through a communication network. Each site can request data at other sites. In contrast, in a client-server database, the data is stored at a centralized system called server that satisfies requests generated by client systems. Database integrity Database integrity ensures that data entered into the database is accurate, valid, and consistent. Any applicable integrity constraints and data validation rules must be satisfied before permitting a change to the database. OR Data integrity is a fundamental component of information security. In its broadest use, data integrity refers to the accuracy and consistency of data stored in a database, data warehouse, data mart or other construct. The term Data Integrity can be used to describe a state, a process or a function and is often used as a proxy for data quality. Integrity constraints Integrity constraints are used to ensure accuracy and consistency of data in a relational database. There are following integrity constraints: 1. Entity integrity - The entity integrity constraint states that no primary key value can be null. This is because the primary key value is used to identify individual tuples in a relation. Having null value for the primary key implies that we cannot identify some tuples. This also specifies that there may not be any duplicate entries in primary key column key row. 2. Referential Integrity - The referential integrity constraint is specified between two relations and is used to maintain the consistency among tuples in the two relations. Informally, the referential integrity constraint states that a tuple in one relation that refers to another relation must refer to an existing tuple in that relation. It is a rule that maintains consistency among the rows of the two relations Page 9 of 11

10 3. Domain Integrity - The domain integrity states that every element from a relation should respect the type and restrictions of its corresponding attribute. A type can have a variable length which needs to be respected. Restrictions could be the range of values that the element can have, the default value if none is provided, and if the element can be NULL. 4. User Defined Integrity - A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business. E.g.: Age>=18 && Age<=60 Concurrent execution Transaction processing systems allow multiple transactions to run simultaneously. This simultaneous execution of transactions is known as concurrent execution or concurrency. There are two advantages of using concurrent execution: 1. Improved throughput and resource utilization 2. Reduced waiting time Transaction processing A transaction is a logical unit of database processing that includes one or more database access operations such as insertion, deletion, modification and retrieval. Basic properties of transactions / ACID properties 1. Atomicity A transactions is an atomic unit of processing. It is either performed in it entirety or not performed at all. 2. Consistency Transactions preserve database consistency. That is, a transaction transforms a consistent state of the database into another consistent state, without necessarily preserving consistency at all intermediate points. 3. Isolation The execution of a transaction should not be interfered with by any other transaction executing concurrently. 4. Durability or Permanency The changes applies to the database by a committed transaction must persist in the database. These changes must not be lost because of any failure. States of transaction 1. Active - This is the initial state. The transaction stay in this state while it is executing. 2. Partially Committed - This is the state after the final statement of the transaction is executed. 3. Failed - After the discovery that normal execution can no longer proceed. 4. Aborted - The state after the transaction has been rolled back and the database has been restored to its state prior to the start of the transaction. 5. Committed - The state after successful completion of the transaction. We cannot abort or rollback a committed transaction. Serializability Serializability of a schedule means equivalence (in the resulting database values) to some serial schedule with the same transactions (i.e., in which transactions are sequential with no overlap in time, and thus completely isolated from each other: No concurrent access by any two transactions to the same data is possible). Serializability is considered the highest level of isolation among database transactions, and the major correctness criterion for concurrent transactions. Concurrency control Concurrency control ensures that correct results for concurrent operations are generated, while getting those results as quickly as possible. Concurrency control comprises the underlying mechanisms in a DBMS which handle isolation and guarantee related correctness. It is heavily utilized by the Database and Storage engines both to guarantee the correct execution of concurrent transactions, and (different Page 10 of 11

11 mechanisms) the correctness of other DBMS processes. The transaction-related mechanisms typically constrain the database data access operations' timing (transaction schedules) to certain orders characterized as the Serializability and Recoverabiliry schedule properties. Constraining database access operation execution typically means reduced performance (rates of execution), and thus concurrency control mechanisms are typically designed to provide the best performance possible under the constraints. Often, when possible without harming correctness, the serializability property is compromised for better performance. However, recoverability cannot be compromised, since such typically results in a quick database integrity violation. Locking Locking is the most common transaction concurrency control method in DBMSs, used to provide both serializability and recoverability for correctness. In order to access a database object a transaction first needs to acquire a lock for this object. Depending on the access operation type (e.g., reading or writing an object) and on the lock type, acquiring the lock may be blocked and postponed, if another transaction is holding a lock for that object. Types of lock 1. Binary Lock - A binary lock can have two states or values: locked and unlocked (or 1 and 0, for simplicity). A distinct lock is associated with each database item X. If the value of the lock on X is 1, item X cannot be accessed by a database operation that requests the item. If the value of the lock on X is 0, the item can be accessed when requested. We refer to the current value (or state) of the lock associated with item X as LOCK(X). 2. Shared/Exclusive (or Read/Write) Locks - To recover from binary lock disadvantage, a different type of lock called a multiplemode lock is used. In this scheme called shared/exclusive or read/write locks there are three locking operations: read_lock(x), write_lock(x), and unlock(x). A lock associated with an item X, LOCK(X), now has three possible states: "read-locked," "writelocked," or "unlocked." A read-locked item is also called share-locked, because other transactions are allowed to read the item, whereas a write-locked item is called exclusive-locked, because a single transaction exclusively holds the lock on the item. Deadlock Transaction is unit of work done. So a database management system will have number of transactions. There may be situations when two or more transactions are put into wait state simultaneously.in this position each would be waiting for the other transaction to get released. E.g. Suppose we have two transactions one and two both executing simultaneously. In transaction numbered one we update student table and then update course table. We have transaction two in which we update course table and then update student table. We know that when a table is updated it is locked and prevented from access from other transactions from updating. So in transaction one student table is updated it is locked and in transaction two course table is updated and it is locked. We have given already that both transactions gets executed simultaneously. So both student table and course table gets locked so each one waits for the other to get released. This is the concept of deadlock in DBMS. Object Oriented Database An object database (also object-oriented database management system) is a database management system in which information is represented in the form of objects as used in object-oriented programming. Object databases are different from relational databases and belongs together to the broader database management system. Most object databases also offer some kind of query language, allowing objects to be found by a more declarative programming approach. It is in the area of object query languages, and the integration of the query and navigational interfaces, that the biggest differences between products are found. An attempt at standardization was made by the ODMG with the Object Query Language, OQL. Access to data can be faster because joins are often not needed (as in a tabular implementation of a relational database). This is because an object can be retrieved directly without a search, by following pointers. Page 11 of 11