11.1 Introduction to Normalization

	Normalisation is an approach in database design which analyzes database tables in order to get a concise and organized database structure.
	A table is normalized if:

		It doesn’t contain redundancy.
		It doesn’t cause maintenance problems.
		It accurately represents the data required.

	One way to design a database is to have one big table that holds all the data required. However, this has several problems.
	For example, consider a library database that holds information on members and their departments in one table as shown in Figure 11.1.

Although no join operations would be required to get the location of the department that a member belongs to, there are many problems associated with this design including:

			When a member moves from one department to another, rather than just updating the Dept_No attribute value, the Dept_Name and Dept_location attribute values have also to be updated.
			If the name of a department is changed, all member rows belonging to this department have to be updated.

11.1 Introduction to Normalization

			If a department has no members, a row has to be added to the table that contains NULL value for the member attributes Member_Id, Member_fname and Member_lname.
			A related problem occurs when member rows are deleted, how do we know that the last record associated with a department is about to be deleted.

	Database table normalization is based on normal forms that provide restrictions on what attributes that can be included in the same table.
	Using normal form normalization in database design is guaranteed to avoid various problems such as the ones described above.

11.1 Introduction to Normalization

11.1.1 Attribute Dependency

	To understand the process of normalization using normal forms, the concept of dependency between attributes within a table need to be introduced.
	Different types of attribute dependency could exist between attributes of the same table including:

Functional dependency:

			If A and B are attributes of table T, B is functionally dependent on A if each value of A is associated with exactly one value of B in T.
			B must be a fact about A. Functional dependency between attributes is denoted by A → B.
			For example, in the Library table shown in Figure 11.1, attribute Member_fname is functionally dependent on attribute Member_Id as each value of Member_Id is associated with exactly one value of Member_fname.
			Thus, Member_Id → Member_fname.

Identification Key:

Attribute A is a primary key if every attribute in the table is functionally dependent on A.

11.1 Introduction to Normalization

Full Functional Dependency:

			This type of dependency is relevant when the table has a composite primary key, i.e. a primary key with multiple attributes.
			If A represents a composite primary key of table T and B is a non-key attribute in T, B is fully functionally dependent on A if it is functionally dependent on all attributes of A.

Transitive Dependency:

			If attribute B depends on A (A → B) and attribute C depends on B (B → C), then attribute C depends on A (A → C).
			Note that if the transitive dependency to be valid, B must not depend on A, i.e. B → A must be false