это тесно связанное с отношениями понятие, которое означает устранение противоречий и повышение эффективности базы данных.
Базы данных считаются противоречивыми, если данные одной таблицы не соответствуют данным другой. Например, если ряд ваших сотрудников считают, что Арканзас находится на западе, а остальные — что на юге, при этом те и другие выполняют ввод данных, опираясь только на свои знания, то отчеты о состоянии дел на западе будут недостоверными.
Неэффективная база, данных, как правило, не позволяет выделять именно те данные, которые вам требуются. Если база данных хранит всю информацию в одной таблице, вы можете просто потерять самообладание, пока найдете в ней нужный телефонный номер. С другой стороны, полностью нормализованная база данных хранит каждую частицу информации в отдельной таблице и уникальным образом идентифицирует ее собственным первичным ключом. Нормализованные базы данных позволяют ссылаться на любую частицу информации в любой таблице, используя первичный ключ.
При проектировании и инициализации базы данных нужно решить, как ее нормализовать. Обычно все, что связано с приложением базы данных (от структуры таблиц до структуры запросов, от пользовательского интерфейса до поведения отчетов), вытекает из характера нормализации вашей базы данных.
Как разработчику баз данных, вам еще придется столкнуться с базами данных, которые не нормализованы по той или иной причине. Недостаток нормализации может намеренным (например, для достижения более высокой производительности) или оказаться результатом неопытности либо небрежности разработчика базы данных. В любом случае, если вы собираетесь нормализовать существующую базу данных, вам нужно сделать это как можно раньше (поскольку все остальное в разработке базы данных зависит от структуры ее таблиц). Кроме того, для приведения в порядок базы данных с недостаточно продуманной структурой можно использовать команды языка определения данных. Они позволяют переносить Данные из одной таблицы в другую, а также добавлять, обновлять и удалять из таблиц записи, отвечающие заданному критерию.
В качестве примера выбора варианта нормализации можно создать проект базы данных и рассмотреть требование, выдвинутое Брэдом Джонсом в бизнес-ситуации 1.2. Ему требуется способ хранения названия штата, в котором проживает клиент, а также информации о регионе страны, к которому относится этот штат. Начинающий разработчик может создать одно поле для хранения названия штата, а второе — для названия региона страны.
| tblCustomer |
|---|
| ID |
| FirstName |
| LastName |
| Address |
| Company |
| City |
| State |
| PostalCode |
| Phone |
| Fax |
| Region |
Эта структура первоначально может показаться рациональной, однако посмотрим, что произойдет, если кто-нибудь постарается ввести данные в приложение, основанное на этой таблице.
Если бы вы вводили обычную информацию о клиенте - имя, адрес и т.д., то после ввода названия штата вам бы пришлось задуматься, чтобы определить регион проживания данного клиента. Где же находится этот Арканзас – на западе или на юге? Где находится клиент с Виргинских островов? Если существует большая вероятность ошибки, то такого рода решения не стоит оставлять в руках операторов, занимающихся вводом данных, даже несмотря на их высокую квалификацию. Если же полагаться только на человеческую память, то рано или поздно ваши данные станут противоречивыми. А чтобы защитить данные от противоречивости, и следует обращаться к нормализации.