случаях разработки программного обеспечения, такой подход оправдан лишь при 
решении простейших задач. Если вы рассчитываете, что ваша база данных должна 
будет поддерживать хоть какую-то степень сложности, немного планирования и 
проектирования, в конечном итоге, несомненно сбережет ваше время.
Проектирование баз данных
Предположим, у вас есть большая коллекция компакт-дисков, и вы хотите создать 
базу данных, чтобы отслеживать ее. Прежде всего, нужно определить, какие данные 
вы собираетесь хранить. Неплохо начать с того, чтобы подумать, а зачем, 
собственно, вам хранить эти данные. В нашем случае мы, скорее всего, хотим 
иметь возможность найти диск по исполнителю, названию и песне. Раз мы хотим 
искать эти пункты, они должны быть включены в базу данных. Помимо того, часто 
полезно просто перечислить пункты, которые нужно отслеживать. Возможен такой 
список: название CD, фирма звукозаписи, название ансамбля, название песни. В 
качестве отправной точки выберем для хранения данных таблицу, представленную 
как таблица 2-1.
Таблица 2-1. База данных CD, состоящая из одной таблицы
Band NameCD TitleRecord LabelSongsStevie WonderTalking BookMotownYou Are the 
Sunshine of My Life, Maybe Your Baby, Superstition, . . .Miles Davis Quintet
Miles SmilesColumbiaOrbits, Circle, . . .Wayne ShorterSpeak No EvilBlue Note
Witch Hunt, Fee-Fi-Fo-FumHerbie HancockHeadhuntersColumbiaChameleon, Watermelon 
Man, . . .Herbie HancockMaiden VoyageBlue NoteMaiden Voyage(Для краткости мы 
опустили большую часть -песен.) На первый взгляд, эта таблица нам подходит, 
поскольку в ней есть все необходимые данные. При более близком рассмотрении, 
однако, мы сталкиваемся с некоторыми проблемами. Возьмем, к примеру, Herbie 
Hancock. Название ансамбля повторяется дважды - для каждого CD. Это повторение 
неприятно по нескольким причинам. Во-первых, при вводе данных нам приходится 
вводить одно и то же несколько раз. Во-вторых, что более важно, при изменении 
каких-либо данных приходится изменять их в нескольких местах. Что если, к 
примеру, в Herbie вкралась орфографическая ошибка? Пришлось бы исправлять 
данные в двух строках. Та же проблема возникнет, если имя Herbie Hancock в 
будущем изменится (а ля Jefferson Airplane или John Cougar). С добавлением к 
нашей коллекции новых дисков Herbie Hancock увеличивается объем работы, 
необходимой для поддержания непротиворечивости данных.
Другая проблема, вызванная наличием в базе данных всего одной таблицы, связана 
с тем, как хранятся названия песен. Мы храним их, как список песен, в одной 
колонке. Мы столкнемся с кучей проблем, если попытаемся разумно использовать 
эти данные. Представьте себе, как мы будем вводить и поддерживать этот список 
песен. А что если мы захотим хранить еще и длительность песен? Или пожелаем 
осуществлять поиск по названию песни? Довольно быстро становится ясно, что 
хранить песни в таком виде нежелательно.
Вот тут начинает играть свою роль проектирование баз данных. Одна из важнейших 
задач проектирования баз данных - устранение из нее избыточности. Для этого 
используется прием, называемый нормализацией. Прежде чем приступить к 
нормализации, обсудим некоторые фундаментальные понятия реляционных баз данных. 
Модель данных -это диаграмма, показывающая конструкцию вашей базы данных. Она 
состоит из трех основных элементов - сущностей, атрибутов и связей. Пока 
остановимся на сущностях и атрибутах, а о связях поговорим позднее.
Сущности в базе данных
Сущность - это важная вещь или объект, сведения о котором нужно сохранить. Не 
все вещи являются сущностями, а только те, данные о которых должны быть 
сохранены. Сведения о сущностях имеют вид атрибутов и/или связей. Если некий 
кандидат на то, чтобы быть сущностью, не имеет атрибутов или связей, в 
действительности он не является сущностью. В модели базы данных сущности 
представляются в виде прямоугольника с заголовком. Заголовок является именем 
сущности.
Атрибуты сущности
Атрибут описывает данные о сущности, которые нужно сохранить. У каждой сущности 
ноль или более атрибутов, описывающих ее, и каждый атрибут описывает в точности 
одну сущность. Каждый экземпляр сущности (строка таблицы) имеет в точности одно 
значение, возможно, равное NULL, для каждого из своих атрибутов. Значение 
атрибута может быть числом, строкой символов, датой, временем или другим 
базовым значением данных. На первом этапе проектирования базы данных, 
логическом моделировании, нас не заботит то, каким образом будут храниться 
данные.
NULL лежит в основе проблемы, связанной с отсутствующей информацией. Он 
специально используется тогда, когда какая-то часть данных отсутствует. 
Рассмотрим, к примеру, ситуацию, когда на CD нет данных о длительности каждой 
песни. У каждой песни есть длительность, но, глядя на коробку, вы не можете 
сказать, какова она. Хранить длительность как О нежелательно, поскольку это 
было бы неверно. Вместо этого вы записываете длительность как NULL. Если вы 
считаете, что можно сохранить ее как 0 и использовать 0 для обозначения 
«неизвестной длины», то можете попасть в одну из тех западней, которые привели 
к проблеме 2000-го года. В старых системах не только год хранится как две цифры,
 но и придается особое значение величине 9-9-99.
В нашем примере база данных ссылается на ряд объектов - CD, название CD, 
название ансамбля, песни и название фирмы звукозаписи. Какие из них являются 
сущностями, а какие - атрибутами?
Модель данных
Обратите внимание, что мы определяем несколько видов данных (название CD, 
название ансамбля и т. д.), относящихся к каждому CD, и без которых описать CD