PHP mysql Database normalizatin
Download as PPT, PDF0 likes593 views
The document discusses database normalization. It begins by explaining the first normal form (1NF), which requires data to be atomic and for each row to have a unique primary key. An example employee database is provided, and steps are taken to transform it into 1NF by creating individual rows for each employee. The document then covers the second normal form (2NF), which requires the database to be in 1NF and for non-key attributes to depend on the whole primary key. To achieve 2NF, repeating groups like city and state are extracted into separate tables. Finally, the third normal form (3NF) is discussed, requiring attributes to depend transitively on the primary key. An order database is used as an example, and
PHP mysql Database normalizatin
- 3. What is NormalizationWhat is Normalization Normalization allows us to organize data so that it: • Allows faster access (dependencies make sense) • Reduced space (less redundancy)
- 4. Normal FormsNormal Forms Normalization is done through changing or transforming data into various Normal Forms. There are 5 Normal Forms but we almost never use 4NF or 5NF. We will only be concerned with 1NF, 2NF, and 3NF.
- 5. For a database to be in a normal form, it must meet all requirements of the previous forms: • Eg. For a database to be in 2NF, it must already be in 1NF. For a database to be in 3NF, it must already be in 1NF and 2NF.
- 6. Sample DataSample Data Manager Employees Fatma Sayed, Tariq Abdulaziz Tafla, Mohammed Ali Sarai, Miriam This data has some problems: • The Employees column is not atomic. A column must be atomic, meaning that it can only hold a single item of data. This column holds more than one employee name.
- 7. Manager Employees Fatma Sayed, Tariq Abdulkaziz Tafla, Mohammed Ali Sarai, Miriam Data that is not atomic means: • We can’t easily sort the data • We can’t easily search or index the data • We can’t easily change the data • We can’t easily reference the data in other tables
- 8. Manager Employee1 Employee2 Fatma Sayed Tariq Abdulaziz Tafla Mohammed Ali Sarai Miriam Breaking the Employee column into more than 1 column doesn’t solve our problems: • The data may look atomic, but only because we have many identical columns storing a single piece of data instead of a single column storing many pieces of data.
- 9. • We still can’t easily sort, search, or index our employees. • What if a manager has more than 2 employees, 10 employees, 100 employees? We’d need to add columns to our database just for these cases. • It is still hard to reference our employees in other tables.
- 10. Manager Employee1 Employee2 Fatma Sayed Tariq Abdulaziz Tafla Mohammed Ali Sarai Miriam By the way, what would be a good choice of a Primary Key for this table?
- 11. First Normal FormFirst Normal Form 1NF means that we must: • Eliminate duplicate columns from the same table, and Let’s get started by making our columns atomic…
- 12. Atomic DataAtomic Data By breaking each tuple of our table into an entry for each employee, we have made our data atomic. What would be the primary key? Manager Employee Fatma Sayed Fatma Tariq Abdulaziz Tafla Abdulaziz Mohammed Ali Sarai Ali Miriam
- 13. Primary KeyPrimary Key The best primary key would be the Employee column. Every employee only has one manager, therefore an employee is unique. Employee Manager Sayed Fatma Tariq Fatma Tafla Abdulaziz Mohammed Abdulaziz Sarai Ali Miriam Ali
- 14. First Normal FormFirst Normal Form Congratulations! The fact that all our data and columns is atomic and we have a primary key means that we are in 1NF! Employee Manager Sayed Fatma Tariq Fatma Tafla Abdulaziz Mohammed Abdulaziz Sarai Ali Miriam Ali
- 15. First Normal Form RevisedFirst Normal Form Revised Of course there may come a day when we hire a second employee or manager with the same name. To avoid this, let’s use an employee ID instead of their name. ID Employee ManagerID 1 Sayed 7 2 Tariq 7 3 Tafla 8 4 Mohammed 8 5 Sarai 9 6 Miriam 9 7 Fatma 8 Abdulaziz 9 Ali
- 16. 1NF: Before and After1NF: Before and After ID Employee ManagerID 1 Sayed 7 2 Tariq 7 3 Tafla 8 4 Mohammed 8 5 Sarai 9 6 Miriam 9 7 Fatma 8 Abdulaziz 9 Ali Manager Employees Fatma Sayed, Tariq Abdulaziz Tafla, Mohammed Ali Sarai, Miriam
- 17. Moving to Second Normal FormMoving to Second Normal Form A database in 2NF must also be in 1NF: • Data must be atomic • Every row (or tuple) must have a unique primary key Plus: • Subsets of data that apply to multiple rows (repeating data) are moved to separate tables
- 18. CustID FirstName LastName Address City State Zip 1 Bob Smith 123 Main St. Tucson AZ 12345 2 John Brown 555 2nd Ave. St. Paul MN 54355 3 Sandy Jessop 4256 James St. Chicago IL 43555 4 Maria Hernandez 4599 Columbia Vancouver BC V5N 1M0 5 Gameil Hintz 569 Summit St. St. Paul MN 54355 6 James Richardson 12 Cameron Bay Regina SK S4T 2V8 7 Shiela Green 12 Michigan Ave. Chicago IL 43555 8 Ian Sampson 56 Manitoba St. Winnipeg MB M5W 9N7 9 Ed Rodgers 15 Athol St. Regina SK S4T 2V9 This data is in 1NF: all fields are atomic and the CustID serves as the primary key
- 19. But let’s pay attention to the City, State, and Zip fields: • There are 2 rows of repeating data: one for Chicago, and one for St. Paul. • Both have the same city, state and zip code City State Zip Tucson AZ 12345 St. Paul MN 54355 Chicago IL 43555 Vancouver BC V5N 1M0 St. Paul MN 54355 Regina SK S4T 2V8 Chicago IL 43555 Winnipeg MB M5W 9N7 Regina SK S4T 2V9
- 20. The CustID determines all the data in the row, but U.S. Zip codes determines the City and State. (eg. A given Zip code can only belong to one city and state so storing Zip codes with a City and State is redundant) This means that City and State are Functionally Dependent on the value in Zip code and not only the primary key.
- 21. To be in 2NF, this repeating data must be in its own table. So: • Let’s create a Zip code table that maps Zip codes to their City and State.
- 22. Our Data in 2NFOur Data in 2NF CustID FirstName LastName Address Zip 1 Bob Smith 123 Main St. 12345 2 John Brown 555 2nd Ave. 54355 3 Sandy Jessop 4256 James St. 43555 4 Maria Hernandez 4599 Columbia V5N 1M0 5 Gameil Hintz 569 Summit St. 54355 6 James Richardson 12 Cameron Bay S4T 2V8 7 Shiela Green 12 Michigan Ave. 43555 8 Ian Sampson 56 Manitoba St. M5W 9N7 9 Ed Rodgers 15 Athol St. S4T 2V9 Zip City State 12345 Tucson AZ 54355 St. Paul MN 43555 Chicago IL V5N 1M0 Vancouver BC S4T 2V8 Regina SK M5W 9N7 Winnipeg MB S4T 2V9 Regina SK •We see that we can actually save 2 rows in the Zip Code table by removing these redundancies: 9 customer records only need 7 Zip code records. •Zip code becomes a foreign key in the customer table linked to the primary key in the Zip code table CustomerTableZipCodeTable
- 23. Advantages of 2NFAdvantages of 2NF Saves space in the database by reducing redundancies If a customer calls, you can just ask them for their Zip code and you’ll know their city and state! (No more spelling mistakes) If a City name changes, we only need to make one change to the database.
- 24. Summary So Far…Summary So Far… 1NF: • All data is atomic • All rows have a unique primary key 2NF: • Data is in 1NF • Subsets of data in multiple columns are moved to a new table • These new tables are related using foreign keys
- 25. Moving to 3NFMoving to 3NF To be in 3NF, a database must be: • In 2NF • All columns must be fully functionally dependent on the primary key (There are no transitive dependencies)
- 26. In this table: • CustomerID and ProdID depend on the OrderID and no other column (good) • Stated another way, “If you know the OrderID, you know the CustID and the ProdID” So: OrderID CustID, ProdID OrderID CustID ProdID Price Quantity Total 1 1001 AB-111 50 1,000 50,000 2 1002 AB-111 60 500 30,000 3 1001 ZA-245 35 100 3,500 4 1003 MB-153 82 25 2,050 5 1004 ZA-245 42 10 420 6 1002 ZA-245 40 50 2,000 7 1001 AB-111 75 100 7,500
- 27. But there are some fields that are not dependent on OrderID: • Total is the simple product of Price*Quantity. As such, has a transitive dependency to Price and Quantity. • Because it is a calculated value, doesn’t need to be included at all. OrderID CustID ProdID Price Quantity Total 1 1001 AB-111 50 1,000 50,000 2 1002 AB-111 60 500 30,000 3 1001 ZA-245 35 100 3,500 4 1003 MB-153 82 25 2,050 5 1004 ZA-245 42 10 420 6 1002 ZA-245 40 50 2,000 7 1001 AB-111 75 100 7,500
- 28. Also, we can see that Price isn’t really dependent on ProdID, or OrderID. Customer 1001 bought AB- 111 for $50 (in order 1) and for $75 (in order 7), while 1002 spent $60 for each item in order 2. OrderID CustID ProdID Price Quantity Total 1 1001 AB-111 50 1,000 50,000 2 1002 AB-111 60 500 30,000 3 1001 ZA-245 35 100 3,500 4 1003 MB-153 82 25 2,050 5 1004 ZA-245 42 10 420 6 1002 ZA-245 40 50 2,000 7 1001 AB-111 75 100 7,500
- 29. Maybe price is dependent on the ProdID and Quantity: The more you buy of a given product the cheaper that product becomes! So we ask the business manager and she tells us that this is the case. OrderID CustID ProdID Price Quantity Total 1 1001 AB-111 50 1,000 50,000 2 1002 AB-111 60 500 30,000 3 1001 ZA-245 35 100 3,500 4 1003 MB-153 82 25 2,050 5 1004 ZA-245 42 10 420 6 1002 ZA-245 40 50 2,000 7 1001 AB-111 75 100 7,500
- 30. We say that Price has a transitive dependency on ProdID and Quantity. • This means that Price isn’t just determined by the OrderID. It is also determined by the size (or quantity) of the order (and of course what is ordered). OrderID CustID ProdID Price Quantity Total 1 1001 AB-111 50 1,000 50,000 2 1002 AB-111 60 500 30,000 3 1001 ZA-245 35 100 3,500 4 1003 MB-153 82 25 2,050 5 1004 ZA-245 42 10 420 6 1002 ZA-245 40 50 2,000 7 1001 AB-111 75 100 7,500
- 31. Let’s diagram the dependencies. We can see that all fields are dependent on OrderID, the Primary Key (white lines) OrderID CustID ProdID Price Quantity Total
- 32. But Total is also determined by Price and Quantity (yellow lines) • This is a derived field (Price x Quantity = Total) • We can save a lot of space by getting rid of it altogether and just calculating total when we need it OrderID CustID ProdID Price Quantity Total
- 33. Price is also determined by both ProdID and Quantity rather than the primary key (red lines). This is called a transitive dependency. We must get rid of transitive dependencies to have 3NF. OrderID CustID ProdID Price Quantity
- 34. We do this by moving the transitive dependency into a second table… OrderID CustID ProdID Price Quantity
- 35. By splitting out the table, we can quickly adjust our price table to meet our competitor, or if the prices changes from our suppliers. OrderID CustID ProdID Quantity ProdID PriceQuantity
- 36. The second table is our pricing list. Think of Quantity as a range: • AB-111: 1-100, 101-500, 501 and more ZA-245: 1-10, 11-50, 51 and more The primary Key for this second table is a composite of ProdID and Quantity. OrderID CustID ProdID Quantity ProdID Quantity Price 1 1001 AB-111 1,000 AB-111 1 75 2 1002 AB-111 500 AB-111 101 60 3 1001 ZA-245 100 AB-111 501 50 4 1003 MB-153 25 ZA-245 1 42 5 1004 ZA-245 10 ZA-245 11 40 6 1002 ZA-245 50 ZA-245 51 35 7 1001 AB-111 100 MB-153 1 82
- 37. Congratulations! We’re now in 3NF! We can also quickly figure out what price to offer our customers for any quantity they want. OrderID CustID ProdID Quantity ProdID Quantity Price 1 1001 AB-111 1,000 AB-111 1 75 2 1002 AB-111 500 AB-111 101 60 3 1001 ZA-245 100 AB-111 501 50 4 1003 MB-153 25 ZA-245 1 42 5 1004 ZA-245 10 ZA-245 11 40 6 1002 ZA-245 50 ZA-245 51 35 7 1001 AB-111 100 MB-153 1 82
- 38. To Summarize (again)To Summarize (again) A database is in 3NF if: • It is in 2NF • It has no transitive dependencies A transitive dependency exists when one attribute (or field) is determined by another non-key attribute (or field) We remove fields with a transitive dependency to a new table and link them by a foreign key.
- 39. SummarizingSummarizing A database is in 2NF if: • It is in 1NF • There is no repeating data in its tables. Put another way, if we use a composite primary key, then all attributes are dependent on all parts of the key.
- 40. And Finally…And Finally… A database is in 1NF if: • All its attributes are atomic (meaning they contain only a single unit or type of data), and • All rows have a unique primary key.
Editor's Notes
- #11: Students would be expected to answer “Manager” since each manager is only listed once, and the employees are scattered across multiple columns. Also, an employee may change managers fairly frequently (but once a person is a manager, they are likely to remain managers).
- #12: Objective: to remove a table’s repeating groups and ensure that all entries of the resulting table have at most a single value.
- #13: Students should now say that the Employee is the Primary Key since there are now multiple manager values in the table. Only Employee is unique.
- #14: Students should now say that the Employee is the Primary Key since there are now multiple manager values in the table. Only Employee is unique.
- #15: Students should now say that the Employee is the Primary Key since there are now multiple manager values in the table. Only Employee is unique.
- #16: Students should now say that the Employee is the Primary Key since there are now multiple manager values in the table. Only Employee is unique.
- #19: Students should now say that the Employee is the Primary Key since there are now multiple manager values in the table. Only Employee is unique.
- #34: Every non-key column is independent of every other non-key column. Eliminates fields that can be derived from other fields! (student marks total) {Book} → {Author} {Author} does not → {Book} {Author} → {Author Nationality} Therefore {Book} → {Author Nationality} is a transitive dependency.