Normalization

1 1 NF 2 2 NF
1.1 No repeating groups 1.2 Book (ISBN, Book_Title, Author) is not in 1 NF as we can have multiple authors for a given entity (a book) 2.1 All non key attributes are fully dependent on the key 2.2 Thus, 2.2.1 if value of a non key attribute depends only on part of the key, i.e. independent of some of the attributes that form the key, then it fails in 2 NF 2.2.2 practically relevant to composite keys only 2.3 Book (Book#, ISBN, Book_Title) is not in 2 NF as Book_Title depends only on ISBN (with book# uniquely identifying every physical book) 3.1 No transitive dependencies for any non key attribute 3.2 Thus, 3.2.1 a non key attribute should be directly dependent on the key, rather than or via another non key attribute which in turn is directly dependent on the key 3.2.2 in other words, no non key attribute should determine another non key attribute 3.3 Typically, transaction tables fail in 3 NF 3.4 Borrowing (Borrowing#, Book#, Member#, Borrowed_Date, Return_By_Date) is not in 3 NF as a formula on Borrow_Date might determine Return_By_Date

3 3 NF

4 BCNF

5 4 NF

4.1 Every determinant must be a candidate key 4.2 Thus, 4.2.1 a determinant that determines only one or few but not all other attributes of the entity, is not a candidate (i.e. alternate) key 4.2.2 if there is a transitive dependency then we have a determinant that determines some specific attribute(s) - so what fails to meet 3 NF fails for BCNF also 4.2.3 a determinant that determines part of attribute(s) of the key though none of non-key attributes, satisfies 3 NF but fails to meet BCNF 4.2.4 practically relevant to composite keys only 4.3 Borrowing (Book#, Member#, Borrowed_Date, Return_By_Date) is not in BCNF as there may be a formula by which Return_By_Date determines Borrow_Date 4.3.1 possibility of a reverse formula having Borrowed_Date determining Return_By_Date would make it fail in 2 NF 5.1 No multi-valued dependency (MVD) 5.2 Thus, 5.2.1 when a key multi-determines a non-key attribute (following a business requirement), for any value of the key, a list of values for the non key attribute will follow 5.2.2 if we keep it as-is, the structure fails to meet 1 NF 5.2.3 if we flatten out the data, creating an individual row for each combination of value of the key and its multi-determined attribute, then, 5.2.3.1 an attempt to create a single new entity into the table can result in multiple rows, i.e. causing redundancy for other attributes 5.2.3.2 this redundancy is the symptom of failure to meet 4 NF 5.3 Book (ISBN, Book_Title, Author) is not in 4 NF because an attempt to create a new logical entity i.e. a new book, requires multiple physical rows in the table as whenever have multiple authors; this results in redundancy for the Book_Title attribute 6.1 No non key-preserved join dependency (JD). 6.2 Thus, 6.2.1 a table R is in 5 NF if every JD is implied by its candidate keys; to verify 6.2.1.1 find all its JD 's 6.2.1.2 find all its candidate keys 6.2.1.3 every projection in any JD has one or more candidate keys that are also candidate key for R 6.2.2 Projections from an unqualified JD, upon joining, will cause a constrained MVD, i.e. number of multi-determined values will vary 6.3 Thus, a non-key preserved JD is the source of an MVD of varying number of multi-determined rows and an FD is an MVD determining a single value

6 5 NF