Инфологическая модель данных
Инфологическая модель реляционной БД – это структурная схема объектов БД – её таблиц и логических связей между таблицами.
Слово «реляционная» происходит от relation (англ.) – отношение, в математических моделях данных отношения изображают в виде таблиц, поэтому БД, состоящая из двумерных таблиц, называется реляционной. Реляционная БД (РБД)состоит из нескольких таблиц, содержащих массивы данных, между таблицами установлены логические связи, которые и объединяют их в единую базу данных.
Простой ключ или ключевой атрибут (в русифицированной версии Access – первичный ключ или ключевое поле) должен однозначно идентифицировать (определять) любую запись в таблице БД. Например, поле Фамилия не может быть первичным ключом, т.к. в кортежах БД могут быть люди с одной фамилией, поле Корпус может означать и корпус прибора, и воинское подразделение и т.п., поэтому в качестве первичного выбирают уникальные атрибуты – Табельный номер, шифр изделия, Код дисциплины и т.п.
Составной ключ –это первичный ключ, состоящий из нескольких
атрибутов, например, по отдельности атрибуты Фамилия и Дата рождения не могут однозначно определить любую запись таблицы, а составной атрибут Фамилия+Дата рождения является уникальным (единственным), так как маловероятно, что в таблице могут иметься две записи с совпадающими значениями этих полей.
Внешний ключ –это атрибут, который служит для связи с другими таблицами и имеется во всех таблицах, между которыми устанавливается связи.Обычнотаблица БД имеет один ключевой атрибут (простой или составной) и один или несколько вторичных. Внешним ключом для подчинённой таблицы является первичный ключ. Для задания связи эти поля таблицы должны иметь одинаковые имена или хотя бы одинаковые форматы данных.
связь 1:1
Рисунок 1 Инфологическая модель реляционной БД «Деканат»
Между таблицами БД может быть три вида связей:
· связь «один ко многим», 1:N, например, между кафедрой и преподавателями, т.к. у кафедры много преподавателей, а у каждого преподавателя – одна кафедра и
· связь»многие ко многим», N:M, например, между преподавателями
и дисциплинами, т.к. один преподаватель читает несколько дисциплин, и одна дисциплина может читаться несколькими преподавателями.
Связи «один к одному» и «один ко многим» легко устанавливаются в Access, а связь «многие ко многим» напрямую не может быть реализована, но фактически она представляет собой две связи типа «один ко многим», поэтому для неё создаётся третья таблица, ключ которой состоит из двух полей, общих для двух таблиц со связью N:M. Таким образом, связь N:M заменяется на ещё одну таблицу, которая связывается с обеими таблицами двумя связями 1:N. В таблице связи, кроме ключевых атрибутов могут быть и другие описательные поля.
Например, связь N:M между таблицами-объектами ГРУППА и ДИСЦИПЛИНА реализуется с помощью третьей таблицы с именем ГРУП-ДИСЦ, которые связаны с исходными таблицами связями 1:N (рис. 2).
N M
Рисунок 2 Замена связи N:M на таблицу с двумя связями 1:N
Таким образом, реализация связи «многие ко многим» добавляет в БД ещё один объект – таблицу связи.
Логическая модель реляционной БД – это инфологическая БД, в которой каждая её таблица представлена своей схемой – шапкой таблицы и показаны ключевые атрибуты, между которыми установлены логические связи между таблицами.
Лекция 7. Инфологическое моделирование
В настоящий момент не существует единой общепринятой системы обозначений для ER-модели и разные CASE-системы используют разные графические нотации, но разобравшись в одной, можно легко понять и другие нотации.
Модель «cущность—связь»
Как любая модель, модель «сущность—связь» имеет несколько базовых понятий, которые образуют исходные кирпичики, из которых строятся уже более сложные объекты по заранее определенным правилам.
Эта модель в наибольшей степени согласуется с концепцией объектно-ориентированного проектирования, которая в настоящий момент несомненно является базовой для разработки сложных программных систем, поэтому многие понятия вам могут показаться знакомыми, и если это действительно так, то тем проще вам будет освоить технологию проектирования баз данных, основанную на ER-модели.
В основе ER-модели лежат следующие базовые понятия:
Рис. 7.1. Пример определения сущности в модели ER
Рис. 7.2. Пример отношения «один-ко-многим» при связывании сущностей «Студент» и «Преподаватель»
Рис. 7.3. Пример моделирования связи «многие-ко-многим»
Рассмотрим для этого ранее приведенный пример связи «Дипломное проектирование». На нашем рисунке эта связь интерпретируется как необязательная с двух сторон. Но ведь на самом деле каждый студент, который пишет диплом, должен иметь своего руководителя дипломного проектирования, но, с другой стороны, не каждый преподаватель должен вести дипломное проектирование. Поэтому в данной смысловой постановке изображение этой связи изменится и будет выглядеть таким, как представлено на рис. 7.4.
Рис. 7.4. Пример обязательной и необязательной связи между сущностями
Кроме того, в ER-модели допускается принцип категоризации сущностей. Это значит, что, как и в объектно-ориентированных языках программирования, вводится понятие подтипа сущности, то«есть сущность может быть представлена в виде двух или более своих подтипов — сущностей, каждая из которых может иметь общие атрибуты и отношения и/или атрибуты и отношения, которые определяются однажды на верхнем уровне и наследуются на нижнем уровне. Все подтипы одной сущности рассматриваются как взаимоисключающие, и при разделении сущности па подтипы она должна быть представлена в виде полного набора взаимоисключающих подтипов. Если на уровне анализа не удается выявить полный Перечень подтипов, то вводится специальный подтип, называемый условно ПРОЧИЕ, который в дальнейшем может быть уточнен. В реальных системах бывает достаточно ввести подтипизацпю на двух-трех уровнях.
Сущность, на основе которой строятся подтипы, называется супертипом. Любой экземпляр супертипа должен относиться к конкретному подтипу. Для графического изображения принципа категоризации или типизации сущности вводится специальный графический элемент, называемый узел-дискриминатор, в нотации POWER DESIGNER он изображается в виде полукруга, выпуклой стороной обращенного к суперсущности. Эта сторона соединяется направленной стрелкой с суперсущностью, а к диаметру этого круга стрелками подсоединяются подтипы данной сущности (см. рис. 7.5).
Рис. 7.5. Диаграмма подтипов сущности ТЕСТ
Эту диаграмму можно расшифровать следующим образом. Каждый тест в некоторой системе тестирования является либо тестом проверки знаний языка SQL, либо некоторой аналитической задачей, которая выполняется с использованием заранее написанных Java-апплетов, либо тестом по некоторой области знаний, состоящим из набора вопросов и набора ответов, предлагаемых к каждому вопросу.
В результате построения модели предметной области в виде набора сущностей и связей получаем связный граф. В полученном графе необходимо избегать циклических связей — они выявляют некорректность модели.
В качестве примера спроектируем инфологическую модель системы, предназначенной для хранения информации о книгах ц областях знаний, представленных в библиотеке. Описание предметной области было приведено ранее. Разработку модели начнем с выделения основных сущностей.
Прежде всего, существует сущность «Книги», каждая книга имеет уникальный шифр, крторый является ее ключом, и ряд атрибутов, которые взяты из описания предметной области. Множество экземпляров сущности определяет множество книг, которые хранятся в библиотеке. Каждый экземпляр сущности «Книги» соответствует не конкретной книге, стоящей на полке, а описанию некоторой книги, которое дается обычно в предметном каталоге библиотеке. Каждая книга может присутствовать в нескольких экземплярах, и это как раз те конкретные книги, которые стоят на полках библиотеки. Для того чтобы отразить это, мы должны ввести сущность «Экземпляры», которая будет содержать описания всех экземпляров книг, которые хранятся в библиотеке. Каждый экземпляр сущности «Экземпляры» соответствует конкретной книге на полке. Каждый экземпляр имеет уникальный инвентарный номер, однозначно определяющий конкретную книгу. Кроме того, каждый экземпляр книги может находиться либо в библиотеке, либо на руках у некоторого читателя, и в последнем случае для данного экземпляра указываются дополнительно дата взятия книги читателем и дата предполагаемого возврата книги.
Между сущностями «Книги» и «Экземпляры» существует связь «один-ко-многим» (1:М), обязательная с двух сторон. Чем определяется данный тип связи? Мы можем предположить, что каждая книга может присутствовать в библиотеке в нескольких экземплярах, поэтому связь «один-ко-многим». При этом если в библиотеке нет ни одного экземпляра дайной книги, то мы не будем хранить ее описание, поэтому если книга описана в сущности «Книги», то по крайней мере один экземпляр этой книги присутствует в библиотеке. Это означает, что со стороны книги связь обязательная. Что касается сущности «Экземпляры», то не может существовать в библиотеке ни одного экземпляра, который бы не относился к конкретной книге, поэтому и со стороны «Экземпляры» связь тоже обязательная.
Теперь нам необходимо определить, как в нашей системе будет представлен читатель. Естественно предложить ввести для этого сущность «Читатели», каждый экземпляр которой будет соответствовать конкретному читателю. В библиотеке каждому читателю присваивается уникальный номер читательского билета, который будет однозначно идентифицировать нашего читателя. Номер читательского билета будет ключевым атрибутом сущности «Читатели». Кроме того, в сущности «Читатели» должны присутствовать дополнительные атрибуты, которые требуются для решения поставленных задач, этими атрибутами будут: «Фамилия Имя Отчество», «Адрес читателя», «Телефон домашний» и «Телефон рабочий». Почему мы ввели два отдельных атрибута под телефоны? Потому что надо в разное время звонить по этим телефонам, чтобы застать читателя, поэтому администрации библиотеки будет важно знать, к какому типу относится данный телефон. В описании нашей предметной области существует ограничение на возраст наших читателей, поэтому в сущности «Читатели» надо ввести обязательный атрибут «Дата рождения», который позволит нам контролировать возраст наших читателей.
Из описания предметной области мы знаем, что каждый читатель может держать на руках несколько экземпляров книг. Для отражения этой ситуации нам надо провести связь между сущностями «Читатели» и «Экземпляры». А почему не между сущностями «Читатели» и «Книги»? Потому что читатель берет из библиотеки конкретный экземпляр конкретной книги, а не просто книгу. А как же узнать, какая книга у данного читателя? А это можно будет узнать по дополнительной связи между сущностями «Экземпляры» и «Книги», и эта связь каждому экземпляру ставит в соответствие одну книгу, поэтому мы в любой момент можем однозначно определить, какие книги находятся на руках у читателя, хотя связываем с читателем только инвентарные номера взятых книг. Между сущностями «Читатели» и «Экземпляры» установлена связь «один-ко-многим», и при этом она не обязательная с двух сторон. Читатель в данный момент может не держать ни одной книги на руках, а с другой стороны, данный экземпляр книги может не находиться ни у одного читателя, а просто стоять на полке в библиотеке.
Теперь нам надо отразить последнюю сущность, которая связана с системным каталогом. Системный каталог содержит перечень всех областей знаний, сведения по которым содержатся в библиотечных книгах. Мы можем вспомнить системный каталог в библиотеке, с которого мы обычно начинаем поиск нужных нам книг, если мы не знаем их авторов и названий. Название области знаний может быть длинным и состоять из нескольких слов, поэтому для моделирования системного каталога мы введем сущность «Системный каталог» с двумя атрибутами: «Код области знаний» и «Название области знаний». Атрибут «Код области знаний» будет ключевым атрибутом сущности.
Из описания предметной области нам известно, что каждая книга может содержать сведения из нескольких областей знаний, а с другой стороны, из практики известно, что в библиотеке может присутствовать множество книг, относящихся к одной и той же области знаний, поэтому нам необходимо установить между сущностями «Системный каталог» и «Книги» связь «миогие-ко-многим», обязательную с двух сторон. Действительно, в системном 1 каталоге не должно присутствовать такой области знаний, сведения по которой не представлены ни в одной книге нашей библиотеки, противное было бы бессмысленно. И обратно, каждая книга должна быть отнесена к одной или нескольким областям знаний для того, чтобы читатель мог ее быстрее найти.
Инфологическая модель предметной области «Библиотека» представлена на рис. 7.6.
Рис. 7.6. Инфологическая модель «Библиотека»
Инфологическая модель «Библиотека» разработана нами под те задачи, которые были перечислены ранее. В этих задачах мы не ставили условие хранения истории чтения книги, например, с целью поиска того, кто раньше держал книгу и мог нанести ей вред или забыть в ней случайно большую сумму денег. Если бы мы ставили перед собой задачу хранения и этой информации, то наша инфо-логическая модель была бы другой. Я оставлю эту задачу для вашего самостоятельного творчества.
Переход к реляционной модели данных
Инфологическая модель используется на ранних стадиях разработки проекта. Если понимать язык условных обозначений, которые соответствуют категориям ER-модели, то ее можно легко «читать», следовательно, она доступна для анализа программистам-разработчикам, которые будут разрабатывать отдельные приложения. Она имеет однозначную интерпретацию, в отличие от некоторых предложений естественного языка, и поэтому здесь не может быть никакого недопонимания со стороны разработчиков.
Все специалисты всегда предпочитают выражать свои мысли на некотором формальном языке, который обеспечивает однозначную их трактовку. Таким языком для программистов раньше был язык алгоритмов. Любой алгоритм имел однозначную интерпретацию. Он мог быть реализован на разных языках программирования, но сам алгоритм был и оставался одним и тем же. В первые годы развития вычислительной техники широко издавались сборники алгоритмов для широко распространенных математических задач. Эти сборники программистами прочитывались как увлекательные детективные романы, и они все настоящим программистам были понятны, хотя специалисты других профилей смотрели на эти сборники как на издания на иностранных, неведомых им, языках. Для описания алгоритмов могли использоваться разные формализмы. Одним из таких формализмов был метаязык, в котором использовались слова на естественном языке и каждый мог прочесть эти слова, но смысл самого алгоритма мог понять только тот, кто владел знаниями трактовки алгоритмов.
Вот таким условным общепринятым языком описания базы данных и стал язык ER-модели. Для ER-модели существует алгоритм однозначного преобразования ее в реляционную модель данных, что позволило в дальнейшем разработать множество инструментальных систем, поддерживающих процесс разработки информационных систем, базирующихся на технологии баз данных. И во всех этих системах существуют средства описания инфологической модели разрабатываемой БД с возможностью автоматической генерации той даталогической модели, на которой будет реализовываться проект в дальнейшем.
Рассмотрим правила преобразования ER-модели в реляционную.
Рис. 7.7. Преобразование сущности СОТРУДНИК к отношению EMPLOYEE
Рис. 7.8. Свойства атрибутов отношения EMPLOYEE
Рис. 7.9. Преобразование взаимосвязанных сущностей СТУДЕНТ и ПРЕПОДАВАТЕЛЬ к взаимосвязанным отношениям STUDENT и PROFESSOR
Рис. 7.10. Исходная модель взаимосвязи супертипа и подтипов
Разрешение связей типа «многие-ко-многим». Так как в реляционной модели данных поддерживаются между отношениями только связи типа «один-ко-мно-гим», а в ER-модели допустимы связи «многие-ко-многим», то необходим специальный механизм преобразования, который позволит отразить множественные связи, неспецифические для реляционной модели, с помощью допустимых для нее категорий. Это делается введением специального дополнительного связующего отношения, которое связано с каждым исходным связью «один-ко-мно-гим», атрибутами этого отношения являются первичные ключи связываемых отношений. Так, например, в схеме «Библиотека» присутствует связь такого типа между сущностью «Книги» и «Системный каталог». Для разрешения этой неспецифической связи при переходе к реляционной модели должно быть введено специальное дополнительное отношение, которое имеет всего два атрибута: ISBN (шифр книги) и KOD (код области знаний). При этом каждый из атрибутов нового отношения является внешним ключом (FORKING KEY), а вместе они образуют первичный ключ (PRIMARY KEY) новой связующей сущности. На рис. 7.12 представлена реляционная модель, соответствующая представленной ранее на рис. 7.6 инфологической модели «Библиотека».
Теория нормализации, которую мы рассматривали ранее применительно к реляционной модели, применима и к модели «сущность—связь». Поэтому нормализацию можно проводить и на уровне инфологической (семантической) модели и смысл ее аналогичен нормализации реляционной модели. Алгоритм приведения семантической модели к 5-й нормальной форме может быть следующим:
Рис. 7.12. Результирующая модель с наследованием всех атрибутов суперсущности
Шаг 1. Проанализировать схему на присутствие сущностей, которые скрыто моделируют несколько разных взаимосвязанных классов объектов реального мира (именно это соответствует ненормализованным отношениям). Если такое выявлено, то разделить каждую из этих сущностей на несколько новых сущностей и установить между ними соответствующие связи, полученная схема будет находиться в первой нормальной форме. Перейти к шагу 2.
Шаг 2. Проанализировать все сущности, имеющие составные первичные ключи, на наличие неполных функциональных зависимостей непервичных атрибутов от атрибутов возможного ключа. Если такие зависимости обнаружены, то разделить данные сущности на 2, определить для каждой сущности первичные ключи и установить между ними соответствующие связи. Полученная схема будет находиться во второй нормальной форме. Перейти к шагу 3.
Шаг 3. Проанализировать неключевые атрибуты всех сущностей на наличие транзитивных функциональных зависимостей. При обнаружении таковых расщепить каждую сущность на несколько таким образом, чтобы ликвидировать транзитивные зависимости. Схема находится в третьей нормальной форме. Перейти к шагу 4.
Шаг 4. Проанализировать все сущности на наличие детерминантов, которые не являются возможными ключами. При обнаружении подобных расщепить сущность на две, установив между ними соответствующие связи. Полученная схема соответствует нормальной форме Бойса—Кодда. Перейти к шагу 5.
Шаг 5. Проанализировать все сущности на наличие многозначных зависимостей. Если обнаружатся сущности, у которых имеется более одной многозначной зависимости, то расщепить такие сущности на две, установив между ними соответствующие связи. Полученная схема будет находиться в четвертой нормальной форме. Перейти к шагу 6.
Рис. 7.13. Реляционная схема «Библиотека»
Шаг 6. Проанализировать сущности на наличие в них зависимостей проекции-соединения. При обнаружении таковых расщепить сущность на требуемое число взаимосвязанных сущностей и установить между ними требуемые связи. Полученная таким образом схема будет находиться в пятой нормальной форме и, будучи формально преобразованной к реляционной схеме по указанным выше принципам, даст реляционную схему также в пятой нормальной форме.
200 тыс км/с в стекле и
3 млн. км/с в поверхностных слоях металлов, разную скорость в эфире (см. статью «Температура эфира и красные смещения»), разную скорость для разных частот (см. статью «О скорости ЭМ-волн»)
3. В релятивизме возможны манипуляции со временем (замедление), поэтому там нарушаются основополагающие для любой науки принцип причинности и принцип строгой логичности. В релятивизме при скорости света время останавливается (поэтому в нем абсурдно говорить о частоте фотона). В релятивизме возможны такие насилия над разумом, как утверждение о взаимном превышении возраста близнецов, движущихся с субсветовой скоростью, и прочие издевательства над логикой, присущие любой религии.
4. В гравитационном релятивизме (ОТО) вопреки наблюдаемым фактам утверждается об угловом отклонении ЭМ-волн в пустом пространстве под действием гравитации. Однако астрономам известно, что свет от затменных двойных звезд не подвержен такому отклонению, а те «подтверждающие теорию Эйнштейна факты», которые якобы наблюдались А. Эддингтоном в 1919 году в отношении Солнца, являются фальсификацией. Подробнее читайте в FAQ по эфирной физике.
ИНФОЛОГИЧЕСКОЕ МОДЕЛИРОВАНИЕ
Инфологическая модель создается по результатам проведения исследований предметной области.
Инфологическая модель представляет собой описание будущей базы данных, представленное с помощью естественного языка, формул, графиков, диаграмм, таблиц и других средств, понятных как разработчикам БД, так и обычным пользователям.
Назначение такой модели состоит в адекватном описании процессов, информационных потоков, функций системы с помощью общедоступного и понятного языка, что делает возможным привлечение экспертов предметной области, консультантов, пользователей для обсуждения модели и внесения исправлений. В данном случае под созданием инфологической модели будем понимать именно ее создание для БД. В общем случае, инфологическая модель может создаваться для любой проектируемой системы и представляет ее описание (в общем случае в произвольной форме).
Создание инфологической модели является естественным продолжением исследований предметной области, но в отличие от него является представлением БД с точки зрения проектировщика (разработчика). Наглядность представления такой модели позволяет экспертам предметной области оценить ее точность и внести исправления. От правильности модели зависит успех дальнейшей разработки.
Инфологическую модель можно представить в виде словесного описания, однако наиболее наглядным является использование специальных графических нотаций, разработанных для проведения подобного рода моделирования.
Важно отметить, что создаваемая на этом этапе модель полностью не зависит от физической реализации будущей системы. В случае с БД это означает, что совершенно не важно где физически будут храниться данные: на бумаге, в памяти компьютера и кто или что эти данные будет обрабатывать. В этом случае, когда структуры данных не зависят от их физической реализации, а моделируются исходя из их смыслового назначения, моделирование называется семантическим.
Существует несколько способов описания инфологической модели, однако, в настоящее время одним из наиболее широко распространенных подходов, применяемых при инфологическом моделировании, является подход, основанный на применении диаграмм «сущность-связь» (ER – Entity Relationship). При рассмотрении последующих примеров будем использовать одну из самых распространенных в рамках ER моделей нотацию IDEF1X. Данный стандарт был разработан в 1993 г. Национальным институтом стандартизации и технологий и является федеральным стандартом обработки информации (США), описывающим семантику и синтаксис языка, правила и технологии для разработки логической модели данных.
Для построения инфологической модели важно знать элементы этой модели. Базовыми элементами модели сущность-связь являются сущности.
Сущность по форме представляет собой только некоторое реального описание объекта, точнее набор описаний его значимых признаков-атрибутов. Конкретный набор значений атрибутов объекта будет называться экземпляром сущности. 
Рис. 1. Сущность и экземпляр сущности
Как видно из рис. 1, понятие «сущность» – означает форму информации, ее смысл. Понятие «элемент сущности» – отражает содержание.
Так, без наличия описания информации (т.е. сущности) будет трудно понять содержание следующей информации
| ИВАНОВ |
| СЕРГЕЙ |
| АЛЕКСАНДРОВИЧ |
| М |
| 15.07.1945 |
| ХОЛОСТ |
| . |
Это может быть как описанием объекта «сотрудник предприятия», так и описанием объекта «покупатель», или чем-то иным.
Поэтому, процесс выделения сущностей из автоматизируемой предметной области и их описание является ключевым для создания любых структур данных.
В качестве сущности может быть выбран не только объект, но и явление, процесс, трансформация, действие.
Если автоматизируется какой-либо процесс, то необходимо указать свойства этого процесса, объекты участвующие в этом процессе.
Пример. При автоматизации процесса покупки товаров (сущность «Покупка товаров») необходимо указать:
· какой товар необходимо купить (сущность «Товар»);
· у кого его необходимо купить (сущность «Продавец»);
· другие признаки операции покупка товара, такие как «количество», «цена», «сумма» и пр.
Отсюда следует, что сущности, выделенные из предметной области могут быть связанными между собой. Одна сущность может ссылаться на другую и даже быть признаком другой сущности более высокого уровня (так, сущность «сотрудник» может быть элементом или необходимым атрибутом сущности «организация»).
Понятие «связь» между сущностями представляет собой наличие какой-либо зависимости, ассоциации между сущностями – т.е. наличие информационной или логической связи между объектами автоматизируемой предметной области.
Существует множество видов сущностей и связей между ними.
Рассмотрим понятие их более подробно:
Итак, сущность – это реальный или воображаемый объект реального мира, имеющий существенное значение для рассматриваемой предметной области, информацию о котором необходимо хранить в БД. В некоторых случаях сущностью может являться событие, процесс или явление, имеющие место в реальном мире.
Фактически каждая сущность представляет собой множество подобных индивидуальных объектов, именуемых экземплярами. Имя сущности дается по имени ее экземпляра. Каждый экземпляр сущности индивидуален и должен отличаться от других экземпляров. Это отличие выражается в наличии у каждого экземпляра сущности уникальных свойств, называемых атрибутами.
Примерами сущностей могут быть Товар, Клиент, Покупатель. Наименование товара «Кирпич» является экземпляром сущности товар. Один и тот же объект реального мира может являться экземпляром нескольких сущностей. Так Иванов И.И. может быть как клиентом, так и покупателем, а также являться сотрудником фирмы.
Согласно нотации IDEF1X сущности изображаются в виде прямоугольников, как это показано на рис. 2.
Рис. 2. Пример изображения сущностей на ER диаграмме
Процесс выделения сущностей из автоматизируемой предметной области и их описание является ключевым для создания любых структур данных.
В качестве сущности может быть выбран не только объект, но и явление, процесс, действие.
Если автоматизируется какой-либо процесс, то необходимо указать свойства этого процесса, объекты участвующие в нем.
Например, при автоматизации процесса покупки товаров необходимо указать:
· какой товар необходимо купить (сущность «Товар»);
· у кого его необходимо купить (сущность «Продавец»);
· другие признаки: «Количество», «Цена», «Сумма» и пр. (сущность «Покупка товаров»).
Отсюда следует, что сущности, выделенные из предметной области могут быть связанными между собой. Одна сущность может ссылаться на другую и даже быть признаком другой сущности более высокого уровня (так, сущности «Товар» и «Продавец» могут быть элементами или необходимыми атрибутами сущности «Покупка товаров», сущность «Сотрудник» – элементом или необходимым атрибутом сущности «Организация»).
Понятие связь между сущностями представляет собой наличие какой-либо зависимости, ассоциации между сущностями – т.е. наличие информационной или логической связи между объектами автоматизируемой предметной области.
Ключевым моментом в методологии IDEF1X является взаимосвязь или отношения в которых находятся сущности. Форма взаимодействия одной сущности с другими является важной ее характеристикой. Различают два основных вида взаимодействия. Сущность является независимой если каждый ее экземпляр может быть однозначно идентифицирован без установления связей с другой сущностью. Сущность является зависимой (дочерней), если уникальная идентификация ее экземпляров возможна только путем установления связи с другой сущностью.
Например, сущности «Отдел» и «Сотрудник» являются независимыми, если предположить, что сотрудник может работать в организации, не числясь ни в одном отделе. Примером зависимой сущности может являться сущность «Заказ» в паре сущностей «Клиент»-«Заказ». Информация о заказе не имеет смысла без информации о клиенте его разместившем.
Согласно нотации IDEF1X независимые сущности изображаются в виде обычных прямоугольников, зависимые – в виде прямоугольников со скругленными углами, как это показано на рис.38. При нанесении на ER диаграмму сущности, необходимо руководствоваться следующими требованиями:
· сущность должна иметь наименование с четким смысловым значением и именоваться существительным в единственном числе.
· сущность должна обладать уникальным в пределах модели именем, имеющим четкое смысловое значение, выраженное в виде существительного в единственном числе, которое записывается над прямоугольником;
· именование сущности обычно производится по имени ее экземпляра, а единственное число облегчает в дальнейшем чтение модели.
Рис. …. Пример изображения связей между сущностями в нотации IDEF1X
Сущность «Заказ» на рис.3 изображена в виде прямоугольника со скругленными углами, т.к. является зависимой от клиента. Зависимость эта обусловлена тем, что экземпляр сущности «Заказ» не может существовать, если не указан клиент, его разместивший. «Заказ» в свою очередь, может являться независимой по отношению к сущности «Состав заказа», содержащей информацию о наименованиях, количестве и стоимости заказанных товаров или услуг. В этом случае сущности «Заказ» и «Состав заказа» являются зависимыми и изображаются в виде прямоугольников со скругленными углами, сущность «Клиент», является независимой и изображается в виде обычного прямоугольника.
Рис. …. Изображение зависимых сущностей «Заказ» и «Состав заказа»
Таким образом, если сущность имеет несколько отношений с другими сущностями и при этом хотя бы в одном случае является зависимой, она изображается как зависимая.
Атрибут сущности – это именованная характеристика, являющаяся некоторым свойством сущности, значимым для рассматриваемой предметной области. Наименование атрибута должно быть выражено существительным в единственном числе и быть уникальным в пределах БД.
Примерами атрибутов могут являться «Номер клиента», «Имя клиента», «Номер заказа», «Дата заказа» и др. На ER диаграмме атрибуты помещаются внутри прямоугольника. В этом случае название сущности размещается за пределами прямоугольника. Ключевые атрибуты помещаются в списке атрибутов первыми и отделяются от неключевых горизонтальной линией (рис….).
Рис. …. Отображение атрибутов сущности на ER диаграмме
На этапе инфологического моделирования мы скорее имеем дело с признаками сущности.
Признак – это обобщенная характеристика сущности, позволяющая описать ее свойства не вдаваясь в подробности.
На этапе инфологического моделирования признаки выступают в роли атрибутов. На этом этапе от разработчика не требуется проводить глубокий анализ сущности с целью выяснения всех ее атрибутов и их характеристик. Достаточно просто установить, что сущность обладает определенным набором признаков, которые необходимо выделить. В дальнейшем, при создании даталогической модели, признаки трансформируются в атрибуты, или наборы атрибутов, в зависимости от их сложности.
Ключ сущности – это атрибут или набор атрибутов, значения которых однозначно идентифицируют экземпляр сущности.
При инфологическом моделировании необходимо говорить о ключевых признаках. Таким образом, для идентификации сущности необходимо выделить ключевой признак.
Ключ сущности может быть сложным (составным), состоящим из нескольких атрибутов или признаков. При этом комбинация значений атрибутов, входящих в ключ, должна быть уникальной в пределах сущности. Выбор первичного ключа является очень важной и зачастую непростой задачей, от решения которой может зависеть эффективность будущей БД. Сложность выбора обусловлена тем, что, во-первых, значение ключевого атрибута должно быть уникальным в пределах сущности, а во-вторых, в одной сущности может существовать несколько атрибутов или их наборов, подходящих на роль ключа сущности. Такие атрибуты (наборы атрибутов) называются потенциальными ключами (кандидатами). Один атрибут или набор атрибутов из числа кандидатов должен быть выбран в качестве первичного ключа. При этом он должен удовлетворять следующим требованиям:
· уникальности – два экземпляра сущности не должны иметь одинаковых значений возможного ключа;
· компактности – составной ключ не должен содержать ни одного атрибута, удаление которого не приводило бы к утрате уникальности;
· значимости – атрибут ключа не должен быть пустым;
· постоянства – значение атрибутов ключа не должно меняться в течение всего времени существования экземпляра сущности.
Если существует несколько кандидатов на роль первичного ключа, предпочтение следует отдавать более простому (содержащему меньшее количество атрибутов) ключу. Ключи, входящие в список кандидатов, но не ставшие первичными называются альтернативными ключами. На ER диаграмме такие атрибуты помечаются символами (AK) после имени атрибута.
На рис. изображена сущность «Контрагент», в качестве потенциальных ключей которой можно выделить:
1. «Код контрагента» (АК1.1);
2. «Наименование контрагента» (АК2.1) + «Телефон» (АК2.2);
3. «Город контрагента» (АК3.1)+ «Адрес контрагента» (АК3.2).
Рис. …. Альтернативные ключи сущности «Контрагент»
Если учесть очень маленькую вероятность существования двух контрагентов с одинаковыми наименованиями и телефонами или расположенных в городах с одинаковыми названиями и по одинаковым адресам, то второй и третий варианты подойдут на роль первичного ключа, однако, существует еще первый вариант, который проще по составу чем второй и третий – «Код контрагента». Это «синтетический» атрибут, т.к. не имеет прямого отношения к сущности «Контрагент», ведь не существует единого классификатора всех контрагентов, в котором каждому из них соответствует свой уникальный номер. «Код контрагента» в данном случае – это номер, присвоенный ему в пределах данной организации.
С точки зрения теории баз данных использование атрибута «Код контрагента» в качестве ключевого неправильно, так как он не в состоянии обеспечить уникальности экземпляров сущности, ведь можно ввести дважды данные об одном и том же контрагенте, присвоив им при этом разные коды. При этом сущность окажется не только избыточной, но также может произойти нарушение целостности информации в БД вследствие использования в связанных с контрагентом сущностях информации об одном и том же контрагенте, ссылаясь на него при этом по разным номерам.
Иллюстрация такого случая приведена на рис.3.7. Видно, что всего было оформлено 3 заказа Контрагентом 1. Но, так как в списке контрагентов ему соответствуют коды 1 и 3, то в одном случае заказ был оформлен Контрагентом с кодом 1, а во втором – с кодом 3. С точки зрения СУБД Контрагент 1 с кодом 1 и Контрагент 1 с кодом 3 являются разными экземплярами. Если не исправить данное положение, то со временем это приведет к серьезным трудностям в обработке информации БД, связанной с получением итоговых сведений.
Рис. 3.7 Пример нарушения целостности информации базы данных
Тем не менее, на практике, в силу особенностей реализации технологий реляционных СУБД, используется именно такой подход, при котором очень часто в качестве первичного ключа сущности используется именно суррогатный ключ (код или номер), а контроль целостности информации и избыточность остаются либо «на совести» пользователя, от которого требуется повышенное внимание при добавлении информации в БД, либо «на совести» программиста, реализующего различные блокировки.
Следующим важным понятием в методе «сущность-связь» является понятие отношения между сущностями.
Отношение (связь) – это некоторая ассоциация (логическое соотношение) между двумя сущностями, предполагающая зависимость между атрибутами этих сущностей.
Связи позволяют по одной сущности находить другие сущности, связанные с ней. Название связи обычно представляется глаголом или глагольной фразой (отглагольным существительным), которая выражает некоторое ограничение или бизнес-правило и облегчает чтение диаграммы. Изображенная на рис. связь позволяет определить какие именно заказы разместил клиент и какой именно сотрудник оформил заказ. Глагольные фразы облегчают понимание смысла связи и могут быть созданы как для прямого, так и для обратного чтения связи. Так, в примере, представленном на рис. связь между сущностями «Клиент» и «Заказ» может быть прочитана следующим образом: Клиент размещает Заказ, Заказ размещается Клиентом. Обычно достаточно создания одной глагольной фразы для чтения связи в направлении от независимой сущности к зависимой, исключением являются связи типа многие-ко-многим, при которых для лучшего понимания типа связи желательно создание двух глагольных фраз.
Пример изображения связи на ER диаграмме
На этапе инфологического моделирования используют идентифицирующие и неидентифицирующие связи. Выше было сказано о том, что существуют зависимые и независимые сущности. Тип связи между двумя сущностями определяет какая из них является зависимой (дочерней), а какая – независимой (родительской).
Идентифицирующая связь устанавливается между родительской и дочерней сущностями и означает, что каждому экземпляру дочерней сущности должен соответствовать хотя бы один экземпляр родительской. При этом дочерняя сущность не может существовать «вне рамок» родительской. На ER диаграммах идентифицирующая связь показывается в виде сплошной линии. Точка на линии ставится со стороны дочерней сущности (рис.43). Неидентифицирующая связь устанавливается между двумя независимыми сущностями и означает, что каждый экземпляр дочерней сущности может быть идентифицирован без использования экземпляра родительской сущности. На ER диаграммах неидентифицирующая связь показывается в виде пунктирной линии (рис.44).
Пусть даны две сущности «Материал» и «Единица измерения». Если предположить, что при учете материалов в БД можно не указывать единицу измерения данного материала, то сущности «Материал» и «Единица измерения» являются независимыми, а связь между ними – неидентифицирующей (рис.44).
Пример неидентифицирующей связи между сущностями
Связь между сущностями обеспечивается за счет миграции атрибутов родительской сущности в дочернюю.
Миграция – перенос атрибутов одной сущности в другую для установления связи между ними.
Мигрировавший атрибут называется внешним ключом и помечается на ER диаграмме символами (FK) (Foreign Key). Мигрировавший атрибут или группа атрибутов могут быть помещены в состав первичного ключа сущности или в состав неключевых атрибутов в зависимости от типа связи между сущностями. При этом действуют следующие правила:
· если сущности связаны идентифицирующей связью, то все ключевые атрибуты родительской сущности мигрируют в состав первичного ключа дочерней сущности (рис.40);
· если сущности связаны неидентифицирующей связью, то все ключевые атрибуты родительской сущности мигрируют в состав неключевых атрибутов дочерней сущности (рис.44).
При этом возможны два варианта отношений:
Допускаются пустые значения внешних ключей в дочерней сущности (знак ромба на неидентифицирующей связи со стороны независимой сущности).
Пустые значения внешних ключей в дочерней сущности не допускаются (отсутствие знака ромба со стороны независимой сущности).
Каждая связь, независимо от того, является ли она идентифицирующей или нет обладает мощностью.
Мощность связи (cardinality) – характеристика связи между сущностями, предназначенная для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.
Существует четыре различных типа мощности (рис.45):
1. Одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности. Не помечается дополнительным значком на диаграмме.
2. Одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение). На диаграмме помечается значком P.
3. Одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения). На диаграмме помечается значком Z.
4. Одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности. На диаграмме помечается цифрой.
Обозначение мощности в нотации IDEF1X
Существует еще одна, не вошедшая в приведенный выше перечень, мощность связи – многие-ко-многим. Такая связь возможна только на логическом уровне представления модели и означает, что каждому экземпляру родительской сущности может соответствовать несколько экземпляров дочерней, а каждому экземпляру дочерней – несколько экземпляров родительской.
В этом случае понятия «родительская» и «дочерняя» применимы к обоим связываемым сущностям. На диаграмме такая связь обозначается сплошной линией с двумя точками на концах. Обе сущности, участвующие в связи обозначаются как независимые. Пример такой связи приведен на рис.46. В данном случае, в отгрузку могут быть включены несколько товаров, в то же время один товар может участвовать в нескольких отгрузках.
Особой разновидностью связей является категориальная связь, используемая для описания структур, в которых сущность является типом (категорией) другой сущности. При этом родительская сущность (родовой предок) содержит общие свойства, присущие дочерним (категориальным) сущностям. Категориальную связь, называемую иногда иерархией наследования создают тогда, когда несколько сущностей имеют общие по смыслу атрибуты, либо когда сущности имеют общие по смыслу связи, либо когда это диктуется бизнес-правилами. Для каждой категории можно указать дискриминатор – атрибут родового предка, который показывает, как отличить одну категориальную сущность от другой.
Пример связи «многие-ко-многим»
В качестве примера рассмотрим следующий случай: допустим, известно, что при оформлении операций, связанных с перемещением товарно-материальных ценностей в организации используется два вида накладных: приходная и расходная. В данном случае сущность «Накладная» является родительской, так как объединяет общие для обеих сущностей атрибуты, а сущности «Приходная» и «Расходная» содержат информацию об особенностях накладных каждого вида. Дискриминатором в данном случае будет вид накладной (рис.47).
Категориальные связи делятся на два типа – полные и неполные. Если экземпляру родового предка соответствует экземпляр в каком-либо потомке, то связь является полной, на ER диаграмме изображается с помощью дискриминатора (рис.47). Если категория еще не выстроена полностью и в родовом предке есть экземпляры, для которых нет соответствующих экземпляров в потомках, категория является неполной, на ER диаграмме изображается с помощью дискриминатора (рис.47). Возможны иерархии наследования, в которых присутствуют и полные и неполные категории. При этом сущности, в одном случае являющиеся потомками, могут одновременно являться предками по отношению к другим связям.
В примере, изображенном на рис.47 первая категориальная связь (вид накладной) является полной, т.к. существует только два вида накладных: приходная и расходная. Тип расходной накладной является неполной категориальной связью, т.к. предполагается, что сюда включены еще не все сущности данной категории (например отгрузка материалов на сторону или списание материалов). Отсутствие сущности на диаграмме может быть обусловлено тем, что еще не выявлено ее существование в рамках данной модели, не установлен ее тип или ее существование внутри модели нежелательно.
Пример полной и неполной категориальной связи
