1 ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ: ОСНОВНЫЕ ПОНЯТИЯ

1.1Основные цели и этапы проектирования баз данных

Вбазе данных (БД) отражается информация об определенной предметной области. Под предметной областью будем понимать часть реального мира, данные о которой должны храниться в проектируемой БД. Предметная область может представлять собой, например, предприятие, отрасль промышленности, торговую фирму, учебное заведение, магазин, библиотеку и т.д. Информация, необходимая для описания предметной области, зависит от типа самой предметной области, а также от того, какую именно информацию об этой предметной области требуется хранить и обрабатывать. Эта информация может включать сведения о предметах, событиях и их характеристиках (например, сведения о работниках предприятия, финансовых сделках, автомобилях, товарах, учебных предметах и т.д.).

Основные цели проектирования баз данных (ПБД) следующие:

−обеспечение хранения в БД всех необходимых данных;

−обеспечение получения данных по всем необходимым запросам;

−сокращение избыточности и дублирования данных;

−обеспечение целостности данных: исключение потери данных, противоречий в содержании БД, нарушений смысла данных;

−сокращение времени доступа к данным и получения данных по запро-

сам.

В процессе проектирования баз данных выделяют три основных этапа.

1.1.1 Концептуальное (инфологическое) проектирование – анализ пред-

метной области и ее описание. Этот этап осуществляется без ориентации на ка- кие-либо конкретные программные или технические средства. Результатом данного этапа является формализованная модель предметной области, построенная с использованием специальных языковых средств (обычно – графических). Инфологическая модель, как правило, включает следующие основные элементы:

−описание объектов предметной области;

−описание атрибутов (свойств) объектов;

−описание связей между объектами.

Пусть, например, проектируется база данных о промышленном предприятии. Объектами предметной области в данном случае могут являться работники предприятия, его подразделения, другие предприятия – поставщики сырья или потребители продукции, заключенные договоры, виды выпускаемой продукции, конкретные выпущенные изделия и т.д. Эти объекты имеют свойства (атрибуты) – фамилия, адрес и профессия работника, стоимость изделия, объем поставок по договору и т.д. Наконец, объекты находятся в различных связях друг с другом: работник работает в некотором подразделении, подразделения выпускают продукцию, продукция поставляется по договорам другим предприятиям и т.д.

4

Для описания объектов предметной области, их атрибутов и связей между ними обычно применяются стандартизированные системы графических обозначений. Чаще всего применяются ER-модели (ER-диаграммы), подробно рассматриваемые в разделе 2, и семантические объектные модели (COM-модели), рассматриваемые в [2].

Кроме того, инфологическая модель может включать:

−описание основных запросов к проектируемой БД;

−описание документооборота, т.е. документов, используемых в качестве источников данных для БД или составляемых на основе БД;

−описание алгоритмических связей между данными (например, алгоритмы и формулы для вычисления каких-либо величин, хранящихся в БД или определяемых на основе БД);

−описание ограничений целостности, т.е. правил, обеспечивающих актуальность и непротиворечивость данных. Ограничения целостности представляют собой требования к допустимым значениям данных и связям между ними.

1.1.2 Даталогическое (логическое) проектирование – описание логиче-

ской структуры данных средствами системы управления базами данных (СУБД), для которой проектируется БД. Такое описание (даталогическая модель) строится на основе инфологической модели по определенным правилам. Для реляционных БД (т.е. БД, где данные представлены в виде таблиц) даталогическая модель включает:

−описание таблиц;

−описание связей между таблицами;

−описание атрибутов.

1.1.3 Физическое проектирование – описание физической структуры БД, т.е. ее размещения на запоминающем устройстве. Такое описание называется физической моделью. Физическая модель включает:

−тип носителя;

−способы организации данных;

−способы управления свободной памятью;

−способы сжатия данных и т.д.

Этот этап, как правило, в основным скрыт от проектировщика БД, так как реализуется средствами СУБД. Поэтому в данном пособии этот этап не рассматривается.

Примечание - При использовании систем автоматизированного проектирования БД этап инфологического проектирования обычно называют логическим проектированием, а этапы даталогического и физического проектирования – физическим проектированием.

1.2Нормальные формы

Обычно БД, разработанная по правилам инфологического и даталогического проектирования, является нормализованной, т.е. удовлетворяет определенным требованиям, обеспечивающим удобство ее хранения и обновления.

5

Тем не менее, для БД, полученной по результатам даталогического проектирования, должна выполняться проверка на соблюдение свойств нормализации. Такая проверка тем более необходима, если БД проектируется “на глаз”, без использования каких-либо строгих методик инфологического и даталогического проектирования.

Нормализация обеспечивает:

−минимальную избыточность данных (все данные хранятся один раз);

−минимальный физический объем данных;

−ускорение доступа к данным;

−сокращение риска потери данных или их искажения при внесении изменений в БД.

Нормализация выполняется для каждой таблицы, входящей в БД. Выделяется несколько уровней нормализации (нормальных форм): первая, вторая, третья и т.д. Нормализация каждой таблицы выполняется поэтапно: сначала таблица приводится к первой нормальной форме, затем – ко второй, и. т.д. При переходе к каждой последующей нормальной форме устраняются недостатки (аномалии), присущие предыдущей нормальной форме.

На практике в большинстве случаев достаточным оказывается приведение

ктретьей нормальной форме (см. подраздел 1.5). Иногда требуется приведение

кнормальной форме Бойса-Кодда (подраздел 1.6) и к четвертой нормальной форме (1.7). Приведение к нормальным формам более высоких порядков (пятая, шестая и т.д.) требуется редко.

Примечание - В данном пособии используется термин “нормализация баз данных” (или “нормализация таблиц”, или просто “нормализация”). Более точным является термин “нормализация отношений”, обычно применяемый в теории проектирования БД. Подробно теоретические основы проектирования БД рассматриваются, например, в [5,6].

Процесс нормализации БД рассмотрим на следующем примере.

Пример – Проектируется БД организации, проектирующей здания и сооружения (проектно-строительная организация). БД должна содержать информацию о сотрудниках организации, о выполняемых организацией проектах (т.е. о решаемых задачах проектирования зданий и сооружений), а также о работе сотрудников над проектами. Для каждого сотрудника должна храниться следующая информация:

−табельный номер;

−фамилия;

−специальность;

−оклад.

Для каждого проекта должна храниться следующая информация:

−номер проекта;

−адрес проектируемого объекта;

−тип объекта (например, жилой дом, склад, заводской цех и т.д.);

−нормативный документ, в соответствии с которым проектируется объект (например, некоторый стандарт, строительные нормы и правила и т.д.).

6

Кроме того, необходимо хранить информацию о работе сотрудников над проектами: перечень проектов, над которыми работает каждый сотрудник (или, наоборот, перечень сотрудников, занятых в каждом из проектов), а также дату начала и окончания работы каждого сотрудника над каждым из проектов.

Пусть по результатам анализа предметной области (проектно-строительной организации) выявлены следующие особенности данных, которые требуется хранить и обрабатывать в БД:

−табельный номер сотрудника является уникальным, т.е. все сотрудники имеют разные табельные номера. Поэтому табельный номер может использоваться в качестве идентификатора сотрудника. Аналогично, номер проекта может использоваться в качестве идентификатора проекта;

−среди сотрудников могут быть однофамильцы, поэтому фамилия сотрудника не может использоваться в качестве идентификатора;

−каждый сотрудник имеет только одну специальность;

−оклад сотрудника не зависит от его специальности, а также от проектов, над которыми он в данный момент работает;

−каждый сотрудник может работать над несколькими проектами, но может (по крайней мере, временно) не работать ни над одним проектом, например, во время отпуска;

−над каждым проектом работает несколько сотрудников. В то же время могут быть проекты, на которые не назначен ни один сотрудник (например, сразу после заключения договора о выполнении данного проекта);

−по каждому проекту разрабатывается только один объект строительства;

−для каждого типа объектов имеется только один нормативный документ. Например, строительство всех жилых домов регламентируется некоторым одним определенным документом, строительство всех складов – другим документом, и т.д.;

−работа сотрудника над проектом составляет один интервал времени. Например, невозможен случай, когда сотрудник работает над некоторым проектом с 1 марта по 31 июля, а затем над тем же проектом – с 1 октября по 30 ноября.

Примечание – Выявление всех особенностей данных, которые должны храниться в БД

– обязательная работа, которая должна быть выполнена в самом начале проектирования БД

Приведем таблицу, содержащую все данные, которые требуется хранить в БД проектно-строительной организации (таблица 1.1). В таблице также приведены примеры таких данных.

Таблица 1.1 представляет собой просто набор данных в произвольной форме. Она не является реляционной базой данных. Другими словами, данные в таком виде, как они приведены в таблице 1.1, не могут быть введены ни в одной СУБД, так как они фактически не разбиты на строки и столбцы. Например, данные о сотруднике с табельным номером 15 содержатся в одной строке, однако для описания проектов, над которыми он работает, требуются две строки.

Говоря более строго, атрибуты Номер проекта, Адрес, Тип объекта, Норма-

7