![]() Lets take a look at some issues involved in this design:įirst, this table is subject to several anomalies: we cannot list publishers or authors without having a book because the ISBN is a primary key which cannot be NULL (referred to as an insertion anomaly). Lets take a look at a typical approachīeginning MySQL Database Design and OptimizationĬhad Russell is a programmer and network administrator who owns his own Internet hosting company., Jon Stephens is a member of the MySQL AB documentation team. Because this book has two authors, we are going to need to accommodate both in our table. Let's start by adding the book that coined the term “Spreadsheet Syndrome”. You would need to track certain information about the books available to your site viewers, such as: Let's say you were looking to start an online bookstore. Note: This article has been updated from an original version published in 2003. Additional resources that look at the theory of database normalization and the additional normal forms can be found in the Resources section at the end of this article. This article will take a practical look at database normalization, focusing on the first three of seven generally recognized normal forms. While normalization is not the be-all and end-all of good design, a normalized schema provides a good starting point for further development. The goal of database normalization is to ensure that every non-key column in every table is directly dependent on the key, the whole key and nothing but the key and with this goal come benefits in the form of reduced redundancies, fewer anomalies, and improved efficiencies. ![]() The concept of database normalization was first introduced by Edgar Frank Codd in his paper A Relational Model of Data for Large Shared Data Banks, section 4. The cure for “Spreadsheet Syndrome” is database normalization.ĭatabase normalization is a process by which an existing schema is modified to bring its component tables into compliance with a series of progressive normal forms. The most challenging of these to maintain and rework suffer from what one author described as the “Spreadsheet Syndrome”: a tendency for the developer to lump every possible piece of information into as few table as possible, often into a single table.Ī schema that suffers from the “Spreadsheet Syndrome” is subject to data redundancies, data anomalies, and various inefficiencies. Over the years I, like many of you, have had the experience of taking over responsibility for an existing application and its associated schema (sometimes frustratingly woven together as part of a Microsoft Access solution).
0 Comments
Leave a Reply. |