Логическое проектирование баз данных

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

Модель семантических объектов

Модель впервые предложена Кренке в 1988 г.

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

Рассмотрим диаграммы семантических объектов Магазин, Продавец, Товар (рис. 2): 

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

Для каждого атрибута указана его кардинальность (минимальное и максимальное количество вхождений этого атрибута в объект). Например, если для атрибута Цена объекта Товар приводится кардинальность 1, 1, это означает, что товар обязательно должен иметь цену, и только одну. Атрибут Производитель объекта Товар имеет кардинальность 1, N. Это указывает на то, что один и тот же товар может изготавливаться одним или несколькими производителями (см. рис. 2). Атрибут Склад объекта Магазин имеет кардинальность 0, N. Следовательно, склад при магазине может отсутствовать, или их имеется несколько. Атрибуты, которые принимают более одного значения, называются многозначными.

В объекте Магазин имеется группированный атрибут Адрес. Атрибуты, входящие в его состав, объединены скобкой (см. рис. 2).

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

Диаграммы семантических объектов допускают создание агрегированных объектов, подклассов объектов

1.3 Этап логического проектирования

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

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

Существуют методы однозначного преобразования ER-модели в логическую модель реляционной базы данных. Эти методы положены в основу работы многих CASE-систем – инструментальных средств автоматизированного проектирования баз данных

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

Для сущности, имеющей только простые атрибуты (например, Магазин), может быть созданы одна таблица. Каждый атрибут сущности становится полем таблицы, ключевые атрибуты сущности – первичным ключом таблицы. Для каждого поля определяется допустимый тип данных и другие ограничения целостности. Названия сущности и таблицы, атрибутов и полей могут совпадать, если используемая СУБД не накладывает на них никаких ограничений (табл. 3):

Если между двумя сущностями имеется связь «один к одному», а класс принадлежности связи для обеих сущностей является обязательным, обе сущности можно объединить в одну таблицу. Первичным ключом таблицы может быть первичный ключ любой сущности. Например, имеются связанные сущности Директор и Магазин. В каждом магазине есть директор, и каждый директор руководит только одним магазином. Таблица, включающая атрибуты сущностей Директор и Магазин, может выглядеть следующим образом (табл. 4):

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

Рассмотрим связь между сущностями Магазин и Автомобиль. Предположим, лишь некоторым магазинам («Светлый», «Восток») принадлежит автомобиль (только один). У других магазинов («Факел») автомобиля нет (класс принадлежности связи для сущности Магазин является необязательным). Каждый автомобиль является собственностью некоторого магазина (класс принадлежности связи для сущности Автомобиль является обязательным). Таблица с информацией о магазинах будет идентична табл. 3, а таблица с информацией об автомобилях будет иметь следующий вид (табл. 5):

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

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

Рассмотрим связь «один ко многим» между сущностями Магазин и Работник (см. рис. 1). Класс принадлежности связи для сущности Работник является обязательным. Таблица с информацией о магазинах будет иметь вид, идентичный табл. 3, таблица с информацией о работниках будет включать ключ таблицы Магазин (табл. 6):

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

Рассмотрим связь «многие ко многим» между сущностями Продавец и Товар. Таблица Продавцы может иметь структуру, совпадающую со структурой таблицы Работники (см. табл. 6), таблица Товары будет иметь вид (табл. 7):

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

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

На логическом проектировании баз данных мы и остановимся конкретнее.

2 Логическое проектирование баз данных

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

2.1 Исходные данные для логического проектирования

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

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

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

2.2 Результат логического проектирования

Конечным результатом даталогического проектирования является' описание логической структуры базы данных на ЯОД. Однако если проектирование выполняется «вручную», то для большей наглядности сначала строится схематическое графическое изображение структуры базы данных. При этом должно быть обеспечено однозначное соответствие между конструкциями языка описания данных и графическими обозначениями информационных единиц и связей между ними. Графическое представление используется и при автоматизированном проектировании структуры базы данных как интерфейсное средство общения с проектировщиком, и при документировании проекта.

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

2.3 Подход к логическому проектированию

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

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

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

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

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

Для любой предметной области существует множество вариантов проектных решений ее отображения в логической модели. Методика проектирования должна обеспечивать выбор наиболее подходящего проектного решения.

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

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

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

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

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