Нормализация данных

Теперь займемся проектированием эффективной структуры данных. Теория реляционной базы данных была разработана в начале 70-х годов прошлого ве­ка Коддом (E. F. Codd) на основе математической теории отношений. В реля-

ционной базе данных все данные хранятся в виде таблиц, при этом все опера­ции над базой данных сводятся к манипуляциям таблицами. Основными поня­тиями в этой теории являются: таблица, строка, столбец, индекс, первичный и внешний ключи, связи. Таблица состоит из строк и столбцов и имеет уникаль­ное имя в базе данных. База данных содержит множество таблиц, связь между которыми устанавливается с помощью совпадающих полей. В каждой из таб­лиц содержится информация о каких-либо объектах одного типа.

Приступая к созданию нового приложения, главное — самым тщательным обра­зом спроектировать структуру его таблиц. Если не уделить структуре должного внимания, то в лучшем случае это может проявиться в неэффективной работе приложения, а в худшем — в невозможности реализации некоторых требований к системе в целом. И, наоборот, при хорошей организации набора таблиц будут решены не только текущие проблемы, но и потенциальные, которые в данный момент вы не могли предвидеть. В общем, структура данных является опреде­ляющим фактором успеха или провала всего приложения.

Э. Ф. Кодд доказал, что, следуя при создании таблиц и связей между ними только немногим формализованным правилам, можно обеспечить простоту манипулирования данными. Его методика получила наименование нормали­зации данных. Теория реляционных баз данных основана на концепции ис­пользования ключевых полей для определения отношений между таблицами. Чем больше таблиц, тем больше отношений требуется определить, чтобы связать их между собой. Из теории Кодда отнюдь не следует, что каждая таб­лица должна быть напрямую связана с любой другой таблицей. Но, посколь­ку каждая таблица связана хотя бы с одной таблицей в базе данных, можно утверждать, что все таблицы в базе имеют прямые или косвенные отношения друг с другом.

Мы установили, какие поля будут включены в базу данных. Следующий этап состоит в разделении их на таблицы. Конечно же, можно было бы работать с приведенной выше единственной таблицей " Недвижимость", но даже не знающим правил нормализации ясно, что для каждого проживающего в квар­тире не имеет смысла повторять всю информацию о здании, квартире, ответ­ственном квартиросъемщике и лицевом счете, а при переименовании ули­цы — вносить исправления в тысячи записей, содержащих сведения о технических характеристиках квартиры.

Наличие повторяющейся информации приведет к неоправданному увеличе­нию размера базы данных. В результате снизится скорость выполнения за­просов. При многократном вводе повторяющихся данных возрастет вероят­ность ошибки.

Представьте себе ситуацию, связанную с вводом данных о проживающих на Восточном шоссе. Это пять тысяч человек. Вот несколько вариантов адреса: Шоссе Восточное, Восточное шоссе, ш. Восточное, ш-се Восточное. А сколько еще вариантов может появиться у пользователя, работающего с вашей программой. О грамматических ошибках и вариантах с номером дома, запятыми и точками в адресе позволю себе умолчать. Какую информационно-поисковую систему мы получим в результате? Скорее всего, искать можно — найти нельзя! Вашему вниманию — несколько советов по включению полей в таблицы.

П Включайте поля, относящиеся только к предметной области таблицы. Поле, представляющее факт из другой предметной области, должно при­надлежать другой таблице. Позже, при установлении отношений между таблицами, вы увидите, как можно объединить данные нескольких полей из разных таблиц. А на этом этапе убедитесь, что каждое поле таблицы описывает только одну предметную область. Если вы обнаружите, что в разных таблицах встречается однотипная информация, значит, какие-то таблицы содержат лишние поля.

П Не включайте производные или вычисляемые данные. В большинстве слу­чаев вам нет необходимости хранить результаты вычислений в таблице. С помощью Microsoft Access вы всегда сможете выполнить данные вычис­ления в нужный момент. Не имеет смысла хранить итоговые поля в таблице.

П Включите всю необходимую информацию. Довольно легко упустить важные данные. Вернитесь к собранным на первой стадии проектирова­ния материалам. Внимательно рассмотрите бланки и отчеты и убедитесь в том, что вся интересующая вас информация может быть извлечена или вычислена из таблиц. Подумайте о вопросах, которые вы будете форму­лировать к базе данных. Сможете ли вы получить на них ответ, используя данные из ваших таблиц? Включили ли вы поля, в которых будут хра­ниться уникальные данные типа кода клиента? Какие таблицы содержат информацию, обязательную для создания отчета или формы?

П Разделите информацию на наименьшие логические единицы. Вам может показаться, что удобно иметь одно поле для хранения полного имени клиента или одно поле для названия и описания продукта. Это ошибка. Если вы объединяете более одной категории информации в одном поле, потом вам будет очень не просто выделить из него отдельные факты. По­старайтесь разбить информацию на наименьшие логические части.

Воспользуемся практическими рекомендациями теории нормализации для разработки на основании таблицы " Недвижимость" многотабличной базы

данных Real Estate. На рис. 1.1 вы видите то, что у вас должно получиться после всех манипуляций, кратко изложенных выше и предусмотренных тео­рией нормализации. Практический же путь к этому результату смотрите на следующих полутора десятках страниц.