Practically Normal: An Introduction to Normalization
0 likes263 views
This document serves as a practical introduction to data normalization, outlining its purpose, benefits, and various normal forms. It defines key concepts such as candidate keys, primary keys, and the first through fifth normal forms, providing examples for clarity. The text emphasizes the importance of normalization in enhancing data integrity and efficiency, while also addressing scenarios when denormalization may be appropriate.
Practically Normal: An Introduction to Normalization
- 1. Practically Normal: A Practical Introduction to Normalization Ed Leighton-Dick
- 2. Who Am I? O 22 years in IT O SQL Server since 2000 (v6.5-2012) O DBA, 2006-present O Chapter Leader, I-380 PASS O MCITP O Husband O Father of two O Runner O Beginning blogger and presenter
- 3. Let me tell you a story…
- 12. How can we help Frank?
- 13. Normalization O The process of organizing data to minimize redundancy O Goals O Produce smaller, well-structured relations O Eliminate modification difficulties O Minimize redesign when extending structure O Make data model more informative to users O Avoid bias toward any particular pattern of querying O Reduce data entry errors caused by redundant data
- 14. First, Identify the Keys O Candidate key: A column or group of columns that uniquely identifies a row O Natural key: A candidate key that consists of a column or columns that already exist in the table O Surrogate key: An otherwise meaningless column created to serve as a candidate key O Primary key: The candidate key chosen as the preferred way of identifying rows
- 17. Normal Form O Criteria for determining a table’s degree of vulnerability to logical inconsistencies and anomalies O Many normal forms exist O Each implies adherence to lower-ranked normal forms
- 18. First Normal Form (1NF) O No repeating groups
- 24. Second Normal Form (2NF) O No non-key field is dependent on part of a key
- 29. Third Normal Form (3NF) O No non-key field is dependent on another non-key field
- 34. Boyce-Codd Normal Form (BCNF) O Stronger version of 3NF O All non-key fields are dependent on a candidate key or a superset of a candidate key (“superkey”)
- 40. 4NF and 5NF O How parts of a key relate to each other O Both require keys with three or more parts
- 41. Fourth Normal Form (4NF) O All multivalued dependencies are related to a candidate key O A -> B and A -> C and B -> C
- 42. 4NF: Example A Restaurant Pizza Variety Delivery Area A1 Pizza Thick Crust Shelbyville A1 Pizza Stuffed Crust Shelbyville A1 Pizza Braided Crust Shelbyville A1 Pizza Buttered Crust Shelbyville A1 Pizza Thick Crust Capital City A1 Pizza Stuffed Crust Capital City A1 Pizza Braided Crust Capital City A1 Pizza Buttered Crust Capital City Adapted from Wikipedia
- 43. 4NF: Example B Restaurant Pizza Variety Delivery Area A1 Pizza Thick Crust Springfield A1 Pizza Thick Crust Capital City A1 Pizza Stuffed Crust Springfield A1 Pizza Stuffed Crust Shelbyville Elite Pizza Thin Crust Capital City Elite Pizza Stuffed Crust Capital City Elite Pizza Stuffed Crust Springfield Vincenzo’s Pizza Thin Crust Springfield Adapted from Wikipedia
- 44. Fifth Normal Form (5NF) O All join dependencies are implied by a candidate key O The combination of A and B does not imply C
- 45. 5NF: Example A Salesman Brand Product Type Jack Acme Vacuum Jack Acme Breadbox Willy Robusto Pruning Shears Willy Robusto Vacuum Willy Robusto Breadbox Louis Nimbus Vacuum Louis Robusto Vacuum Louis Acme Vacuum Adapted from Wikipedia
- 46. 5NF: Example B Salesman Type Jack Vacuum Jack Breadbo x Willy Shears Willy Vacuum Willy Breadbo x Louis Vacuum Salesma n Brand Jack Acme Willy Robusto Louis Acme Louis Robusto Louis Nimbus Brand Type Acme Vacuum Acme Breadbo x Robusto Shears Robusto Vacuum Robusto Breadbo x Nimbus Vacuum Adapted from Wikipedia
- 47. Why normalize? O Manageability O Smaller tables O More informative data model O Easier to add rows than columns O Scalability O Structures are “vertical” not “horizontal” O Number of columns is finite O Minimize redesign O Avoid query bias O Space savings O Less repeated data O Increased data integrity O Less repeated data => More consistent data
- 48. But doesn’t normalization help performance? O Well… sometimes O Does not directly help performance O Helps you work with the database engine in an optimal way O Smaller tables => Fewer I/Os O Avoids procedural code O Can be slower in some cases!
- 49. Denormalization O Process of “undoing” normalization O Good for… O Data warehouses O Frequently-accessed reports O Making database easier for novice users to query against O Always normalize first! O “Normalize until it hurts… Denormalize until it makes sense”
- 50. Questions?
- 51. Resources O Wikipedia http://en.wikipedia.org/wiki/Database_normalization O “A Simple Guide to Five Normal Forms…” http://www.bkent.net/Doc/simple5.htm O Karen Lopez series http://www.dataversity.net/archives/3898
- 52. Thank you! Ed Leighton-Dick Email: [email protected] Twitter: @eleightondick Website: edleightondick.com Please fill out your speaker comment cards!
Editor's Notes
- #5: Once upon a time, a guy named Frank opened a small fruit stand that sold apples.
- #6: This is Frank.
- #7: Frank decides to start keeping track of his fruit sales in a spreadsheet.
- #8: Business is booming, so he begins to diversify his business.
- #9: Frank adds columns to track the new produce.
- #10: Now Frank needs to start tracking his inventory. He adds more columns.
- #11: Business was so good that Frank decided to open a second fruit stand. He adds more columns to track sales and inventory at the second location.
- #12: Frank’s spreadsheet is collecting the information he needs, but it has become difficult to manage. He decides to contact a consultant for help.
- #18: Many more normal forms than what I’m going to show… Most above BCNF deal with less-common cases. I learned six in college; Wikipedia lists 9; I’ve seen lists that show more. New ones are added occasionally to handle additional cases.
- #48: Goals Produce smaller, well-structured relations Eliminate modification difficulties Minimize redesign when extending structure Make data model more informative to users Avoid bias toward any particular pattern of querying Reduce data entry errors caused by redundant data Manageability Tables are smaller Easier to add rows than columns More informative data model - Easier to find columns for querying, modifications Scalability Structures are “vertical” not “horizontal” – Rows can be added indefinitely; columns are finite Minimize redesign when columns need to be added/deleted Avoid bias toward any particular pattern of querying Space savings Less repeated data Increased data integrity Less repeated data => More consistent data
- #50: Final comments: This is not hard stuff… It just takes practice. Anything can be used for practice!
- #53: Add contact info I want feedback!