Построение логических записей

 

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

Пусть требуется разработать модель данных системы резервирования авиабилетов. Причем известны следующие элементы данных.

 

Поскольку все элементы данных в примере относятся к рейсам самолетов, то ключом логической записи логично было бы выбрать номер рейса. Действительно этот атрибут обладает основным свойством ключа – каждый рейс имеет свой уникальный номер. Связи между элементами определяются ролью каждого из них по отношению к ключу. Так, из пункта отправления могут отправляться много рейсов, но каждый рейс имеет только один пункт отправления, поэтому связь между ними со стороны ключа будет М:1. Следовательно, эти атрибуты можно объединить в логическую запись. То же касается атрибутов «Пункт назначения», «Тип самолета». Между ключом и атрибутом «Дата вылета» существует связь М:М, так как один и тот рейс может вылетать в разные даты, а в одну и ту же дату могут вылетать разные рейсы, то есть эти атрибуты нельзя объединить в логическую запись. То же касается и атрибута «Количество свободных мест». Однако эти два атрибута несут существенную информационную нагрузку и должны быть включены в модель. Чтобы решить эту проблему, можно преобразовать схему так.

 

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

	Рейс

 

Модели данных различаются по характеру связей между логическими записями. В зависимости от этого параметра различают иерархические, сетевые и реляционные модели данных.

Иерархические модели данных

 

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

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

Найти группу, где учится студент А.

Найти факультет, где учится студент А.

Найти дисциплины, которые изучает студент А.

Для получения ответа на первый запрос необходимо найти запись о студенте среди записей «Студент» и далее найти связанную с ним запись из записей «Группа».

Для получения ответа на второй запрос необходимо найти запись о студенте среди записей «Студент», найти связанную с ним запись из записей «Группа» и далее связанную с последней запись из группы записей «Факультет».

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

Сетевые модели данных.

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

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

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

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

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

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

 

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

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

Реляционные модели данных

 

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

Пусть задано отношение, содержащее данные о поставке продукции некоторыми поставщиками.

 

№ заказа	Поставщик	Дата	Товар	Характеристики	Цена
	А…	17.04.03	П…	О……	256.00
	А…	17.04.03	Р…	Л…	4598.00
	А…	17.04.03	Е…	Н…..	785.00
	В…	18.04.03	П…	О……	256.00

 

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

№ заказа	Поставщик	Дата
	А…	17.04.03
	В…	18.04.03

 

№ заказа	Товар	Характеристики	Цена
	П…	О……	256.00
	Р…	Л…	4598.00
	Е…	Н…..	785.00
	П…	О……	256.00

 

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

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

ЗАКАЗ(№ заказа, Поставщик, Дата)

ТОВАРЫ(№ заказа, Товар, Характеристики, Цена)

Преобразование сетевых моделей в реляционные

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

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

Преобразуют сетевую модель к реляционной.

Процесс преобразования моделей удобно рассмотреть на следующем примере.

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

 

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

 

 

 

Как видно из полученной модели связующие атрибуты добавлялись в отношения стоящие в исходной модели по стрелке со стороны М. Для устранения связи М:М и размещения данных пересечения (количество персонала отделов, работающих в зданиях) создано отношение Размещение с составным ключом. Записанная по правилам записи реляционных моделей полученная схема примет следующий вид.

ОТДЕЛЕНИЯ(Код отделения, Наименование, Руководитель, Город)

ЗДАНИЯ(Номер здания, Адрес)

ОТДЕЛЫ(Код отдела, Код отделения, Наименование, Начальник, Телефон)

РАЗМЕЩЕНИЕ(Номер здания, Код отдела, Количество персонала)

ПРОЕКТ(Номер проекта, Код отдела, Содержание, Дата окончания)

ПЕРСОНАЛ(Табельный номер, Код отдела, Номер проекта, Имя, Должность, Дата рождения)

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