Module Coordinator Tan Szu Tak School of Information and Communication Technology, Politeknik Brunei Semester

2  Entity Relationship Entity Relationship  Degrees of Data Abstraction Degrees of Data Abstraction  Normalization Normalization  Data Redundancy Data Redundancy  Data Dependencies Data Dependencies  Level of Normalization Level of Normalization  Goal of Normalization Goal of Normalization *Words with underline can be clicked on

3  Update Anomalies Update Anomalies  How Normalization Supports DB Design How Normalization Supports DB Design  Un-normalized Form (UNF) Un-normalized Form (UNF)  First Normal Form (1NF) First Normal Form (1NF)  Second Normal Form (2NF) Second Normal Form (2NF)  Third Normal Form (3NF) Third Normal Form (3NF)  Flow for Normalization Flow for Normalization *Words with underline can be clicked on

Before creating and using database what should we do? We learn more about entity, attributes, relationships and cardinality ratios such as:  What are they?  How to indentify them?  How are they drawn in Chen models? 4

Under cardinality ratios:  1:1  1:M / M:1  M:N (Correction NOT M:M) Different ways to draw a ERD – Chen Model How to improve the ERD? 1. Remove Redundant Relationship 2. Separate M:N into 2 1:M relationship 5

Existence dependence  Entity’s existence depends on existence of related entities  Existence-independent entities can exist apart from related entities. Weak (non-identifying)  Existence-independent  PK of related entity doesn’t contain PK component of parent entity. 6

Strong (Identifying)  Existence dependent  PK of related entity contains PK component of parent entity Optional  Entity occurrence does not require a corresponding occurrence in related entity.  E.g. Lecturer teach many modules but not all lecturer are teaching. 7

Primary/Foreign Key Attribute Multivalued attribute – Attributes with multiple values. E.g. A person may have several degrees. Derived attribute – Values that can be derived with an algorithm. E.g. Age can be derived from date of birth. Cardinality Ratios (Optional) 8

A weak entity can be drawn as: A optional relationship can be shown using a small circle. Cardinality ratio can be shown in brackets. E.g. (1,N) 9

A key attribute can be drawn with it entity underlined. If it is a primary, the entity should be in Bold. A Derived attribute is drawn with dotted oval. A Multivalued attribute is drawn with double line oval. 10

11

Normalization is a process of converting a complex data structure into several simpler, stable data structures. It is a process for assigning attributes to entities by going through a series of levels, refining the design each time. Normalization minimizes or reduce data dependency and thus helps to eliminate the anomalies that result from those redundancies. 12

Data redundancy occurs in database systems which have it attribute values repeated in two or more rows. Redundant data can be determined from other data in the data. It can leads to various problems:  INSERT anomalies  UPDATE anomalies  DELETE anomalies 13

Data dependencies, aka Functional dependencies occurs in a database when information stored in the same table uniquely determines other information stored in the same table. E.g. M_Code, M_Name It can also be describe as a relationship where knowing the value of one attribute (or a set of attributes) is enough to tell you the value of another attribute (or set of attributes) in the same table. 14

If there is a dependency in a database such that attribute/s B is dependent upon attribute/s A, it can be written as “A -> B” (A functionally determines B) Example A EMP table contains the attribute ID and name. It can be said that name is dependent upon ID (ID -> name) as the name can be uniquely determined from their ID. However the reverse is not true as one EMP can have same name but different ID. 15

Database dependencies are important to understand because they provide the basic building blocks used in database normalization. There few other types of dependencies namely:  Trivial Functional Dependencies  Full Functional Dependencies  Transitive Dependencies  Multivalued Dependencies 16

 Trivial Functional Dependencies ◦ Occurs when a functional dependency of an attribute on a collection of attributes that includes the original attribute. E.g. “{A,B} -> B” “{name, ID} -> ID” ◦ It is called trivial because it can be derived from common sense. 17

 Full Functional Dependencies ◦ Occur when the requirements for a functional dependency are meet and the set of attributes on the left side of the functional dependency statement cannot be reduced any farther. Example: “{ID, age} -> name” It is a (partial) functional dependency but it is not a full functional dependency because “age” can be remove from the left side of the statement without impacting the dependency relationship. 18

 Transitive dependencies ◦ Occur when there is an indirect relationship that causes a functional dependency. ◦ Given “A -> C” is a transitive dependency only if both “A -> B” and “B -> C” are true. Example: {Book} -> {Author} {Author} does not -> {Book} {Author} -> {Author Nationality} Therefore {Book} -> {Author Nationality} 19

 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. Example: A car company manufactures many car models and always make both red and blue colors for each model. 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. 20

There are many levels of normalization (Normal Form): 1NF, 2NF, 3NF, BCNF, 4NF and 5NF Each level reduces more redundancy BUT each level also makes DB operations slower The typical stopping point is the 3 rd (3NF) 21

Normalization aim to reduce data redundancy and storage. Redundancy is expressed in terms of dependencies. Therefore each level of normalization reduces the dependencies. A table represents only a single object and its attributes. Data should be kept in one table where possible to eliminate update anomalies to ensuring integrity and consistency. All data in row must depend on the primary key and nothing else to ensure PKs uniquely identify rows. 22

There are three anomalies:  Insertion Anomalies (INSERT) ◦ A record about an entity cannot be inserted into the table without first inserting information about another entity. E.g. Cannot enter a customer without a sales order. 23

 Deletion Anomalies (DELETE) ◦ A record cannot be deleted without deleting a record about a related entity. E.g. Cannot delete a sales order without deleting all of the customer’s information.  Modification Anomalies (UPDATE) ◦ Cannot update information without changing information in many places. E.g. To update customer information, it must be updated for each sales order the customer has placed. 24

25

Un-normalized form is a preparatory stage of the normalization process allowing us to create a structured frame, representative of a piece of organizational data such as a form or document. Un-normalized relation is just a big jumble of data but this preparatory stage is important as each stage of the normalization process is dependent upon the previous. Therefore as a starting stage, setting up with the right domains and data ensure a smooth transition between the stages. 26

Relations can only be in 1NF if each row and column intersection (cell) contains a single atomic value. This means that table entries should be single values, not sets or composite objects A primary key will be determined at this initial stage of normalization also. It may be necessary that the primary key is made up of more than one attribute. (Composite key) 27

For relations to be in 2NF, they must first be in 1NF. They must also have NO partial dependencies. A partial dependency occurs when the primary key is made up of more than one attribute and there exists an attribute that can be removed without effecting the dependency relationship. These partially dependent attributes can be removed into another relation along with a copy of the determinant attribute. 28

Getting a relation to 3NF involves removing any transitive dependencies. Therefore, a relation in 3NF must be in 1NF and 2NF and it must have no non-primary key attributes which are transitively dependent upon the primary key. 29

30 TABLE WITH REPEATING GROUPS (UNNORMALISED FORM (UNF)) FIRST NORMAL FORM (1NF) SECOND NORMAL FORM (2NF) THIRD NORMAL FORM (3NF) Remove repeating groups Identify Functional Dependencies Remove Transitive Dependencies

1) Un-normalized Form (UNF)  Begin with a list of all of the fields that must appear in the database. Think of this as one big table.  Do not include computed fields  One place to begin getting this information is from a printed document used by the system.  Additional attributes besides those for entities described on the document can be added to the database. 31

UNF Example 32

Fields in the original data table will be as follow: SalesOrderNo, Date, CusNo, CusName, CusAdd, ClerkNo, ClerkName, ItemNo, Description, Qty, UPrice Think of this as the baseline – one large table 33 SalesOrder No Item No DescQtyUPriceDateCusNoCusNameClerk No Clerk Name

2) First Normal Form (1NF)  Separate Repeating Groups into New Tables.  Repeating Groups are fields that may be repeated several times for on document/entity.  Create a new table containing the repeating data.  The primary key of the new (repeating group) is always a composite key. (Usually document number and a field uniquely describing the repeating line, like an item number) 34

Example: The new table is as follows: (SalesOrderNo, ItemNo, Description, Qty, UPrice) The repeating fields will be removed from the original data table, leaving the following: (SalesOrderNo, Date, CusNo, CusName, CusAdd, ClerkNo, ClerkName) These two tables are a database in 1NF. 35

What if we did not normalize the database to 1NF? Repetition of Data will occur where Sales Order header data will repeat for every line. 36 SalesOrderNoItemNoDescQtyUPrice SalesOrderNoDateCusNoCusNameCusAddClerkNoClerkName

3) Second Normal Form (2NF)  Remove Partial Dependencies.  Create a separate table with the functionally dependent data and the part of the key on which it depends.  Table created at this step will usually contain descriptions of resources. 37

Example: The new table is as follows: (ItemNO, Description) All of these fields except the primary key will be removed from the original table. The primary key will be left in the original table to allow linking of data: (SalesOrderNo, ItemNo, Qty, UPrice) 38

Cont. Example: Never treat price as dependent on item. Price may be different for different sales orders (discounts, special customers, etc.) Along with the unchanged table below: (SalesOrderNo, Date, CusNo, CusName, CusAdd, ClerkNo, ClerkName) These two tables are a database in 2NF. 39

40 SalesOrderNoItemNoDescQtyUPrice SalesOrder No DateCusNoCusNa me Cus Add ClerkNoClerkName

41 SalesOrderNoItemNoQtyUPrice SalesOrder No DateCusNoCusNa me Cus Add ClerkNoClerkName ItemNoDesc

What if we did not normalize the database to 2NF?  Repetition of Data – Description would appear every time we had an order for the item.  Delete Anomalies – All information about inventory items is stored in the SalesOrderDetail table. Delete a sales order would delete the item.  Insert Anomalies – To insert an inventory item. must insert sales order as well.  Update Anomalies – To change the description, must change it on every Sales Order. 42

4) Third Normal Form (3NF)  Remove Transitive Dependencies.  Create a separate table containing the attribute and the fields that are functionally dependent on it.  Tables created at this step will usually contain descriptions of either resources or agents.  Keep a copy of the key attribute in the original file. 43

Example: The new table is as follows: (CustomerNo, CustomerName, CustomerAdd) (ClerkNo, ClerkName) All of these fields except the primary key will be removed from the original table. The primary key will be left in the original table to allow linking of data: (SalesOrderNo, Date, CustomerNo, ClerkNo) 44

45 SalesOrder No DateCusNoCusNa me Cus Add ClerkNoClerkName

46 ClerkNoClerkName SalesOrderNoItemNoQtyUPrice ItemNoDesc CusNoCusNameCusAdd SalesOrderNoDateCusNoClerkNo

What if we did not normalize the database to 3NF?  Repetition of Data – Detail for Cust/Clerk would appear one every Sales Order.  Delete Anomalies – Delete a sales order would delete the customer/clerk.  Insert Anomalies – To insert a customer/clerk, a sales order must be created.  Update Anomalies – To change the name/address, etc, change must be done on every Sales Order. 47

Below are the completed tables in 3NF: Customers: (CustomerNo, CustomerName, CustomerAdd) Clerks: (ClerkNo, ClerkName) Inventory Items: (ItemNo, Description) Sales Orders: (SalesOrderNo, Date, CustomerNo, ClerkNo) SalesOrderDetail: (SalesOrderNo, ItemNo, Qty, UnitPrice) 48

Lecture Slides by Tan Szu Tak, SICT, Politeknik Brunei