В начало

5. Задания для самостоятельной работы

2. Инфологическая модель сущность-связь

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

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

Рис. 2.1. Уровни моделей данных

Такая человеко-ориентированная модель полностью независима от физических параметров среды хранения данных.

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

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

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

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

Сущность - любой различимый объект (объект, который мы можем отличить от другого объекта), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром сущности - города Москва, Киев и т.д.

Атрибут - поименованная характеристика сущности. Наименование атрибута должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д. Здесь также существует различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений:

Красный, Синий, Банановый, Белая ночь и т.д.,

однако каждому экземпляру сущности присваивается только одно значение атрибута.

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

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

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

2.1. Характеристика связей

Между двумя сущностями, возможны четыре вида связей.

Первый тип - связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности Студент соответствует 1 или 0 представителей сущности Стипендия:

Студент может не получать стипендии, либо получать только одну стипендию.

Второй тип - связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

В квартире может никто не жить или жить один или несколько жильцов.

Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще тип связи МНОГИЕ-К-ОДНОМУ (М:1).

Третий тип - многие ко многим.

Если связь между сущностями Квартира и Владелец называется Владение, то существует четыре возможных представления такой связи:

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

2.2. О первичных и внешних ключах

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

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

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

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

Теперь о внешних ключах:

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

В таблице Издание поля ВидИздания и КодИздательства является внешним ключом, соответствующим внутренним ключам КодиВидИздания и КодИздательства таблиц ВидИздания и Издательства соответственно.

Если сущность В обозначает сущность А, то она должна включать внешний ключ, соответствующий первичному ключу сущности А.

Поле Ind1 таблицы Подчиненная является внешним ключом, соответствующим внутреннему ключу Ind таблицы Основная. Заметим, что таблица Подчиненная также имеет свой внутренний ключ Ind.

2.3. Классификация сущностей

Имеется четыре вида сущностей:

• Основная
• Характеристика
• Справочник
• Ассоциация

Основная сущность (стержень) - это независимая сущность.

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

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

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

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

Это могут быть имена организаций, фамилии клиентов, цвета…

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

При отсутствии жестких правил (сотрудник может одновременно зачисляться в несколько отделов или не зачисляться ни в один отдел) необходимо создать описание с ассоциацией Зачисление:

Отделы (Номер отдела, Название отдела, ...)

Служащие (Табельный номер, Фамилия, ...)

Зачисление (Номер отдела, Табельный номер, Дата зачисления) [Отделы M, Служащие N]

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

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

Отделы (Номер отдела, Название отдела, ...)

Служащие (Табельный номер, Фамилия, ..., Номер отдела, Дата зачисления)[Отделы]

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

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

Рассмотрим вид сущности: Ассоциация.

Ассоциация обычно имеет собственные поля и несколько ссылок на другие сущности.

В СУБД Access тип сущности Ассоциация имеет вид:

2.4. Ограничения целостности

Целостность (от англ. integrity - нетронутость, неприкосновенность, сохранность, целостность) - понимается как правильность данных в любой момент времени. Но эта цель может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность). Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть равно 3. С другой стороны, значение 9, как день недели, явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить, что номера дней недели должны принадлежать набору (1, 2, 3, 4, 5, 6, 7).

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

2.4.1. Средства поддержания целостности данных СУБД Access

Рассмотрим три типа таблиц:

• Основная
• Подчиненная
• Справочник

Таблицы имеют структуру:

Во всех таблицах поле Ind - счетчик (см. 1.3).

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

Сформируем связи таблиц.

Связь между Основной и Подчиненной таблицами оформим так:

Это означает, что мы не сможем сформировать запись в подчиненной таблице с Ind1 <> Ind основной таблицы. Более того, при удалении записи из основной таблицы будет удалена и запись связанной с ней подчиненной таблицы.

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

Связь между основной таблицей и справочником имеет вид:

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