Модели данных типа сущность связь. Основные понятия модели «сущность — связь. Моделирование методом "сущность-связь"

Модель была предложена Петером Пин-Шен Ченом в 1976 г. На использовании разновидностей ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в CASE-системах, поддерживающих автоматизированное проектирование реляционных баз данных. Базовыми понятиями ER-модели являются сущность, связь и атрибут.

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

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

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

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

На рис.12 приведен пример изображения сущностей и связи между ними.

Рис. 12.

Данная диаграмма может быть интерпретирована следующим образом: Каждый СТУДЕНТ учится только в одной ГРУППЕ; Любая ГРУППА состоит из одного или более СТУДЕНТОВ. На следующем рисунке (рис.13) изображена сущность ЧЕЛОВЕК с рекурсивной связью, связывающей ее с ней же самой.

Рис.13.

Лаконичной устной трактовкой изображенной диаграммы является следующая:

Каждый ЧЕЛОВЕК является сыном одного и только одного ЧЕЛОВЕКА;

Каждый ЧЕЛОВЕК может являться отцом для одного или более ЛЮДЕЙ ("ЧЕЛОВЕК").

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

Рис. 14.

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

Как и в реляционных схемах баз данных, в ER-схемах вводится понятие нормальных форм, причем их смысл очень близко соответствует смыслу реляционных нормальных форм. Заметим, что формулировки нормальных форм ER-схем делают более понятным смысл нормализации реляционных схем. Мы рассмотрим только очень краткие и неформальные определения трех первых нормальных форм.

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

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

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

Подтипы и супертипы сущностей. ER-модель позволяет задавать отношение IS-A между типами. При этом если Т 1 IS-A Т 2 (где Т 1 и T 2 - типы сущностей), то Т 1 называется подтипом Т 2 а Т 2- супертипом Т 1. Т.о., существует возможность наследования типа сущности, исходя из одного или нескольких супертипов.

Связи "многие-со-многими". Иногда бывает необходимо связывать сущности таким образом, что с обоих концов связи могут присутствовать несколько экземпляров сущности (например, все члены кооператива сообща владеют имуществом кооператива). Для этого вводится разновидность связи "многие-со-многими".

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

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

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

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

Элементы модели «сущность-связь» Сущность - Класс сущностей - Экземпляр сущности Атрибуты - Композитные атрибуты - Многозначные атрибуты Идентификаторы - Уникальные/неуникальные - Композитные Связи - Классы связей - Экземпляры связей - Рекурсивные связи

Элементы модели «сущность-связь» Класс сущностей (entity classes) – это совокупность сущностей, описывается структурой или форматом сущностей, составляющих этот класс. Экземпляр сущности (аn instance) представляет конкретную сущность Обычно класс сущностей держит множество экземпляров сущности.

Элементы модели «сущность-связь» Атрибуты Атрибуты (свойства) – описывают характеристики сущности. Пример композитного атрибута: Адрес, состоящий из группы атрибутов {Улица, Город, Индекс}. Пример многозначного атрибута: атрибут Имя студента сущности ПРЕПОДАВАТЕЛЬ, который может содержать имена нескольких обучаемых им студентов.

Элементы модели «сущность-связь» Идентификаторы Идентификаторы (identifiers) – атрибуты, с помощью которых экземпляры сущностей именуются, или идентифицируются. Если идентификатор является уникальным, его значение будет указывать на один и только один экземпляр сущности. Если идентификатор является неуникальным, его значение будет указывать на некоторое множество экземпляров. Идентификаторы, состоящие из нескольких атрибутов, называются композитными идентификаторами (composite identifiers).

Элементы модели «сущность-связь» Связи Взаимоотношения сущностей выражаются связями. Классы связей (relationship classes) это взаимоотношения между классами сущностей. Экземпляры связи (relationship instances) взаимоотношения между экземпля­рами сущностей Степень связи (relationship degree) число классов сущностей, участвующих в связи. Обозначение средствами в UML-диаграммах: Связь обозначается

Элементы модели «сущность-связь» Три типа бинарных связей Обозначение средствами в UML- диаграммах: Связь 1:1(«один к одному») обозначается Связь 1:N («один к N» или «один ко многим») – Связь N:M (читается «N к М» или «многие ко многим») – Связь обладания в обобщенном виде, когда не указан конкретный тип связи - Числа внутри ромба, символизирующего связь, обозначают максимальное количество сущностей на каждой стороне связи. Эти ограничения называются максимальными кардинальными числами, а совокупность из двух таких ограничений для обеих сторон связи называется максимальной кардинальностью (maximum cardinality) связи.

Диаграммы «сущность-связь» Схемы бинарных связей, изображенных выше, называются диаграммами «сущность-связь», или ER-диаграммами (entity-relationship diagrams, ER-diagrams). Для указания минимальной кардинальности (minimum cardinality) существует несколько способов. Один из них, продемонстрирован ниже. Связь с указанной минимальной кардинальностью

Слабые сущности Слабые сущности (weak entity) - сущности, которые могут существовать в базе данных только в том случае, если в ней присутствует сущность некоторого другого типа. Сущность, не являющаяся слабой, называется сильной сущностью (strong entity). Идентификационно-зависимые сущности (ID-dependent entities) - это такие сущности, идентификаторы которых содержат идентификатор другой сущности.

27

Диаграммы «сущность-связь» в стиле UML Конструкции ООП, введенные языком UML Классы всех сущностей, которые должны храниться в базе данных, помечаются стереотипом «Persistent» (устойчивый) UML допускает назначение атрибутов классам сущностей UML использует объектно-ориентированную нотацию для обозначения видимости атрибутов и методов «+» - открытые «#» - защищенными «-» - закрытыми

Диаграммы «сущность-связь» в стиле UML Открытым (public) называется такой атрибут, который может читаться и изменяться любым методом любого объекта. Термин защищенный (protected) означает, что атрибут или метод доступен только для методов данного класса и его подклассов. А термин закрытый (private) указывает на то, что соответствующий атрибут или метод доступен только для методов данного класса. В UML задаются ограничения и методы.

Модель сущность–атрибут–связь была предложена Петером Пин-Шен Ченов в 1976 г. На использовании разновидностей ER модели основано большинство современных подходов к проектированию баз данных (главным образом реляционных). Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое количество разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в CASE системах, поддерживающих автоматизированное проектирование реляционных баз данных.

Базовыми понятиями ER-модели являются сущность, атрибут и связь.

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

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

Связь представляется в виде линии, связывающей две сущности или ведущей от сущности к ней же самой. При этом в месте “стыковки” связи с сущностью используются трехточечный вход в прямоугольник сущности, если для этой сущности в связи могут использоваться много экземпляров сущности, и одноточечный вход, если в связи может участвовать только один экземпляр сущности. Обязательный конец связи изображается сплош­ной линией, а необязательный – прерывистой линией.

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

Каждый СТУДЕНТ учится только в одной ГРУППЕ;

Любая ГРУППА состоит из одного или более СТУДЕНТОВ.

Рис. 1. Связь между сущностями

На рис. 2 изображена сущность ЧЕЛОВЕК с рекурсив­ной связью, связывающей ее с ней же самой. Лаконичной устной трактовкой изображенной диаграммы является следующая:

Каждый ЧЕЛОВЕК является сыном одного и только одного ЧЕЛО­ВЕКА;

Каждый ЧЕЛОВЕК может являться отцом для одного или более ЛЮ­ДЕЙ (“ЧЕЛОВЕКОВ”).

Рис. 2. Рекурсивная связь

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

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

Связи “многие-со-многими”. Иногда бывает необходимо связывать сущ­ности таким образом, что с обоих концов связи могут присутствовать не­сколько экземпляров сущности (например, все члены кооператива сообща владеют имуществом кооператива). Для этого вводится разновидность связи “многие-со-многими”.

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

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

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

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

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

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

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

Во втором подходе реализуется автоматизированная компиляция кон­цептуальной модели предметной области в схему БД (чаще всего реляци­онную). Известны два типа подхода:

подход, основанный на явном представлении концептуальной мо­дели предметной области как исходной информации для компиля­ции;

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

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

Наконец, третий подход – это непосредственная работа с базой данных в семантической модели, т.е. применение СУБД, основанных на семанти­ческих моделях данных. При этом снова рассматриваются два варианта.

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

Второй вариант – прямая реализация СУБД, основанная на какой-либо семантичес­кой модели данных.

Наиболее близко ко второму варианту находятся современные объект­но-ориентированные СУБД, модели данных которых по многим парамет­рам близки к семантическим моделям (хотя в некоторых аспектах они бо­лее мощны, а в некоторых – более слабы). Хотя в целом можно сказать, что этот подход еще не вышел за пределы исследовательских и экспери­ментальных проектов.

В настоящее время на рынке программного обеспечения появилось до­статочно много универсальных (не привязанных к какой-либо конкретной СУБД) пакетов автоматизированного проектирования БД, позволяющих производить концептуальное моделирование предметной области. В ос­нове практически всех систем такого рода лежит та или иная интерпрета­ция ER-модели. Такие системы являются реализацией второго из рассмот­ренных выше подходов. Одним из наиболее популярных программных продуктов в этой области является ERwin компании Platinum.

Модели данных

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

Самый простой тип – это список – структура данных в виде линейной последовательности.

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

Рис. 3. Иерархическая древовидная структура БД

Основными внутренними ограничениями иерархической модели данных являются следующие:

– все типы связей должны быть функциональными, т.е. 1:1, 1:М, М:1;

– структура связей должна быть древовидной.

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

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

Корневое дерево как ориентированный граф можно определить следующим образом:

– имеется единственная особая вершина, называемая корнем, в которую не заходит ни одно ребро;

– во все остальные вершины заходит только одно ребро, а ис­ходит произвольное количество ребер;

– нет циклов.

Иерархическая древовидная структура, ориен­тированная от корня, удовлетворяет следующим условиям:

– иерархия всегда начинается с корневого узла;

– на первом уровне иерархии может находиться только корне­вой узел;

– на нижних уровнях находятся порожденные (зависимые) узлы;

– каждый порожденный узел, находящийся на уровне L, свя­зан только с одним непосредственно исходным узлом (непосредст­венно родительским узлом), находящимся на более верхнем (L – 1)-м уровне иерархии дерева;

– каждый исходный узел может иметь один или несколько не­посредственно порожденных узлов, называемых подобными;

– доступ к каждому порожденному узлу выполняется через его непосредственно исходный узел;

– существует единственный иерархический путь доступа к узлу начиная от корня дерева (рис. 4).

Рис. 4. Иерархический путь доступа к узлу

Другими словами, иерархическая модель представления знаний (или дерево) – структура данных, в которой каждый узел имеет только одного “родителя”, т.е. господствующий узел (кроме самого верхнего узла) и неограниченное количество “потомков”, т.е. узлов, над которыми данный узел господствует.

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

Рис. 5. Сетевая структура

В 70-х годах начали активно проводиться теоретические иссле­дования реляционной модели данных. С появлением персональных ЭВМ реляци­онные модели стали доминировать на рынке информационных систем. Реляционное представление знаний – представление знаний в виде отношений.

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

Логическое проектирование

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

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

1. Удаление связей типа M :N .

2. Удаление сложных связей.

3. Удаление рекурсивных связей.

4. Удаление связей с атрибутами.

5. Удаление множественных атрибутов.

6. Перепроверка связей типа 1:1.

7. Удаление избыточных связей.

1. Удаление связей типа M:N. Если в концептуальной модели присутствуют связи типа M :N (“многие-ко-мно­гим”), то их следует устранить путем определения некоторой промежуточной сущно­сти. Связь типа M :N заменяется двумя связями типа 1:М , устанав­ливаемыми со вновь созданной сущностью.

В качестве примера рассмотрим следующую M :N связь: газета печатает объявления об объектах, сдаваемых в аренду (рис. 6)

Рис. 6. M:N связь

С целью устранения этой связи мы определяем промежуточную сущность ОБЪЯВЛЕНИЕ и создаем две новые связи типа 1:М . В результате связь типа M :N будет заме­нена двумя связями (рис. 7).

Рис. 7. Связи типа 1: M

2. Удаление сложных связей. Сложной называется связь, существующая между тремя и больше типами сущно­стей. Если в концептуальной модели присутствует сложная связь, ее следует устранить с помощью промежуточной сущности. Сложная связь заменяет­ся необходимым количеством бинарных связей типа 1:М , устанавливаемых со вновь созданной сущностью. Например, тройная связь “Сдается внаем” (изображается ромбом) отражает от­ношения, существующие между оформляющим аренду работником компании, зе­мельным участком и арендатором (рис. 8).

Рис. 8. Сложная связь

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

В нашем примере связь “Сдается внаем” можно устранить посредством введения новой слабой сущности с именем Соглашение. Вновь созданная сущность будет связана с исходными сущностями тремя новыми бинарными связями (рис. 9).

Рис. 9. Упрощение сложной связи

3. Удаление рекурсивных связей. Рекурсивными называются такие связи, в которых сущность некоторого типа взаимодействует сама с собой. Если концептуальная модель содержит рекурсивные связи, они должны быть устранены посредством определения неко­торой промежуточной сущности. Например, для отображения ситуации, когда один из работников руководит группой других работников, может быть установлена ре­курсивная связь типа “один-ко-многим” (1:М ).

4. Удаление связей с атрибутами. Если в концептуальной модели присутствуют связи, имеющие собственные атри­буты, они должны быть преобразованы путем создания новой сущности. Например, рассмотрим ситуацию, когда требуется фиксировать количест­во рабочих часов, отработанных временным персоналом каждого из отделений пред­приятия. Связь “Работает в” имеет атрибут с именем “Отработано часов”. Преобразуем связь “Работает в” в сущность с именем “Распределение по отделам”, которой назначим атрибут “Отработано часов”, после чего создадим две новых связи типа 1:М .

5. Удаление множественных атрибутов. Множественными называют атрибуты, которые могут иметь одновременно не­сколько значений для одного и того же экземпляра сущности. Если в концептуальной модели присутствует множественный атрибут, его следует преоб­разовать путем определения новой сущности. Например, для отображения ситуации, когда одно и то же отделение компании имеет несколько телефонных номеров, в концептуальной модели был определен множественный атрибут “Телефонный номер”, относящийся к сущности “Отделение компании”. Этот множественный атрибут сле­дует удалить, определив новую сущность “Телефон”, имеющую единственный простой атрибут “Телефонный номер”, и создав новую связь типа 1.

6. Перепроверка связей типа 1:1. В процессе определения сущностей могли быть созданы две различные сущности, которые на самом деле представляют один и тот же объект в предметной области приложения. Например, могли быть созданы две сущности “Отдел” и “Департамент”, ко­торые на самом деле представляют один и тот же тип объекта. Другими словами, имя “Отдел” является синонимом имени “Департамент”. В подобном случае следует объе­динить эти две сущности в одну. Если первичные ключи объединяемых сущностей различны, выберите один из них в качестве первичного, а другой укажите как аль­тернативный ключ.

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

При устранении избыточности доступа большое значение имеют временные пока­затели. Например, рассмотрим ситуацию, когда необходимо смоделировать связи между сущностями “Мужчина”, “Женщина” и “Ребенок”. Очевидно, что между сущностями “Мужчина” и “Ребенок” имеется два пути доступа: один – через непосредственную связь “ Является отцом” и другой – через связи “ Женат на” и “Является матерью”. На первый взгляд кажет­ся, что связь “ Является отцом” избыточна. Однако это утверждение может оказать­ся ошибочным по двум причинам. Во-первых, отец может иметь детей от предыду­щего брака, а мы моделируем только текущий брак отца (через связь 1:1). Во-вторых, отец и мать могут быть вообще не женаты или отец может быть женат на женщине, которая не является матерью данного ребенка (или же мать может быть замужем за мужчиной, который не является отцом ребенка). Поэтому все сущест­вующие взаимоотношения не могут быть смоделированы без использования связи типа “Является отцом” (рис. 10).

Рис. 10. Связь между сущностями “Мужчина”, “Женщина”, “Ребенок”

Похожая информация.

Физическая модель (Табличная) данных содержит определения всех реализуемых объектов в конкретной базе данных для конкретной СУБД.

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

В прошлой лекции мы познакомились с методологиями IDEF0 и DFD которые позволяют описать бизнес-процессы протекающие в информационной системе. В модели DFD мы рассмотрели элемент - хранилище данных, который показывает типы информации, которой оперирует система. Однако эта методология не предназначена для описания структуры хранимой информации. Для этого больше подходят различные Entity Relationship - диаграммы (сущностные диаграммы), целью которых является описание структуры хранимых данных и взаимосвязей между ними. Разработаны методики, которые позволяют преобразовать такие данные в набор команд, который создаст необходимые хранилища (таблицы) внутри базы данных информационной системы.

ER-моделирование

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

Основные преимущества ER-моделей:

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

Основные типы объектов на ER-диаграмме:

• Сущность (Entity) - тип объектов, информация о которых будет хранится в БД. Например: отделы, сотрудники, товары, накладные.
• Атрибут (Attribute) - элементы из которых состоят сущности. Например, для сущности «товары» атрибутами могут быть «название», «описание», «количество», «цена» и другие, в зависимости от потребностей информационной системы. В зависимости от нотации ER-диаграммы рядом с атрибутом, кроме его имени указывают тип и обязательность заполнения. На слайде представлена ER-диаграмма в нотации «Information Engineering», согласно которой для атрибута указывается имя, тип, и является он внешним и/или первичным кличем.
• Связь (Relationship) показывают связи между сущностями. Например сотрудник работает в отделе, где «отдел» и «отдел» - сущности.

Сущность - набор объектов реального мира, каждый из которых имеет следующие характеристики:

• Уникален (может быть отделен от всех прочих каким-либо образом)
• Играет определенную роль в моделируемой системе
• Может быть описан одним или более элементом информации (Атрибутом)

Пример: люди, персонал, события, заказы, продажи, покупатели, поставщики

Атрибут описывает некоторые свойства сущности. Сущность может иметь много атрибутов, но выбираются только те, которые важны для системы. Атрибуты делятся на ключевые (Entity Keys) и описательные (Entity Descriptors). Ключевые атрибуты должны уникальным образом идентифицировать экземпляры сущности. Для каждого атрибута должен быть указан домен (тип, предметная область).

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

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

Базовые термины

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

• " Тип данных " (type, domean - домен) - множество допустимых величин ("область определения") и операций. Для всех типов существуют операции сравнения и присвоения. Величинам не запрещено иметь структуру, например, объекта.
• " Отношение " (relation) - множество атрибутов: уникальных имен с уточнением типа данных; плюс множество "наборов величин" ("рядов"), соответствующих атрибутам. Величины в наборах могут быть представлены только единичными значениями соответствующих атрибутам типов, то есть быть скалярами ("1-я нормальная форма").
• " Ключ " (key) - группа атрибутов, значения которых во всех наборах в отношении различны, но ни одна подгруппа этих атрибутов таким свойством уже не обладает (свойство "минимальности" ключа). В частности, группа может состоять из единственного атрибута. Ключ в отношении обязан иметься всегда, а если их несколько, один из них обязан быть назначен "первичным" (primary).
• " Внешний ключ " (foreign key) - группа атрибутов, значения которых в каждом наборе величин отношения обязаны совпадать со значениями ключа возможно другого отношения. Внешние ключи в отношении не обязательны и провозглашаются по потребностям моделирования.
• " Операции " (operation) - множество общих действий над отношениями, дающих в результате опять-таки отношения ("замкнутость операций"). Используются для получения новых отношений в нуждах последующего моделирования или при извлечении из базы нужных данных. Перечень операций можно определять по-разному; в первых предложениях модели приводилось восемь операций (проекции, соединения, отбора и пр.), уже не минимальный набор, как компромисс между отсутствием избыточности и удобством употребления.
• " Реляционная база данных " (relational database) - набор отношений.

"Тип данных" иногда называют "доменом" (domain), но иногда под "доменом" разумеют только "область определения" величин. "Набор величин" (tuple) по-русски иначе называют "кортежем" или "n-кой".

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

Если отказаться от определительного слова-кальки "реляционный", то термин "реляционная БД" можно перевести как "БД отношений" (точнее, "БД построенная посредством отношений"; отношений как инструмента, а не объекта моделирования: иначе исходный термин был бы relation database). Точно так же термин "реляционная модель" можно перевести как "модель отношений", то есть "система понятий для построения модели предметной области в виде набора отношений". По ряду причин, в том числе исторического и языкового характеров, этого не было в свое время сделано.

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

Приведенный взгляд на реляционную БД (набор отношений и операции) характерен для реляционной алгебры . Это не единственная точка зрения. Каждый набор величин в переменной отношения можно понимать как истинное высказывание ("предикат"): имеется такой-то сотрудник с такими-то свойствами; такой-то отдел и так далее. Тем самым реляционная база данных в каждый момент времени представляет собой набор истинных высказываний о предметной области, сформулированный через отношения. По сути, набор высказываний в переменных отношений и образует модель предметной области, представленную базой данных. Такой взгляд на реляционную БД характерен для реляционного исчисления . Оба взгляда на реляционную модель хорошо изучены и доказана их выразительная равносильность.

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

• Отношение → Таблица
• Кортеж → Строка, запись
• Кардинальность → Количество строк
• Атрибут → Столбец, поле
• Степень → Количество столбцов
• Первичный ключ → Идентификатор
• Домен → Область допустимых значений

Ключевые поля

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

• Простой ключ - состоит из одного атрибута, составной - из нескольких.
• Потенциальный ключ - атрибут или набор атрибутов, которые могут идентифицировать каждый из кортежей отношения. Например в отношении паспортный стол («Номер паспорта») и («ФИО» и «Дата рождения») - потенциальные ключи, которые позволяют уникальным образом идентифицировать каждого человека.
• В каждом отношении может быть только один первичный ключ - атрибут или набор атрибутов значения которого уникальным образом идентифицирую каждую запись. Если такими свойствами обладают несколько наборов атрибутов, то один из них выбирается первичным, а все остальные - альтернативными.
• Внешний ключ - хранит значение первичного ключа другого отношения. Внешние ключи используются для связи между отношениями.

Первичный ключ

• Каждое реляционное отношение имеет только 1 первичный ключ , все остальные - альтернативные.
• Значение всех атрибутов первичного ключа не может быть не определено. Например, отношение хранит информацию о жителях города. Первичный ключ - составной (ИМЯ, ФАМИЛИЯ, дата рождения). Информационную систему установили в Исландии, где не используют фамилий, значит атрибут «фамилия» для большинства кортежей будет незаполненным. Несмотря на это составной первичный ключ будет продолжат уникальным образом идентифицировать каждый из кортежей. Однако недопустимо, чтобы значения одновременно всех атрибутов первичного ключа были пустыми.
• Значение первичного ключа не влияет на расположение кортежей в табличном представлении отношения. Даже если значение первичного ключа - число (например 1,2,3 …) в общем случае это не гарантирует, что кортежи внутри БД хранятся в том же порядке и будут выводится в таком же порядке. В «общем случае» означает, что иногда из-за специфики конкретной СУБД строки могут хранится упорядочено по первичному ключу, но это скорее исключение. В случае вывода результатов запроса мы должны явно указывать порядок, в котором нужно выводить строки, если такой порядок важен. Результаты запроса «дай мне первых 5 человек» непредсказуем, если мы не укажем, по какому критерию они должны быть «первыми».
• Первичный ключ не влияет на доступ к атрибутам кортежа. Например в отношении «паспортный стол» вместе с ФИО и датой рождения хранится адрес регистрации человека. Мы можем попросить БД извлечь все адреса, не зная ФИО и дату рождения.

Внешний ключ

Внешний ключ используется для установления связей между отношениями. Например возьмем два отношения «Владельцы» (первичный ключ «номер паспорта») и «Недвижимость». Чтобы установить, кто владеет каждым из объектов недвижимости мы свяжем эти отношения по значению атрибута «номер паспорта». В отличии от первичного ключа значение внешнего ключа может быть неопределённо (строка 4 на слайде) - если мы не знаем владельца недвижимости мы его не указываем. В отличие от первичного ключа значение внешнего ключа может повторятся (стоки 1,3 на слайде) - у одного владельца может быть несколько объектов недвижимости. Однако то что атрибут «номер паспорта» в отношении «Недвижимость» является внешним ключом на первичный ключ отношения «Владелец» гарантирует что значением атрибута «номер пастора» могут быть только значения из первичного ключа. Мы не можем указать в качестве значения атрибута номер пастората человека, которого еще нет в отношении «Владелец» (строка 5).

Устанавливая внешний ключ можно явно задать поведение СУБД, если изменить значение первичного ключа или удалить кортеж. Однако при этом сохраняется правило «во внешнем ключе хранятся только значения, которые есть в первичном ключе или неопределённое значение (NULL)».

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

ЕR-модели: связи

На ER-моделях внешние ключи отображаются в виде связей.

Каждая связь характеризуется 4 свойствами - силой , мощностью , степенью и участием сущности в связи.

Разберем эти характеристики.

Участие сущности в связи

Обозначается на связи поперечной линией или кружком.

Поперечная линия означает обязательное (mandatory ) участие сущности в связи, а кружок - необязательное (optional ).

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

В отделе может работать несколько сотрудников. Сотрудник должен работать в каком-то из отделов.

Степень связи (relationship degree ) указывает на число ассоциированных сущностей . Бинарная связь (binary relationship ) описывает ассоциации двух сущностей. Тернарная связь (ternary relationship ) имеет место, когда связываются три сущности. Унарная связь (unary relationship ) описывает ассоциации внутри единственной сущности.

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

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

Мощность может быть:

• один-к-одному (1:1) - в группе студентов один староста;
• один-ко-многим (1:N) - в одном отделе работает много сотрудников;
• многие-ко-многим (M:N) - один покупатель купил много товаров, товаров покупали много покупателей.

Сила связи : сильная связь (Identifying Relationship)

Дочерняя сущность не может существовать без родительской. (Не бывает ответа без вопроса; не бывает товара в корзине пользователя, если не существует самой корзины)

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

На диаграмме сильная связь отображается неразрывной линией между сущностями.

Сила связи: Слабая связь (Nonidentifying Relationship)

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

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

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

Рекурсивная-связь (унарная связь)

Чаще всего используется для построение иерархий.

Поставщик МОЖЕТ работать с НУЛЕМ или БОЛЕЕ заказчиков (id_Customer).

Заказчик ДОЛЖЕН работать с одним поставщиком (id_Sup).

Но поставщик и заказчик - это фирма ли организация - объекты одного типа и потому хранятся в одном отношении.

Связь многие-ко-многим.

Пример: поставщики могут поставлять много типов товаров. Разные поставщики могут поставлять одинаковые типы товаров.

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

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

ER-модели и реальность

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

Представим, что А - поставщик, B - товар.

Mandatory-mandatory. Для примера, который приведен на слайде эта связь означает, что каждый поставщик (Supplier) должен поставлять только один уникальный набор товаров (Invoice). С точки зрения теории тут все хорошо. На практике это не допустимо: ни кто не будет искать нового поставщика, если проверенный вами поставщик может предоставить несколько номенклатур товара. А теперь об эмоциях, кот будет испытывать оператор при попытке ввода данных о новом поставщике. Он не сможет ввести данные ни в одну из таблиц. Так что весь багаж неприличной лексики будет направлен в ваш адрес.

Optional-mandatory. Пример связи приведен на слайде. Как видим у оператора теперь все хорошо: данные вводить он может. У бизнеса опять проблема: он должен искать нового поставщика, даже если проверенный вами поставщик может предоставить несколько номенклатур товара. А бизнесу нужны проблемы? Нет. Он должен функционировать. Как удовлетворить бизнес? Ответ простой. При проектировании БД нужно думать о нормализации. Если Supplier - сущность, то используйте связи типа optional-mandatory (mandatory-optional) или optional-optional. Хотя чаще всего связи один-к-одному - это ошибка.

Optional-optional. Как видим у оператора опять все хорошо, а у бизнеса опять проблема. Подведем итоги для связи один-к-одному. Если сущности участвуют в связи как: - mandatory-mandatory, то такая связь не имеет права на жизнь; - optional-mandatory (mandatory-optional) или optional-optional, то сопровождение бизнеса проблематично.

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

Связь один-ко-многим mandatory-optional - это наиболее часто встречающаяся форма связи. Она предполагает, что каждое и любое вхождение сущности A может существовать только в контексте одного (и только одного) вхождения сущности B. В свою очередь, вхождения B могут существовать как в связи с вхождениями A, так и без нее.

Связь один-ко-многим optional-optional - Как A, так и B могут существовать без связи между ними.

В терминах предыдущего слайда эти диаграммы можно проиллюстрировать на следующих примерах.

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

Mandatory-mandatory. Для примера, который приведен на слайде эта связь означает, что каждый поставщик (A) должен поставлять один или более наборов товаров (B). С точки зрения теории тут все хорошо. Однако на практике оператор не сможет ввести данные ни в одну из таблиц, поскольку записи необходимо одновременно вводить в обе таблицы.

Optional-mandatory. В этом случае у оператора теперь все хорошо: данные вводить он может, а у бизнеса могут возникнуть проблемы. Дело в том, что связь optional-mandatory предполагает, что поставщик (A) должен поставлять один или более наборов товаров (B), в то время как B может принадлежать поставщику. Другими словами, товары могут существовать без поставщика, в то время как у поставщика есть товары. Т.е. возможно неконтролируемое ведение бизнеса: кто поставил товар? С кого спрашивать? А бизнесу проблемы нужны? Нет. Он должен давать прибыль. В этом случае лучше использовать mandatory-optional: поставщик может поставлять один или более наборов товаров, в то время как товар должен принадлежать поставщику. Другими словами, у товара есть поставщик, а данные о поставщиках, которые когда-то поставляли товар будут сохранены. И овцы целы и волки сыты - оператор может вводить данные и бизнесмен в кусе дел.

Optional-optional. Как видим у оператора опять все хорошо, а у бизнеса проблема - безконтрольность: Товар может существовать без поставщика и поставщик без товара.
Подведем итоги для связи один-ко-многим. Если сущности участвуют в связи как: - mandatory-mandatory, то такая связь не имеет права на жизнь, поскольку вводить записи одновременно в обе таблицы невозможно; - optional-optional, то сопровождение бизнеса проблематично.

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

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

Многие-ко-многим mandatory-optional - применяется редко. Такие связи всегда подлежат дальнейшей детализации.

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

Optional-optional один-к-одному. Для примера, который приведен на слайде эта связь означает, что любой мужчина (женщина) может состоять в браке с одной женщиной (мужчиной). Эта связь удобна для отслеживания истории брачующихся: впервые, повторно, ... Другими словами, связь альтернативного типа.

Optional-optional один-ко-многим. Пример связи приведен на слайде. Это классическая иерархия (древовидная структура). Связь, приведенную на слайде можно интерпретировать, например, так: любой сотрудник может быть подчинен только одному менеджеру, в то время как менеджер может руководить одним или многими сотрудниками.

Optional-optional М:М Пример связи приведен на слайде 3. Это сетевая структура.

Контрольный список вопросов к сущностям

• Отражает ли имя сущности суть данного объекта?
• Нет ли пересечения с другими сущностями?
• Имеются ли хотя бы два атрибута?
• Всего атрибутов не более восьми?
• Есть ли синонимы/омонимы данной сущности?
• Сущность определена полностью?
• Есть ли уникальный идентификатор?
• Имеется ли хотя бы одна связь?
• Существует ли хотя бы одна функция по созданию, поиску, корректировке, удалению, архивированию и использованию значения сущности?
• Ведется ли история изменений?
• Имеет ли место соответствие принципам нормализации данных?
• Нет ли такой же сущности в другой прикладной системе, возможно, под другим именем?
• Не имеет ли сущность слишком общий смысл?
• Достаточен ли уровень обобщения, воплощенный в ней?

Контрольный список вопросов к атрибутам:

• Является ли наименование атрибута существительным единственного числа, отражающим суть обозначаемого атрибутом свойства?
• Не включает ли в себя наименование атрибута имя сущности (этого быть не должно)?
• Имеет ли атрибут только одно значение в каждый момент времени?
• Отсутствуют ли повторяющиеся значения (или группы)?
• Описаны ли формат, длина, допустимые значения, алгоритм получения и т.п.?
• Не может ли этот атрибут быть пропущенной сущностью, которая пригодилась бы для другой прикладной системы (уже существующей или предполагаемой)?
• Не может ли он быть пропущенной связью?
• Нет ли где-нибудь ссылки на атрибут как на "особенность проекта", которая при переходе на прикладной уровень должна исчезнуть?
• Есть ли необходимость в истории изменений?
• Зависит ли его значение только от данной сущности?
• Если значение атрибута является обязательным, всегда ли оно известно?
• Есть ли необходимость в создании домена для этого и ему подобных атрибутов?
• Зависит ли его значение только от какой-то части уникального идентификатора?
• Зависит ли его значение от значений некоторых атрибутов, не включенных в уникальный идентификатор?

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

Наиболее часто формализация представлений о предметной области осуществляется в рамках модели «сущности-связи» («объекты-связи»). На данном этапе проектирования используется метод «сущность – связь», который называют также методом «ER-диаграмм» (“Essence” – сущность, “Relation” – связь). Этот метод основан на использовании диаграмм, называемых соответственно диаграммами ER-экземпляров и диаграммами ER-типа.

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

Основными понятиями метода сущность – связь являются следующие:

Сущность;

Атрибут сущности;

Ключ сущности;

Связь между сущностями;

Степень связи;

Класс принадлежности экземпляров сущности;

Диаграммы ER-экземпляров;

Диаграммы ER-типа.

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

Атрибут ((от лат. attribuo – приписываю) – свойство или вещь, неотделимые от предмета) представляет собой логически неделимый элемент структуры информации, характеризующийся множеством атомарных значений. Это понятие аналогично понятию «атрибут» в отношении. Экземпляр объекта характеризуется совокупностью конкретных значений атрибутов данного типа объекта. Один или некоторая группа атрибутов объекта данного типа могут исполнять роль ключевого атрибута (ключа сущности). В данном курсовом проекте вышеуказанные сущности характеризуются атрибутами, такими, как: код_факультета, название_факультета, код_кафедры, ФИО_сотрудника и т. д.

Ключ сущности – это атрибут или набор атрибутов, идентифицирующих экземпляр сущности (например, код_должности).

Связь двух или более сущностей – это зависимость между атрибутами этих сущностей. Оно обозначается глаголом. Причем связи бывают двух типов:

Иерархические;

Одноуровневые.

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

Классификация связей

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

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

Между таблицами могут устанавливаться:

Бинарные связи;

Тернарные связи;

N-арные связи.

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

1:1 (один к одному);

1:М (один ко многим);

М:1 (многие к одному);

М:М (многие ко многим).

Связь вида 1:1 образуется, если все поля связи родительской и дочерней таблиц являются ключевыми. Поскольку значения в ключевых полях двух таблиц не повторяются, обеспечивается взаимно-однозначное соответствие записей из этих таблиц. Сами таблицы, по сути, здесь становятся равноправными.

Связь вида 1:М имеет место в случае, когда одной записи родительской таблицы соответствует несколько записей дочерней таблицы.

Связь М:1 имеет место в случае, когда одной ил нескольким записям основной таблицы ставится в соответствие одна запись дополнительной таблицы.

Связь М:М возникает в случаях, когда нескольким записям основной таблицы соответствует несколько записей дополнительной таблицы.

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

В данном курсовом проекте таблицы связаны связями вида 1:М (один ко многим). Например, таблица «факультеты» является родительской таблицей по отношению к дочерней таблице «кафедры». Эти таблицы связаны отношением 1:М с помощью ключа «код­_факультета»