• База данных модель сущность - связь. Модель «сущность — связь

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

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

    2.1 Семантические модели и когнитивный аспект

    2.1.1 Семантические модели данных

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

    Но если в базе хранятся только данные, то, как же хранятся смыслы? Прежде всего, смыслы -это тоже данные, связанные с теми данными, смысл которых они представляют.

    Выделим следующие виды смыслов:

    • Смыслы, предназначенные только для человека. Могут хранится в информационных системах (ИС), но пассивны, то есть недоступны системе, и потому не влияют на ее поведение. Извлекаются только человеком
    • Смыслы, внутренние для ИС. Они активны, то есть изменяют или создают новое поведение ИС. Типичные примеры: ключи, типы данных, метаданные.
    • Смыслы внешние, связанные с системами или задачами, внешними по отношению к ИС, или, более узко, к базе данных. Эти смыслы также активны.

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

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

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

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

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

    Детально семантика данных будет рассмотрена в лекции "Семантика баз данных" учебника.

    Самая известная семантическая модель "сущность-связь" ("entity-rela-tionship" - ER) была предложена Питером Пин Шен Ченом (Peter Chen) в 1976 году.

    2.1.2 Когнитивный аспект

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

    2.1.3 Уровни модели

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

    1. Информация об объектах и связях предметной области (ПО), излагаемая в терминах ПО (концептуальная модель).
    2. Структурированная информация о ПО, излагаемая в терминах информационных систем (логическая модель).
    3. Структуры данных, не зависящие от способа доступа, то есть не связанные со структурами данных, поиском, индексацией и т. д. (физическая модель).
    4. Структуры данных, зависящие от способа доступа (модель аппаратного уровня).

    Забегая вперед, заметим, что реляционная модель относится к уровням 2 и 3. Сетевая и иерархическая модели, в том виде как они существовали 20 лет назад, работают в основном на уровне 3 и 4. UML -это уровни 1, 2 и 3, но UML далеко выходит за рамки описания данных. Модель "сущность-связь" работает на уровнях 1 и 2.

    Модель данных «сущность-связь»

    Модель данных «сущность-связь» ввел в 1976 г. П. П. Чен. Она имеет много общего с иерархической и сетевой моделями данных и в силу своей ориентации на процесс проектирования может рассматриваться как обобщение и развитие ранее рассмотренных моделей. Описываемая модель допускает непосредственное представле­ние связей типа М: N.

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

    Каждая сущность принадлежит к некоторому классу или ему соответствует некоторый тип. Между сущностями имеются связи, за которыми пользователь закрепляет какой-то класс (тип). Таким образом, класс сущностей и класс связей определяют множества конкретных объектов и связей между ними. Заметим, что некоторая сущность может принадлежать более чем к одному классу (например, поставщик может одновременно быть и потребителем). В каждый момент времени состояние связи S между классами сущностей E 1 , Е 2 ..., Е n определяется отношением между множествами DOM E 1 , DOM E 2 , ..., DOM Е n , где DOM Е i , i = - множество объектов типа Е i .

    Множество связей в модели «сущность - связь» можно представить в виде математического отношения п классов объектов:

    где е i - сущность, принадлежащая множеству сущностей Е i , кортеж <e 1 e 2 ... е п > - связь из множества связей R. Необязательно, чтобы все E i , на которых определено R, были различными. Совокупность сущностей и классов связей образует верхний уровень модели.

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

    Графически модель «cущность - связь» представляется в виде схемы, в которой каждому классу объектов соответствует прямоугольник, а классу связей - шестиугольник (рис. 2.7). Под прямоугольником и шестиугольником указываются имена атрибутов сущностей и связей.

    Рис. 2.7. Графическое представление модели «сущность-связь»:

    а) класс сущностей; б) класс связей;

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

    На связи накладываются следующие ограничения:

    типы связей между классами задаются парами (1:1, 1: N, N: 1, М: N). Когда значения М и N уточнены, берется максимальное значение;

    одна связь может относиться ко многим сущностям и одна сущность может иметь много связей. В случае связей типа 1:1, 1: N, N: 1 не всегда нужно указывать имя связи.

    Рассмотрим пример представления концептуальной схемы БД с помощью модели «сущность-связь» (рис. 2.8). Пусть имеются следующие приложения: управление поставками, складом, производством и договорами. Эти приложения могут использовать такие классы сущностей: ПОСТАВЩИК (поставщики), БАЗ-ДЕТ (базовые детали), ИЗД-УЗЕЛ (изделия и узлы), ДОГОВОР (договоры), СЛУЖАЩИЙ (служащие), ОТДЕЛ (отделы).

    Рис. 2.8. Пример схемы модели «сущность-связь»

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

    ВЫБРАТЬ - позволяет выбрать поставщика базового продукта в зависимости от условий продажи и поставки (эти условия задаются на схеме);

    СБОРКА-БД - указывает базовые детали (материалы), которые непосредственно используются для производства изделия или узла, а также их число;

    СБОРКА-УЗЕЛ - указывает узлы, непосредственно входящие в другие узлы или изделия, а также их число;

    ПОСТ-БАЗ - связывает в договоре поставщиков с базовыми деталями;

    НАЗНАЧИТЬ - характеризует в договоре изделия и узлы;

    ОТВЕЧАЕТ - указывает ответственного за договор;

    УЧАСТВУЕТ - связывает договор и людей, которые участвуют в его реализации;

    РАБОТАЕТ - связывает отдел и людей, которые в нем работают;

    РУКОВОДИТ - указывает руководителя данного отдела.

    Схема модели «сущность-связь» может быть описана в виде, представленном на рис. 2.8.

    Классы сущностей:

    E1/ПОСТАВЩИК [НОМ-ПОСТ, ФАМ-ПОСТ, АДРЕС];

    Е2/БАЗ-ДЕТ [НОМ-БДЗ-ДЕТ, НАИМ-БАЗ-ДЕТ, КОЛИЧ-НА-СКЛАДЕ, МИНИМ-КОЛИЧ];

    Е3/ДОГОВОР [НОМ-ДОГ, ДАТА];

    Классы связей:

    L 1/ПОСТ-БАЗ L2 /ВЫБРАТЬ L3 /СБОРКА-БД

    [ПОСТАВЩИК, БАЗ-ДЕТ, ДОГОВОР];

    [ПОСТАВЩИК, БАЗ-ДЕТ: ЦЕНА, СРОК-ПОСТ];

    [БАЗ-ДЕТ, ИЗД-УЗЕЛ: КОЛИЧ-БД];

    Имена атрибутов связей отделяются двоеточием от имен классов сущностей.

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

    1. Связь может относиться к нескольким классам сущностей, например, связь ПОСТ-БАЗ соединяет классы сущностей ПОСТАВЩИК, БАЗ-ДЕТ, ДОГОВОР.

    2. Связь может многократно относиться к одному классу сущностей, например связь СБОРКА-УЗЕЛ.

    3. Многие связи могут относиться к одному классу сущностей, например связи РАБОТАЕТ и РУКОВОДИТ между сущностями СЛУЖАЩИЙ и ОТДЕЛ.

    4. Модель отображает различные связи типа 1:1, 1: N , М: N.

    5. Наличие двух классов сущностей для деталей БАЗ-ДЕТ и ИЗД-УЗЕЛ позволяет управлять: поставками деталей и находить поставщиков, опираясь на класс БАЗ-ДЕТ; процессом производства изделий, используя класс ИЗД-УЗЕЛ.

    6. Два класса сущностей БАЗ-ДЕТ и ИЗД-УЗЕЛ имеют общие и специфические для них атрибуты. Наличие общих атрибутов приводит к некоторой избыточности данных. Специфические атрибуты требуются областью применения объектов.

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

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

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

    Рис. 2.9. Схема прямой и обратной связей

    Например, в связи между сущностями СЛУЖАЩИЙ и ОТДЕЛ (рис. 2.9) прямая связь РАБОТАЕТ указывает на то, что служащий работает только в одном отделе; обратная связь СОДЕРЖИТ указывает на то, что отдел содержит не менее одного служащего (обычно много служащих). Другими словами, связь L между двумя классами сущностей А и В указывает на то, что сущность А связана, как минимум, с M и, как максимум, с N сущностями В. Иногда N может быть не определено.

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

    Реляционная модель

    Основные понятия

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

    1. Каждый элемент таблицы представляет собой один элемент данных, т.е. группа значений в одном столбце одной строки недопустима;

    2. Все столбцы в таблице однородные. Это означает, что элементы столбца имеют одинаковую природу. Столбцам присвоены имена;

    3. В таблице нет двух одинаковых строк;

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

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

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

    Приведем ряд терминов, применяющихся в реляционной модели:

    · Отношением (relation) называется двумерное множество – таблица, удовлетворяющая вышеперечисленным требованиям;

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

    · Кортежом (tuple) называется строка таблицы. В общем случае кортежи представляют собой набор пар <атрибут>, <значение>. Каждое значение должно быть атомарным, т.е. не может быть многозначным или составным. Следовательно, многозначные и составные атрибуты в реляционной модели не поддерживаются. Количество кортежей называется кардинальным числом ;

    · Домен представляет собой множество всех возможных значений определенного атрибута отношения.

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

    · Потенциальный ключ – это подмножество атрибутов отношения, обладающего следующими свойствами:

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

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

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

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

    Исходя их вышеприведенных понятий, математически отношение можно описать следующим образом. Пусть даны n множеств Dl, D2, D3,..., Dn . Тогда отношение R есть множество упорядоченных кортежей<d1 , d2 , d3 ,..., dn >, где dk ÎDk , dk – атрибут, a Dk – домен отношения R.

    В середине 70-х годов инженером IBM Коддом (Codd) была предложена модель данных, основанная на математических операциях исчисления отношений и реляционной алгебре. Основной структурной единицей этой модели являлось отношение (relation). Поэтому такая модель данных получила название реляционной. Коддом был также разработан язык манипулирования данных, представленных в виде отношений. Он предложил два эквивалентных между собой по своим выразительным возможностям варианта языка манипулирования данными:

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

    6. Реляционное исчисление . Это непроцедурный язык описательного или декларативного характера, содержащий лишь информацию о желаемом результате. Процесс получения этого результата скрыт от пользователя. К языкам такого типа относятся SQL и QBE. Первый основан на реляционном исчислении кортежей, второй – на реляционном исчислении доменов.

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

    Отношения

    Теоретическим фундаментом реляционного подхода к БД является математическая теория отношений. Основные понятия и операции над отношениями используются в реляционных БД.

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

    Помимо элементов система включает в себя связи, отношения между ними. Так, числа а и b могут быть равны (а = b ) , не равны (а b ), а больше или равно b (а b ); фигуры А и В могут быть конгруэнтны (А = В ), А может содержать В (A B ); две прямые А и В могут быть параллельны (А || В ), перпендикулярны (). Студент а относится (принадлежит) к множеству А (студенты кафедры).

    Все перечисленные отношения касаются двух объектов и поэтому называются бинарными отношениями или просто отношениями . Отношения между тремя объектами называются тернарными , а между n объектами - n-арными . Так, тернарным является отношение между объектами ЗАКАЗЧИК, ПОСТАВЩИК, ТОВАР.

    Бинарным отношением R между множествами А и В (обозначается R (A , В )) называется любое множество упорядоченных пар (а , b ), где а А , b В . Если (а ,b ) R , то говорят, что а находится в отношении R к b , и записывают aRb , Поскольку множество упорядоченных пар (а , b ), где а A , b В , является декартовым произведением A ×В , то бинарным отношением будет любое подмножество этого произведения.

    Пример 2.1. Возьмем множество поставщиков и множество предлагаемых товаров. Любое подмножество связей ПОСТАВЩИК - ТОВАР является бинарным отношением.

    Пример 2.2. Пусть даны множества A = {1, 2, 3} и В = {2, 3, 4, 5, 6}. Декартово произведение A ×В - это множество пар:

    (1, 2), (1, 3), …, (1, 6),

    (2, 2), (2, 3), …, (2, 6),

    (3, 2), (3, 3), …, (3, 6).

    Построим бинарное отношение R , у которого первый элемент является делителем второго. Получим следующее бинарное отношение: R ={(1, 2), (1, 3), (1, 4), (1, 5), (1, 6), (2, 2), (2, 4), (2, 6), (3, 3), (3,6)}.

    Пример 2.3. Пусть Ольга (О), Павел (П), Иван (И) - имена детей в семье. Отношением а - брат b будет:

    R = {(П, О), (И, О), (П, И), (И, П)}.

    В отношении R (A , В ) множество А , т.е. совокупность всех первых координат, называют областью определения отношения R , а множество B , т. е. множество всех вторых координат, - областью его значений . Так, для примера 3.3 область определения - множество {П, И}, а область значений- множество {О, П, И}.

    Дополнением к бинарному отношению R будем называть отношение , которое определяет подмножество

    = (A ×B )\R ,

    т.е. a b тогда и только тогда, когда {a , b ) R . Так, для примера 2.2

    = {(2, 3), (2, 5), (3, 2), (3, 4), (3, 5)}.

    Бинарные отношения можно задавать различными способами: матрицами, графами, таблицами (сечениями). Отношение R (A , В ), где А = {а 1, а 2 , ..., a m }; B = {b 1, b 2 , ..., b n }, можно представить матрицей смежностей, строки которой соответствуют элементам A , а столбцы - элементам В ; на пересечении а i -й строки и b j -го столбца записана 1, если a i Rb j , и 0, если a i Rb j . Матрицы смежности для отношений R и для примера 2.2 имеют вид

    R

    Бинарное отношение R (A , В ) можно представить в виде ориентированного графа. Элементы множества А и В - вершины графа, причем ребром соединяются те и только те элементы а А , b В , для которых (a , b ) R. Так, в виде графа на рис. 2.10 представлено отношение для примера:

    Рис. 2.10. Представление отношения R в виде графа

    Пусть даны три множества А , В , С и два отношения R (A , В ) и S (B , С ). Композицией , или умножением , отношений R и S называют бинарное отношение RS (или R *S ) между элементами множеств А и С такое, что aRSc тогда и только тогда, когда существует хотя бы один элемент b В , при котором истинны aRb и bSc .

    Пример 2.4. Рассмотрим множества

    А = {а 1, а 2 , а 3 }, В = {b 1 , b 2 , b 3 }, С = {с 1 , c 2 , c 3 , c 4 }

    и отношения

    R (A , B ) = {(a 1 , b 2), (a 2 , b 1), (a 2 , b 3), (a 3 , b 4)},

    S (B , C ) = {(b 1 , c 2), (b 2 , c 1)}.

    Умножение отношений RS можно представить в виде графа (рис. 2.11.).

    Умножение бинарных отношений ассоциативно, т. е. (RS )T = R (ST ). Пусть даны отношения R (A , В ), S (B , С ) и Т (С , D ). Тогда a (RS )Td = aR (ST )d , т.е. элемент а A тогда и только тогда находится в каждом из отношений (RS )T и R (ST ) к элементу d D , когда существуют такие элементы b В и c С , что aRb , bSc , cTd . Умножение отношений, однако, не является в общем случае коммутативным (перестановочным), т.е. RS SR . Эта операция имеет место только в частных случаях (в этом случае говорят, что R и S перестановочны).

    Пример2.5. Пусть даны множества

    A = {a, b}, B = {a, b, c}, C = {b, c}

    и отношения R (A , В ) = {(а , b ), (b , с )}, S (B , C ) = {(b , с ), (а , b )}. Тогда aRSc = aSRc для любых а А и c С .

    Умножение k отношений R на множестве H , т.е. k -я степень R , обозначаемая R k , рекурсивно определяется следующим образом:

    1) aR l b истинно, когда истинно aRb ;

    2) aR i b для i >0 истинно, когда существует такое с А ,
    что aRc и cR i - l b истинны.

    Пусть имеем aR 3 b . Тогда существует такое с 1, что aRc 1 и c 1 R 2 b . Для c 1 R 2 b найдется такое с 2 , что c 1 Rc 2 и c 2 Rb , т. е. для аR 3 b есть такое с 1, с 2 А , что аRс 1 , c 1 Rc 2 и с 2 Rb .

    Пусть в одном или нескольких множествах даны от­ношения R i (i пробегает множество индексов I ) и S . Тогда

    , (2.1)

    Согласно a [(UR i )S ]с существует такой элемент b , что a (Ri )b и bSc . А это, в свою очередь, равносильно существованию такого индекса i 0 , что a R b и bSc , т.е.

    Рис. 2.11.Представление операции умножения отношений RS в виде графа

    a(R S) c и поэтому a (R i S )c . Заметим, что в равенствах (3.1) объединение нельзя заменить пересечением. Из (3.1) следует, что если даны отношения R , R " и S , причем R R ", то

    RS R "S , SR SR ". (2.2)

    Действительно, так как R R ’ то R R " = R ", что приводит к равенству (R R ’) S = RS R S = R S , которое равносильно включению RS R "S .а, если для функционального отношения R симметричное ему отношение тоже функционально.

    Всякому отношению R (A , В ) можно поставить в соответствие функцию f (x ), если его сечение по каждому х А либо пусто, либо есть элемент множества В . Если f (x ) всюду определена, т. е. область определения функции совпадает с А , то говорят, что отношение R (A , В ) есть отображение множества А в В . Функциональное отношение R (A , В ) вызывается отображением А в В , если для каждого а A существует один и только один элемент

    Рис. 2.12. Представление функционального отношения R(A, В) в виде графа

    b B , удовлетворяющий отношению aRb . Элемент b называется образом элемента а и обозначается aR , а элемент а - прообразом элемента b при отображении R . Совокупность всех прообразов элемента b в А при отображении R называется полным прообразом этого элемента в А .

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

    определяет отображение множества {1, 2, 3, 4} в множество {2, 5, 1, 4}. При этом 1R = 2, 2R = 5, 3R =1, 4R = 4.

    Пусть Р - отображение А в В , Q - отображение В в С . Умножение отображения PQ будет отображением А в С , и для любого x ?А справедливо x (PQ ) = (xP )Q . Действительно, пусть x (PQ )=c . Тогда для некоторого у В имеем хРу и yQc , откуда хР = у и поэтому с = (xP )Q . Обратно, из (xP )Q следует x (PQ ).

    Умножение отображений, заданных таблицами, покажем на примере:

    Отображение R называют сюръективным (сюръекцией ) или отображением множества А на множество В , когда каждый элемент b ?В имеет хотя бы один прообраз из А .

    Пример 2.6. Пусть А и В - множества вещественных чисел. Отображением (сюръективным) А на В может быть функция, определенная формулой х → Зх + 5, т. е. х переходит в y = 3x + 5.

    Функция х у =х 2 определяет отображение множества A в Б , которое не является сюръективным, так как отрицательные числа из В не являются образами элементов из А .

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

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

    Пример 2.7. Пусть А - множество действительных чисел, В - множество положительных действительных чисел. Отображение х у = е х является взаимно однозначным, так как каждому у соответствует х = ln y . Таким образом, имеем инъективное отображение, обратным для которого будет отображение у х =ln y .

    Взаимно однозначное отображение R между элементами одного множества, для которого R и R - l всюду определены, называется отображением на себя или биективным отображением . Биективное отображение является одновременно сюръективным и ииъективным.

    При отображении некоторого множества самого в себя говорят, что отображение aRb переводит точку а в точку b . При aRa точку а называют неподвижной точкой отображения R . Если все точки множества A при отображении неподвижны, то отображение называют тождественным и обозначают Е А . Очевидно, что Е -1 =Е и для любого отображения R RE =ER = R . При задании отображения в себя с помощью сечений в нижней строке таблицы будут такие же элементы, как и в верхней (возможно, в другом порядке), и каждый из них встречается один и только один раз:

    Матрица смежностей, соответствующая отображению в себя, является квадратной:

    R

    Представление отображения в себя в виде графа состоит из циклов (конечных или бесконечных).

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

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

    Модель "сущность-связь" была предложена в 1976 г. Питером Пин-Шэн Ченом, русский перевод его статьи "Модель "сущность-связь" - шаг к единому представлению данных" опубликован в журнале "СУБД" N 3 за 1995 г.

    Многоуровневые представления данных

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

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

    Рисунок 1. Анализ моделей данных с использованием нескольких уровней логических представлений

    Информация о сущностях и связях

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

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

    Сущность и множество сущностей

    Пусть e обозначает некоторую сущность, которая существует в нашем воображении. Каждая сущность относится к некоторому отличному от других множеству сущностей (entity set), такому как EMPLOYEE, PROJECT или DEPARTMENT. С каждым множеством сущностей связывается предикат, позволяющий проверить, принадлежит ли данная сущность данному множеству. Например, если мы знаем, что сущность относится к множеству сущностей EMPLOYEE, то мы также знаем, что эта сущность обладает свойствами, общими с другими сущностями из множества сущностей EMPLOYEE. В число этих свойств входит упомянутый выше предикат. Пусть Ei обозначает множество сущностей. Заметим, что множества сущностей не обязаны быть непересекающимися. Например, сущность, принадлежащая множеству сущностей MALE-PERSON (МУЖЧИНЫ), принадлежит также и множеству сущностей PERSON (ЛЮДИ). В этом случае MALE-PERSON является подмножеством PERSON.

    Связь, роль и множество связей.

    Рассмотрим ассоциации сущностей. Множество связей (relationship set) Ri – это математическое отношение между n сущностями, каждая из которых относится к некоторому множеству сущностей:

    { | e1 ∈ E1, e2 ∈ E2, ..., en ∈ En}, и каждый кортеж сущностей, , является связью (relationship). Заметим,что в этом определении Ei не обязаны быть различными наборами. Например, marriage (брак) – это связь между двумя сущностями из набора сущностей PERSON (ЧЕЛОВЕК).

    Роль (role) сущности в связи – это функция, которую сущность выполняет в данной связи. Husband (муж) и wife (жена) – это роли. Упорядочивание сущностей в определении связи (заметим, что использовались квадратные скобки) может отсутствовать, если в связи явно указаны роли сущностей: (r1/e1, r2/e2 ,..., rn/en), где ri – это роль сущности ei в данной связи.

    Атрибут, значение и множество значений.

    Информацию об сущности или связи получают путем наблюдения или измерения и выражают множеством пар атрибут-значение. 3, red, Peter и Johnson – это значения. Значения классифицируются в различные множества значений (value sets), такие как FEET, COLOR, FIRST-NAME и LAST-NAME. С каждым множеством значений связывается предикат для проверки того, принадлежит ли значение этому множеству. Значение из некоторого множества значений может быть эквивалентно другому значению из другого множества значений. Например, 12 из множества значений INCH (ДЮЙМЫ) эквивалентно 1 в множестве значений FEET (ФУТЫ).

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

    f: Ei or Ri → Vi or Vi1 × Vi2 × ... × Vin На рис. 2 показано несколько атрибутов, определенных на множестве сущностей PERSON. Атрибут AGE (ВОЗРАСТ) производит отображение в множество значений NO-OF-YEARS (ЧИСЛО-ЛЕТ). Атрибут может задавать отображение в декартово произведение множеств значений. Например, атрибут NAME (ПОЛНОЕ-ИМЯ) задает отображение в множества значений FIRST-NAME (ИМЯ) и LAST-NAME (ФАМИЛИЯ). Заметим, что несколько атрибутов могут задавать отображение одного и того же множества сущностей в одно и то же множество значений (или одну и ту же группу множеств значений). Например, атрибуты NAME (ПОЛНОЕ-ИМЯ) и ALTERNATIVE-NAME (ДРУГОЕ-ПОЛНОЕ-ИМЯ) задают отображение из множества сущностей EMPLOYEE в множества значений FIRST-NAME и LAST-NAME. Тем самым, атрибут и множество значений являются разными понятиями, хотя в некоторых случаях они могут иметь одно и то же имя (например, атрибут EMPLOYEE-NO (НОМЕР-СЛУЖАЩЕГО) задает отображение из EMPLOYEE (СЛУЖАЩИЕ) в множество значений EMPLOYEE-NO (НОМЕР-СЛУЖАЩЕГО)). Это различие не является явным в сетевой модели и во многих существующих системах управления данными. Заметим также, что атрибут определяется как функция. Следовательно, он отображает данную сущность в одно значение (или один кортеж значений в случае декартова произведения множеств значений).

    Рис. 2. Атрибуты, определенные на множестве сущностей PERSON

    Заметим, что связи также имеют атрибуты. Рассмотрим множество связей PROJECT-WORKER (ИСПОЛНИТЕЛЬ-ПРОЕКТА) (рис. 3). Атрибут PERCENTAGE-OF-TIME (ПРОЦЕНТ-ВРЕМЕНИ), представляющий долю времени, выделенную конкретному служащему на конкретный проект,– это атрибут, определенный на множестве связей PROJECT-WORKER. Он не является ни атрибутом сущности EMPLOYEE, ни атрибутом сущности PROJECT, так как его смысл зависит и от служащего, и от проекта. Понятие атрибута связи важно для понимания семантики данных и определения функциональных зависимостей между данными.

    Рис. 3. Атрибуты, определенные на множестве связей PROJECT-WORKER

    Концептуальная структура информации.

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

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

    Рис. 4. Информация о сущностях из множества сущностей (табличная форма)

    Рис. 5. Информация о связях из множества связей (табличная форма)

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

    Заметим, что на рис. 4 и 2 (а также на рис. 5 и 3) представлены различные формы одной и той же информации. Форма таблицы используется для упрощения связывания с реляционной моделью.

    Структура информации

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

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

    На рис. 2 значения атрибута EMPLOYEE-NO могут использоваться для идентификации сущностей в множестве сущностей EMPLOYEE, если у каждого служащего имеется уникальный номер служащего. Возможно, для идентификации сущностей в множестве сущностей понадобится более одного атрибута. Возможно также, что для идентификации сущностей будут использоваться несколько групп атрибутов. По существу, ключ сущности (entity key) – это группа атрибутов, такая, что отображение из множества сущностей в соответствующую группу множеств значений является взаимнооднозначным отображением. Если не удается найти такое отображение на доступных данных, или если желательна простота в идентификации объектов, то можно искусственно определить атрибут и множество значений, чтобы добиться наличия взаимнооднозначного отображения. В случае существования нескольких ключей обычно выбирается семантически значимый ключ в качестве первичного ключа сущности (entity primary key – PK).

    Рис. 6. Представление сущностей значениями (номерами служащих)

    Рис. 6 получен слиянием множества сущностей EMPLOYEE с множеством значений EMPLOYEE-NO с рис. 2. Обратим внимание на некоторые семантические следствия рис. 6. Каждое значение в множестве значений EMPLOYEE-NO представляет сущность (служащего). Атрибуты задают отображение из множества значений EMPLOYEE-NO в другие множества значений. Заметим также, что атрибут EMPLOYEE-NO задает отображение множества значений EMPLOYEE-NO в само его.

    Отношения сущность/связь.

    Информация о сущностях в множестве сущностей теперь может быть организована в форме, показанной на рис. 7. Заметим, что рис. 7 похож на рис. 4, за исключением того, что сущности представлены значениями их первичных ключей. Вся таблица на рис. 7 представляет отношение сущностей (entity relation), а каждая строка представляет кортеж сущностей (entity tuple).

    В некоторых случаях сущности в множестве сущностей нельзя уникально идентифицировать значениями их собственных атрибутов; следовательно, для их идентификации мы должны использовать связь(и). Например, рассмотрим сущности служащих-подчиненных (dependent) и служащих-начальников (supporter): подчиненные идентифицируются своими именами и значениями основного ключа служащих-начальников (т.е. своими связями с этими служащими). Заметим, что на рис. 9 EMPLOYEE-NO не является атрибутом сущностей в множестве DEPENDENT, а представляет собой первичный ключ служащих, которые имеют подчиненных. Каждая строка значений на рис. 9 – это кортеж сущностей с EMPLOYEE-NO и NAME в качестве первичных ключей. Вся таблица является отношением сущностей.

    Теоретически, для идентификации сущностей может использоваться любой вид связи. Для простоты мы ограничимся только одним видом связи: бинарными связями с отображением 1:n, в которых существование n сущностей на одной стороне связи зависит от существования одной сущности на другой стороне связи. Например, один служащий может иметь n (n = 0, 1, 2,...) подчиненных, и существование подчиненных зависит от существования соответствующего служащего-начальника.

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

    Следовательно, мы имеем две формы отношений сущностей. Если связи используются для идентификации сущностей, мы будем называть это слабым отношением сущностей (weak entity relation) (рис. 9). Если связи не используются для идентификации сущностей, мы будем называть это регулярным отношением сущностей (regular entity relation) (рис. 8). Если некоторые сущности в связи идентифицируются другими связями, мы будем называть это слабым отношением связей (weak relationship relation). Например, любые связи между сущностями DEPENDENT и другими сущностями приведут к образованию слабых отношений связи, так как сущность DEPENDENT идентифицируется своим именем и связью с сущностью EMPLOYEE. Проведение различия между регулярными и слабыми отношениями сущностей и связей будет полезно для поддержки целостности данных.

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

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

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

    В прошлой лекции мы познакомились с методологиями 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. Это сетевая структура.

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

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

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

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

    ЛЕКЦИЯ

    Модель «сущность-связь».

    Основные понятия: Сущность, Свойства, Связи.

    Представление сущностей, свойств, связей

    9.1. Модель «Сущность-Связь»

    Наиболее распространенным средством моделирования предметной области систем, ориентированных на обработку фактографической информации, является модель «сущность-связь» (Entity - Relationship Model - ER М ), впервые предложенная Питером Пин-Шэн Ченом в 1976 г. Эта модель традиционно используется в структурном анализе и проектировании, но, по существу, реализует объектный подход к моделированию предметной области.

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

    Моделирование предметной области в этом случае базируется на использовании графических диаграмм, включающих сравнительно небольшое число компонентов (слайд 2) и, самое важное – технологию построения таких диаграмм.

    Семантическую основу ER -модели составляют следующие предположения:

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

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

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

    - систематизация представления, основанная на классах, в общем случае предполагает иерархическую зависимость типов: сущность типа А является подтипом сущности B , если каждый экземпляр типа А является экземпляром сущности типа B ;

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

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

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

    На слайде 3 приведенный пример представления сущности, который не является полным и не претендует на точное соответствие какой либо версии построения ER -диаграмм.

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

    1. связи между объектами и наборами характеристических свойств и таким образом определить сами объекты;

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

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

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

    Сущность имеет имя , уникальное в пределах модели. При этом имя сущности - это имя типа , а не некоторого конкретного экземпляра.

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

    Свойства(слайд 4)

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

    Свойство может быть множественным или единичным – т.е. атрибут, задающий свойство, может одновременно иметь несколько значений или, соответственно, только одно. Например, сотрудник может иметь несколько специальностей, но единственное значение «Таб. номер».

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

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

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

    Значения свойств могут быть постоянными - статическими , или динамическими , т.е. меняться со временем. Например, свойство «Таб. номер» является статическим, а «Адрес» - динамическим. Свойство может быть неопределенным , если оно является динамическим, но его текущее значение еще не задано.

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

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

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

    Сущности, объединяемые связью, называются участниками . Степень связи определяется количеством участников связи .

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

    Количественный характер участия экземпляров сущностей (один или многие) задается типом связи (или мощностью связи ). Возможны следующие типы: «один к одному» (1:1), «один ко многим» (1: М), «многие к одному» (М:1), «многие ко многим» (М:М ) (Слайды 5, 6, 7) .

    Следует отметить, что инструмент связей - это средство представления сложных объектов , каждый из которых может рассматриваться как множество некоторым образом взаимосвязанных простых объектов . Деление на простые и сложные объекты, также как и характер взаимосвязи, является условным и определяется особенностям анализа предметной области, т.е. в конце концов – характером использования данных о предметах в решаемых прикладных задачах. При этом с точки зрения, например, конструктора, ДЕТАЛЬ является сложным объектом, а с точки зрения поставщика – простым.

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

    Отношение «часть-целое» используются для представления составных объектов . Например, МАШИНЫ состоят из УЗЛОВ, УЗЛЫ состоят из ДЕТАЛЕЙ. Здесь возможны как отношения «один ко многим», так и «многие ко многим».

    Отношение «род-вид» - для представления обобщенных объектов . Например, СОТРУДНИКИ подразделяются по профессии на КОНСТРУКТОРОВ, ПРОГРАММИСТОВ, РАБОЧИХ; ПРОГРАММИСТЫ – на ПРИКЛАДНЫХ ПРОГРАММИСТОВ и СИСТЕМНЫХ ПРОГРАММИСТОВ. Иерархические отношения, и, в частности – «родо-видовые », обычно используются как основа классификации объектов по наборам характеристических признаков. Причем «видовые» объекты наследуют свойства «родовых».

    Другой широко используемой разновидностью взаимосвязи является агрегирование – объединение простых объектов в сложный по принципу их принадлежности агрегату или их совместного участия в некотором процессе. Агрегирование, рассматриваемое здесь как более общий случай иерархических отношений, объединяет объекты разной природы с единственным общим свойством «совместное участие». Агрегированные объекты именуются обычно отглагольными существительными, например, «Состав »: ПОДРАЗДЕЛЕНИЕ состоит из СОТРУДНИКОВ; «Поставка »: ПОСТАВЩИК поставляет ДЕТАЛИ.

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

    Сущность, на основе которой определяются подтипы, называется супертипом . Подтипы должны образовывать полное множество, т.е. любой экземпляр супертипа должен относиться к некоторому подтипу. Иногда для полноты множества надо определять дополнительный подтип, например ПРОЧИЕ.

    Подтип наследует свойства и связи супертипа . Например, тип сущности ПРОГРАММИСТ является подтипом сущности СОТРУДНИК. Программисты обладают всеми свойствами сотрудников и участвуют во всех связях, однако обратные утверждения неверны.

    Тип сущности, его подтипы, подтипы этих подтипов и т.д. образуют иерархию типов сущности , пример которой приведен на Слайде 8.

    9.2. ER- диаграмма

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

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

    Сущности .Каждый тип сущности в ER-диаграммах представляется в виде прямоугольника, содержащего имя сущности. В качестве имени обычно используются существительные (или обороты существительного) в единственном числе. Для отражения сущностей слабых типов используются прямоугольники, стороны которых рисуются двойными линиями. Например, в представленной на слайде 9 ER-диаграмме ПОДЧИНЕННЫЙ – сущность слабого типа.

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

    Имена ключевых свойств подчеркиваются. Например, свойство «Таб.н омер» сущности СОТРУДНИК.

    Контур эллипса рисуется двойной линией, если свойство многозначное. Например, свойство «специальность» сущности СОТРУДНИК.

    Контур эллипса рисуется штриховой линией, если свойство производное. Например, свойство «кол-во» сущности ПОСТАВЩИК.

    Эллипс соединяется пунктирной линией, если свойство условное. Например, свойство «Ин. я зык» сущности СОТРУДНИК.

    Если свойство составное, то составляющие его свойства отображаются другими эллипсами, соединенными с эллипсом составного. Например, свойство «Адрес» сущности СОТРУДНИК состоит из простых свойств «Город», «Улица», «Дом».

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

    Стороны ромба рисуют двойными линиями, если это связь сущности слабого типа с сущностью от которой она зависит. Например, связь «Подчинение», связывающая сущность слабого типа ПОДЧИНЕННЫЙ с сущностью СОТРУДНИК, от которой она зависит.

    Участники связи соединены со связью линиями. Двойная линия обозначает полное участие сущности в связи с данной стороны. Например, связь «Подчинение», со стороны сущности ПОДЧИНЕННЫЙ.

    Связь может быть модифицирована указанием роли. Например, для рекурсивной связи «Состав», указаны роли: «Деталь состоит из …» и «Деталь входит в состав …».

    Тип связи указывается индексами «1» или «М» над соответствующей линией. Например, связь «Руководство» имеет тип «один ко многим»: один сотрудник может руководить многими проектами; связь «Участие» имеет тип «многие ко многим»: один сотрудник может участвовать во многих проектах, и в проекте могут участвовать многие сотрудники.

    Пример нормализованной формы ER-диаграммы приведен на слайде 10.

    Одна из разновидностей модели «сущность-связь» используется в нотации IDEF1Х, входящем в семейство стандартов IDEF.

    Графический язык модели и пример диаграммы представлены на слайде 11 .

    Необязательные связи между сущностями Отдел и Сотрудник, Сотрудник и Подчиненный имеют мощность «один ко многим» (конец связи «многие» обозначен жирной точкой), а обязательная связь между сущностями Сотрудник и Проект имеет мощность «многие ко многим».

    Графические элементы основных нотаций модели «сущность-связь» представлены на слайде 12 .


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

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