Этапы проектирования баз данных

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

Логическим проектированием данных называется процесс анализа автоматизируемой предметной области для последующего представления информации в БД. На этапе логического проектирования строится информационная модель ПО без учета физических характеристик ЭВМ. Результатом логического проектирования является концептуальная схема БД, представляющая собой описание ПО с точки зрения информационных потребностей всех пользователей в соответствии с выбранной моделью данных и правилами описания данных в применяемой СУБД. Другими словами, концептуальная схема – это описание общей структуры базы данных на языке СУБД.

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

-35-

различаться для разных ситуаций. Так, если речь идет о составе изделий, то между “ИЗДЕЛИЕМ” и “ДЕТАЛЬЮ” имеется связь типа М:М, так как одна и та же деталь может входить в разные изделия и, наоборот, в изделие входят разные детали. Состав изделия обычно является сложным, и отражать его в явном виде в структуре базы данных нежелательно, а иногда и невозможно. Кроме того, рассматриваемая связь реализована на однородном множестве объектов. В этом случае для отображения связи “целое-часть” можно воспользоваться двумя таблицами базы данных. Первая из них будет хранить информацию о самих объектах, а вторая – информацию о связи между ними, а также дополнительную информацию, характеризующую эту связь. Для состава изделия это могут быть поля “что входит”, “куда входит” и “количество”.

Отношение “целое-часть” может отражать, например, структуру какой-то организации. В этом случае ему скорее всего будет соответствовать связь типа 1:М, и для его отображения в даталогической модели можно использовать рекомендации, данные в п. 5 для соответствующего случая.

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

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

-34-

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

Рис. 22. Обобщенный объект

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

10) Наличие связи “целое-часть” также может быть отображено в даталогической модели по-разному. Само это отношение может качественно

-11-

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

		Рис. 2. Четырехуровневая схема представления БД

-12-

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

Чтобы некоторую предметную область представить в базе данных, прежде всего, необходимо выделить только те понятия, которые интересны с точки зрения целей создания базы данных. Одним из результатов проектирования является присвоение имен элементам данных, представляющих соответствующие понятия (например, «Название книги», «Имя автора» и т.п.). Конкретные значения данных при этом пока только анализируются.

Таким образом, на этапе проектирования концептуальной модели объекты ПО, их связи и свойства абстрагируются и представляются их именами.

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

Этапы проектирования БД в соответствии с четырехуровневой схемой представлены на рис. 3.

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

-33-

III. Отображение сложных объектов.

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

Рис. 21. Агрегированный объект

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

Другой крайней ситуацией является решение, при котором каждому из видов объектов нижнего уровня ставится в соответствие отдельная таблица.

-32-

Если класс принадлежности m-связного объекта является необязательным, то для реализации связи создают третью таблицу, которая будет содержать ключи каждого из связанных объектов (рис. 19).

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

Рис. 19. Связь 1:М и необязательный класс принадлежности m-связного объекта

Рис. 20. Связь M:M

-13-

Физическая структура данных

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

Для отдельных пользователей БД интересной является только часть ПО, связанная с его деятель-

ностью. Такая выделенная часть называется внешней схемой. Внешняя схема анализируется самой первой,

-14-

а проектируется самой последней. Одной предметной области соответствует одна концептуальная схема и большое число внешних схем.

СУБД MS Access в явном виде поддерживает только проектирование логической схемы БД в виде набора таблиц. Структура таблицы создается в соответствии с реляционной моделью данных в режиме “Конструктор”. Затем таблицы связываются между собой соответствующим образом по ключевым полям в режиме “Схема данных”.

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

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

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

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

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

Специальных средств для построения диаграмм инфологической модели MS Access не содержит, поэтому в настоящей работе для создания диаграмм необходимо использовать другие программные продукты, например, Corel Draw или Word.

-31-

Рис. 17. Связь 1:1 и необязательный класс

принадлежности объектов

6)Если между объектами предметной области имеется связь 1:М и класс принадлежности m-связного объекта является обязательным, то можно использовать две таблицы, по одной для каждого объекта. В таблице, соответствующей m-связному объекту, при этом надо дополнительно добавить идентификатор связанного с ним объекта (рис.18).

Рис. 18. Связь 1:М и обязательный класс

принадлежности m-связного объекта

-30-

Рис. 15. Связь 1:1 и обязательный класс

принадлежности объектов

Рис. 16. Связь 1:1 и обязательный класс

принадлежности одного из объектов

Если степень связи между объектами 1:1 и класс принадлежности каждого из них является необязательной, то следует использовать три таблицы: по одной для каждого объекта и одну для отображения связи между ними (рис.17).

-15-