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

Создание базы данных (БД) в среде системы управления базами данных Access (СУБД Access) предполагает выполнение следующих основных этапов:

1. концептуальное проектирование;

2. логическое проектирование;

3. физическое проектирование;

4. использование БД – заполнение БД оперативной информацией и формирование запросов и отчетов.

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

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

Чаще всего концептуальная модель базы данных включает в себя:

§ Описание информационных объектов, или понятий предметной области и связей между ними.

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

На этапе логического проектирования информационная модель предприятия уточняется с учетом типа создаваемой БД – реляционной, сетевой или иерархической.

Логическое (даталогическое) проектирование — это создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель — набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.

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

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

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

Процесс физического проектирования БД предполагает выполнение в среде выбранной СУБД следующих работ:

1. описание логической структуры каждой таблицы;

2. описание связей между таблицами, входящими в одну БД;

3. первоначальное заполнение справочников БД необходимой нормативно-справочной информацией.

Концепция ER-метода логического проектирования

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

1. выделены все сущности, информация о которых должна содержаться в искомой БД;

2. определены основные атрибуты для каждой сущности;

3. назначен ключевой атрибут для каждой сущности;

4. сформулированы связи между выделенными сущностями;

5. выявлены условия применения выделенных сущностей на данном предприятии.

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

В качестве определения ER-метода можно принять следующее:

· основу ER-метода составляют понятия: сущность, связь и атрибуты;

· суть ER-метода состоит в наборе формализованных процедур и правил, позволяющих получить полный набор таблиц и определить структуру каждой таблицы на основе приведенных выше пяти компонент информационной модели предметной области.

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

Основные понятия

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

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

Атрибут есть свойство сущности.

Например, атрибутами (свойствами) сущности Студент являются: фамилия, имя, отчество, номер зачетной книжки, год рождения, академическая группа и т.д.

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

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

ER-диаграммы

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

Сущность Продукт характеризуется такими атрибутами как Номер продукта (НП), Наименование продукта (НАИМ), Единица измерения (ЕИ), Упаковка (УП) и др. Для дальнейшего рассмотрения важно лишь то, что атрибут НП является ключом сущности Продукт. Это означает, что значение атрибута НП однозначно определяет конкретный продукт, т.е экземпляр сущности Продукт. Для определенности будем считать, что НП принимает следующие значения: П1, П2, П3 и т.д.

Сущность Склад обладает следующими атрибутами: Номер склада(НС), Емкость склада (ЕС), Материально ответственное лицо (МОЛ) и т.д. Ключом сущности является атрибут НС. Будем считать, что НС принимает значения С1, С2, С3 и т. д.

Сущности Продукт и Склад соотносятся с помощью связи Хранится. Эта связь может быть графически представлена в виде диаграммы ER-экземпляров и диаграммы ER-типа.

ПРОДУКТ ХРАНИТСЯ СКЛАД

П1 С1

П2 С2

П3 С3

П4 С3

Рис. 1 Пример диаграммы ER-экземпляров

НП…. НС

Рис. 2 Пример диаграммы ER-типа

В большинстве случаев для определения набора отношений проектируемой БД используются диаграммы ER-типа, а не диаграммы экземпляров.

Характеристики связи

Важной характеристикой связи между двумя (и более) сущностями является степень связи.

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

Показатель кардинальности описывает количество возможных связей для каждого из экземпляров рассматриваемых сущностей.

Наиболее распространенными являются бинарные связи с показателями кардинальности "один к одному" (1:1), "один ко многим" (1:n) или "многие к одному" (n:1), "многие ко многим" (m:n).

Например, если для характеристики студентов вуза выделены две сущности Анкетные данные студентов и Успеваемость студентов (в каждой из этих сущностей ключевым атрибутом является шифр студента), то для связи Учится между экземплярами этих сущностей показатель кардинальности будет 1:1, т. е. каждый студент должен быть в точности один раз охарактеризован в каждой из этих сущностей.

Если рассмотреть две сущности Академическая группа (ключ – шифр группы) и Факультет (ключ – шифр факультета), то показатель кардинальности связи Принадлежит между экземплярами этих сущностей равен n:1, т.е. каждая группа обязательно принадлежит какому-то одному факультету, но в каждом факультете есть несколько групп. Заметим, что между сущностями Факультет и Академическая группа показатель кардинальности связи равен 1:n.

Для связи Преподает (Читает) между сущностями Преподаватель и Учебный курс (Дисциплина) показатель кардинальности будет m:n, т.к. каждый преподаватель читает несколько курсов и каждый курс может читаться разными преподавателями (для разных потоков).

Показатели кардинальности связей между экземплярами сущностей зависят прежде всего от производственных правил, установленных в данной организации, т.е. условиями применения сущностей.

Заметим, что показатель кардинальности не может полностью характеризовать связь между экземплярами сущности. Приведем пример. Пусть в одной организации действует следующее условие применения сущностей Продукт и Склад: каждый продукт хранится не более чем на одном складе, и каждый склад хранит не более одного продукта. Во второй организации аналогичное условие применения формулируется следующим образом: каждый продукт хранится не более чем на одном складе, и каждый склад хранит в точности один продукт. В обоих случаях связи имеют один показатель кардинальности 1:1, но здесь действуют разные условия использования складов: в первом случае каждый склад хранит в точности один продукт, а во втором случае на складе может и не быть продуктов, т.е. некоторый склад может не использоваться.

Чтобы различать связи такого рода используется еще одна характеристика связи - класс принадлежности сущности для (конкретной) связи.

Если все экземпляры данной сущности должны участвовать в некоторой связи, то участие в этой связи называется обязательным, т.е. класс принадлежности данной сущности для этой связи является обязательным. Этот факт мы будем отмечать на диаграмме ER-типа помещением жирной точки на границе прямоугольника, обозначающего эту сущность.

Если экземпляры данной сущности могут не участвовать в некоторой связи, то участие в этой связи называется необязательным, т.е. класс принадлежности данной сущности для этой связи является необязательным. В этом случае на диаграмме ER-типа жирная точка вообще не помещается на диаграмме.

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

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

Методика применения ER-метода

Таким образом, в качестве исходных данных для выполнения логического проектирования БД этап концептуального проектирования предоставляет свои результаты:

· набор сущностей;

· предварительный перечень атрибутов для каждой сущности (основные атрибуты);

· ключевой атрибут для каждой сущности;

· набор связей между сущностями;

· описание условий применения объектов (сущностей) на данном предприятии.

ER-метод логического проектирования предполагает выполнение следующих работ:

1. если в результате концептуального проектирования БД были выделены документы-сущности, то необходимо каждую из них представить в виде двух сущностей Заголовок документа и Строка документа;

2. определение показателя кардинальности для каждой из связей (на основе производственных условий использования сущностей и, если это необходимо, диаграммы ER-экземпляров);

3. определение класса принадлежности каждой сущности в каждой связи;

4. построение диаграммы ER-типа;

5. на основании правил 1-6 определение всех отношений БД, их атрибутов и первичных ключей.

6. Отметим роль диаграмм ER-типа и ER-экземпляров при проектировании базы данных.

7. Построение диаграммы ER-типа при проектировании БД дает возможность выбрать правило генерации отношений.

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

9. Диаграмма ER-экземпляров дает возможность определить показатель кардинальности связи и класс принадлежности каждой сущности для рассматриваемой связи.

При этом действуют следующие правила:

· если точка в левой части диаграммы может быть соединена только с одной точкой в правой части, то связь будет иметь показатель …:1;

· если точка в левой части диаграммы может быть соединена с несколькими точками в правой части, то связь будет иметь показатель …:n;

· если точка в правой части диаграммы может быть соединена только с одной точкой в левой части, то связь будет иметь показатель 1:…;

· если точка в правой части диаграммы может быть соединена с несколькими точками в левой части, то связь будет иметь показатель n: …;

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

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