Оценка мощностных характеристик сущностей и связей. Модель «Сущность-связь
Модель данных «сущность-связь»
Модель данных «сущность-связь» ввел в 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 | ||||
Представление отображения в себя в виде графа состоит из циклов (конечных или бесконечных).
Для разработки базы данных, структура которой не зависит от конкретных информационных потребностей и позволяет выполнять любые запросы пользователей, служит диаграмма инфологических моделей «сущность-связь» (ER - диаграмма).
Наиболее часто формализация представлений о предметной области осуществляется в рамках модели «сущности-связи» («объекты-связи»). На данном этапе проектирования используется метод «сущность – связь», который называют также методом «ER-диаграмм» (“Essence” – сущность, “Relation” – связь). Этот метод основан на использовании диаграмм, называемых соответственно диаграммами ER-экземпляров и диаграммами ER-типа.
ER – диаграмма «сущность-связь» представляет собой набор множества объектов и их характеристик, а также взаимосвязей между ними, нужных для выявления данных, которые в дальнейшем используются функциями проектируемой системы.
Основными понятиями метода сущность – связь являются следующие:
Сущность;
Атрибут сущности;
Ключ сущности;
Связь между сущностями;
Степень связи;
Класс принадлежности экземпляров сущности;
Диаграммы ER-экземпляров;
Диаграммы ER-типа.
Под информационным объектом понимается некоторая сущность фрагмента действительности, например: организация, документ, сотрудник, место, событие и т. д. Сущность представляет собой объект, информация о котором хранится в базе данных. Экземпляры сущности отличаются друг от друга и однозначно идентифицируются. Названием сущности являются имена существительные. Каждый тип объектов идентифицируется присущим ему набором атрибутов. В данном курсовом проекте сущностями являются: сотрудник, должности, образование, формы трудового участия, факультеты, кафедры и темы.
Атрибут ((от лат. attribuo – приписываю) – свойство или вещь, неотделимые от предмета) представляет собой логически неделимый элемент структуры информации, характеризующийся множеством атомарных значений. Это понятие аналогично понятию «атрибут» в отношении. Экземпляр объекта характеризуется совокупностью конкретных значений атрибутов данного типа объекта. Один или некоторая группа атрибутов объекта данного типа могут исполнять роль ключевого атрибута (ключа сущности). В данном курсовом проекте вышеуказанные сущности характеризуются атрибутами, такими, как: код_факультета, название_факультета, код_кафедры, ФИО_сотрудника и т. д.
Ключ сущности – это атрибут или набор атрибутов, идентифицирующих экземпляр сущности (например, код_должности).
Связь двух или более сущностей – это зависимость между атрибутами этих сущностей. Оно обозначается глаголом. Причем связи бывают двух типов:
Иерархические;
Одноуровневые.
Для повышения наглядности и удобства проектирования используются графические средства представления сущности, экземпляров сущности и связей между ними . ER-диаграмма представлена в приложении А.
Классификация связей
В реальных базах данных информация размещается в нескольких таблицах. Таблицы при этом связаны семантикой информации. В реляционных СУБД для указания связей таблиц производят операцию их связывания. Это повышает достоверность хранимой в базе информации, т. к. СУБД контролирует целостность данных, вводимых в базу в соответствии с установленными связями.
Установление связей облегчает доступ к данным при выполнении операций: поиск, просмотр, редактирование, выборка и подготовка отчета, т.к. обеспечивается обращение к любым полям связанных таблиц.
Между таблицами могут устанавливаться:
Бинарные связи;
Тернарные связи;
N-арные связи.
При связывании двух таблиц выделяют основную и подчиненную таблицы (родительскую и дочернюю). Логическое связывание таблиц производится с помощью ключа связей. Поля основной таблицы могут быть простыми и ключевыми. Поля связей дополнительной таблицы чаще всего ключевые. В зависимости от того, как определены поля связи основной и дополнительной таблиц (как относятся ключевые поля с полями связи), устанавливаются виды связей:
1:1 (один к одному);
1:М (один ко многим);
М:1 (многие к одному);
М:М (многие ко многим).
Связь вида 1:1 образуется, если все поля связи родительской и дочерней таблиц являются ключевыми. Поскольку значения в ключевых полях двух таблиц не повторяются, обеспечивается взаимно-однозначное соответствие записей из этих таблиц. Сами таблицы, по сути, здесь становятся равноправными.
Связь вида 1:М имеет место в случае, когда одной записи родительской таблицы соответствует несколько записей дочерней таблицы.
Связь М:1 имеет место в случае, когда одной ил нескольким записям основной таблицы ставится в соответствие одна запись дополнительной таблицы.
Связь М:М возникает в случаях, когда нескольким записям основной таблицы соответствует несколько записей дополнительной таблицы.
Аналогично связи 1:1, связь М:М не устанавливает подчиненность таблиц. На практике в связь обычно вовлечены несколько таблиц. При этом одна таблица может иметь различные виды связи с несколькими таблицами, образуя иерархию или «дерево связей» .
В данном курсовом проекте таблицы связаны связями вида 1:М (один ко многим). Например, таблица «факультеты» является родительской таблицей по отношению к дочерней таблице «кафедры». Эти таблицы связаны отношением 1:М с помощью ключа «код_факультета»
14. Модель «сущность-связь» (er-модель)
Сущность – это некоторый объект реального мира, который может существовать независимо. Сущность имеет экземпляры , отличающиеся друг от друга значениями атрибутов и допускающие однозначную идентификацию. Атрибут – это поименованная характеристика сущности. Атрибут, который уникальным образом идентифицирует экземпляры сущности, называется ключом . Ключ может быть составным , представляющим комбинацию нескольких атрибутов.
Связь представляет взаимодействие между сущностями. Она характеризуется мощностью (степенью связи) , которая показывает, сколько сущностей участвует в связи. Связь между двумя сущностями называется бинарной
Важной характеристикой связи является тип связи (кратность) . Рассмотрим типы вышеуказанных связей. Так как один менеджер управляет только одним филиалом, то 1-я связь имеет тип «один-к-одному» (1:1).
Так как один филиал обрабатывает несколько счетов, а каждый счет обрабатывается только одним филиалом, то 2-я связь имеет тип «один-ко-многим» (1:М).
Так как один счет может совместно использоваться несколькими клиентами и один клиент может иметь несколько счетов, то 3-я связь имеет тип «многие-ко-многим» (M:N).
Степень участия определяет, участвуют ли в связи все или только некоторые экземпляры сущности. Она может быть обязательной или необязательной .
Если не каждый экземпляр сущности А связан с каким-либо экземпляром сущности В, то степень участия сущности А является необязательной . Это изображается на ER-диаграмме черным кружком, помещенным на линии связи возле сущности А.
Если каждый экземпляр сущности А связан с каким-либо экземпляром сущности В, то степень участия сущности А является обязательной . При этом на ER-диаграмме черный кружок на линии связи помещается в прямоугольник рядом с сущностью А. Напр., связь Сотрудник Регистрирует Клиентов имеет тип (1:М). При этом не каждый сотрудник регистрирует клиентов (необязательное участие), но каждый клиент регистрируется сотрудником (обязательное участие):
Каждая из четырех сущностей модели может быть описана своим набором атрибутов.
|
МЕНЕДЖЕР | ||
|
Номер менеджера (НМ) |
Номер филиала (НФ) |
|
|
Стажработы (СТАЖ) |
Адрес филиала (АДР_Ф) |
|
|
Специальность (СПЕЦ) | ||
|
Номер клиента (НК) |
||
|
Номер счета (НС) |
Ф.И.О. клиента (ФИО_К) |
|
|
Тип счета (ТИП) |
Адрес клиента (АДР_К) |
|
|
Остаток на счете (ОСТ) |
Социальное положение (СОЦ_П) |
ER-модель в совокупности с наборами атрибутов сущностей может служить примером семантической (концептуальной) модели предметной области или концептуальной схемы базы данных.
Но если требуется одновременно использовать термины ER-модели и реляционной модели данных, то, безусловно, требуется применять для терминов relation и relationship разные русские эквиваленты. За этими терминами стоят весьма различные понятия. В реляционной модели отношение ( relation ) – это единственная родовая структура данных . С помощью этого же механизма представляются "связанные" сущности (вспомните, например, про внешние ключи). Как мы увидим немного позже, в ER-модели для представления схемы базы данных используются два равноправных понятия – сущность и связь . Связи в ER-модели играют роль, отличную от той, какую играют отношения в реляционной модели данных.
Кроме того, в русскоязычную терминологию вошла и чистая транслитерация термина relation именно в смысле отношение . Мы говорим, например, про реляционную модель данных , реляционную алгебру и т. д., понимая модель данных , основанную на отношениях, алгебру отношений и т. п. По этому поводу, по крайней мере, в контексте баз данных, разумно окончательно зарезервировать термины relation и отношение для обозначения понятий реляционной модели данных, а для термина relationship использовать другой допустимый русскоязычный эквивалент – связь .
На использовании разных вариантов ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Питером Ченом (Peter Chen) в 1976 г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. Простота и наглядность представления концептуальных схем баз данных в ER-модели привели к ее широкому распространению в CASE-системах , поддерживающих автоматизированное проектирование реляционных баз данных . Среди множества разновидностей ER-моделей одна из наиболее популярных и развитых применялась в системе CASE компании Oracle . Мы обсудим некоторый упрощенный вариант этой модели. Если говорить более точно, сосредоточимся на ее структурной и целостной частях.
Основные понятия ER-модели
Основными понятиями ER-модели являются сущность , связь и атрибут . Сущность – это реальный или представляемый объект, информация о котором должна сохраняться и быть доступной. 4Понятно, что это "определение" на самом деле является тавтологией , поскольку, во-первых, мы пытаемся определить термин сущность через не определенный термин объект, а во-вторых, попытки определения термина объект настолько же безнадежны. Обычно авторы пытаются оправдываться тем, что в подобном контексте они имеют в виду "житейское", а не сколько-нибудь формализованное понятие объекта. Конечно, от этого не становится легче, поскольку понятие сущности должно пониматься в достаточно точном смысле. Но эта тавтология не изобретена автором этого курса; она традиционна для области семантического моделирования. В этой области стремятся максимально избегать формальностей. В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности . При этом имя сущности – это имя типа , а не некоторого конкретного экземпляра этого типа . 5Хотя было бы правильнее всегда использовать термины тип сущности и экземпляр типа сущности , для избежания многословности (и следуя традиции) в тех случаях, где это не приводит к двусмысленности, мы будем использовать термин сущность в значении типа сущности . Для большей выразительности и лучшего понимания имя сущности может сопровождаться примерами конкретных экземпляров этого типа.
Рис.
9.1.
На рис. 9.1 изображена сущность АЭРОПОРТ с примерными экземплярами "Шереметьево" и "Хитроу". Эта примитивная диаграмма тем не менее несет важную информацию. Во-первых, она показывает, что в базе данных будут содержаться однотипные структуры данных (экземпляры сущности ), описывающие аэропорты. Во-вторых, поскольку в жизни существует несколько точек зрения на аэропорты (например, точка зрения пилота, точка зрения пассажира, точка зрения администратора) и этим точкам зрения соответствуют разные структуры данных, то приведенные примеры аэропортов позволяют несколько сузить допустимый набор точек зрения. В нашем случае приведены примеры международных аэропортов, так что, скорее всего, имеется точка зрения пассажира или пилота международных авиарейсов.
При определении типа сущности необходимо гарантировать, что каждый экземпляр сущности может быть отличим от любого другого экземпляра той же сущности . Это требование в некотором роде аналогично требованию отсутствия кортежей-дубликатов в реляционных таблицах.
Связь – это графически изображаемая ассоциация, устанавливаемая между двумя типами сущностей . Как и сущность , связь – это типовое понятие, все экземпляры обоих связываемых типов сущностей подчиняются устанавливаемым правилам связывания. Поэтому правильнее говорить о типе связи , устанавливаемой между типами сущности , и об экземплярах типа связи , устанавливаемых между экземплярами типа сущности . 6Тем не менее, как и в случае типа сущности , мы будем часто использовать термин связь в значении типа связи . В обсуждаемом здесь варианте ER-модели эта ассоциация всегда является бинарной и может существовать между двумя разными типами сущностей или между типом сущности и им же самим (рекурсивная связь ). В любой связи выделяются два конца (в соответствии с существующей парой связываемых сущностей ), на каждом из которых указываются имя конца связи , степень конца связи (сколько экземпляров данного типа сущности должно присутствовать в каждом экземпляре данного типа связи ), обязательность связи (т. е. любой ли экземпляр данного типа сущности должен участвовать в некотором экземпляре данного типа связи ). 7 В некоторых вариантах ER-модели конец связи называют ролью связи в данной сущности . Тогда можно говорить об имени роли , степени роли и обязательности роли связи в данной сущности .
Связь представляется в виде ненаправленной линии, соединяющей две сущности или ведущей от сущности к ней же самой. При этом в месте "стыковки" связи с сущностью используются:
- трехточечный вход в прямоугольник сущности , если для этой сущности в связи могут (или должны) использоваться много (many ) экземпляров сущности ;
- одноточечный вход, если в связи может (или должен) участвовать только один экземпляр сущности .
Обязательный конец связи изображается сплошной линией, а необязательный – прерывистой линией.
Связь между сущностями БИЛЕТ и ПАССАЖИР , показанная на рис. 9.2 , связывает билеты и пассажиров. Конец связи с именем "для" позволяет связывать с одним пассажиром более одного билета, причем каждый билет должен быть связан с каким-либо пассажиром. Конец связи с именем "имеет" показывает, что каждый билет может принадлежать только одному пассажиру, причем пассажир не обязан иметь хотя бы один билет.
Рис. 9.2.
- каждый БИЛЕТ предназначен для одного и только одного ПАССАЖИРА ;
- каждый ПАССАЖИР может иметь один или более БИЛЕТОВ или не иметь вовсе.
На следующем примере (рис. 9.3) изображена рекурсивная связь , связывающая сущность МУЖЧИНА с ней же самой. Конец связи с именем " сын " определяет тот факт, что несколько людей могут быть сыновьями одного отца. Конец связи с именем " отец " означает, что не у каждого мужчины должны быть сыновья.
Лаконичная устная трактовка изображенной диаграммы состоит в следующем:
- каждый МУЖЧИНА является сыном одного и только одного МУЖЧИНЫ ;
- каждый МУЖЧИНА может являться отцом одного или более МУЖЧИН .
Атрибутом сущности является любая деталь, которая служит для уточнения, идентификации, классификации, числовой характеристики или выражения состояния сущности . Имена атрибутов заносятся в прямоугольник, изображающий
Введение
Центральные идеи современной информационной технологии основываются на концепции, согласно которой данные должны быть сформированы в базы данных с целью отображения меняющегося реального мира и удовлетворения информационных потребностей пользователей. Эти базы данных образовываются и функционируют под управлением специальных программных комплексов (совокупностей языков программирования и программных средств), называемых системами управления базами данных (СУБД). Сама база данных – это хранилище для большого количества систематизированных данных, с которыми можно производить определённые действия: добавления, удаления, изменения, копирования, упорядочивание.
Увеличение объема хранимых данных, расширение круга пользователей информационных систем привели к широкому распространению наиболее удобных и сравнительно простых для понимания реляционных (табличных) СУБД. Для обеспечения одновременного доступа к данным множества пользователей, нередко расположенных достаточно далеко друг от друга и от места хранения баз данных, созданы сетевые мультипользовательские версии баз данных основанных на реляционной структуре. В них тем или иным путем решаются специфические проблемы параллельных процессов, целостности (правильности) и безопасности данных, а также санкционирования доступа.
За последние несколько лет наблюдается тенденция к усложнению структур данных. Простые виды информации, представимой в форме чисел и текстовых строк, не утратив своей значимости, дополняются сегодня многочисленными мультимедийными документами, графическими образами, хронологическими рядами, процедурными, или активными, данными и мириадами прочих сложных информационных форм. В связи с этим появилась целая плеяда СУБД, поддерживающих новые коллекции данных и способных реализовать преимущества современных аппаратных средств. Одним из таких СУБД является MS Access 2003 (2007), входящая в пакет программ Microsoft Office, и являющаяся одной из популярных реляционных СУБД для локальных компьютеров.
Популярность СУБД Microsoft Access обусловлена следующими причинами:
доступность в изучении и понятность позволяют являться одной из лучших систем быстрого создания приложений управления базами данных;
полностью русифицирована;
возможность использования OLE технологии;
поддержка WWW-идеологии;
визуальная технология позволяет постоянно видеть результаты своих действий и корректировать их, кроме того, работа с конструктором форм может существенно облегчить дальнейшее изучение таких систем программирования, как Visual Basic или Delphi;
широко и наглядно представлена справочная система;
наличие большого набора "мастеров" по разработке объектов.
В настоящее время в различных крупных организациях широко применяются автоматизированные информационные системы (АИС).
Цель данного проекта: применение на практике знаний, полученных в процессе изучения курса "Базы данных", и приобретение практических навыков при проектировании и создания информационных систем (ИС), основанных на базах данных.
Основные понятия ER-модели: сущность, экземпляр сущности, атрибут, ключ, связь, типы связей
Основными понятиями ER-модели являются сущность, связь и атрибут.
Сущность – это реальный или представляемый объект, информация о котором должна сохраняться и быть доступна. В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности. При этом имя сущности – это имя типа, а не некоторого конкретного экземпляра этого типа. Для большей выразительности и лучшего понимания имя сущности может сопровождаться примерами конкретных объектов этого типа.
Каждый экземпляр сущности должен быть отличим от любого другого экземпляра той же сущности (это требование в некотором роде аналогично требованию отсутствия кортежей-дубликатов в реляционных таблицах).
Атрибутом сущности является любая деталь, которая служит для уточнения, идентификации, классификации, числовой характеристики или выражения состояния сущности. Имена атрибутов заносятся в прямоугольник, изображающий сущность, под именем сущности и изображаются малыми буквами, возможно, с примерами.
Ключ сущности – это неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности. Неизбыточность заключается в том, что удаление любого атрибута из ключа нарушается его уникальность. Сущность может иметь несколько различных ключей. Ключевые атрибуты изображаются на диаграмме подчеркиванием.
Связь – это графически изображаемая ассоциация, устанавливаемая между двумя сущностями. Эта ассоциация всегда является бинарной и может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). В любой связи выделяются два конца (в соответствии с существующей парой связываемых сущностей), на каждом из которых указывается имя конца связи, степень конца связи (сколько экземпляров данной сущности связывается), обязательность связи (т.е. любой ли экземпляр данной сущности должен участвовать в данной связи).
Связь представляется в виде линии, связывающей две сущности или ведущей от сущности к ней же самой. При этом в месте «стыковки» связи с сущностью используются трехточечный вход в прямоугольник сущности, если для этой сущности в связи могут использоваться много (many) экземпляров сущности, и одноточечный вход, если в связи может участвовать только один экземпляр сущности. Обязательный конец связи изображается сплошной линией, а необязательный - прерывистой линией.
Каждая связь имеет два конца и одно или два наименования. Наименование обычно выражается в неопределенной глагольной форме: «иметь», «принадлежать» и т.п. Каждое из наименований относится к своему концу связи. Иногда наименования не пишутся ввиду их очевидности. Каждая связь может иметь один из следующих типов связи:
Один к одному
Один ко многим
Много ко многим
Рис. 1 – Типы связей
Связь типа «один к одному» означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой). Связь «один к одному» чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две.
Связь типа «один ко многим» означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны «один») называется родительской, правая (со стороны «много») - дочерней.
Связь типа «много ко многим» означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи «много ко многим» является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа «один ко многим» путем создания промежуточной сущности.
Каждая связь может иметь одну из двух модальностей связи:
Может
Должен
Рис. 2 – Модальность связи
Модальность «может» означает, что экземпляр одной сущности может быть связан с одним или несколькими экземплярами другой сущности, а может быть и не связан ни с одним экземпляром.
Модальность «должен» означает, что экземпляр одной сущности обязан быть связан не менее чем с одним экземпляром другой сущности.
Преобразование ER-модели в реляционную модель данных
Рассмотрим преобразование ER-модели в реляционную модель данных на абстрактном примере. Предположим, что дана ER-модель. Необходимо получить набор таблиц (отношений) вида Таблица (Ключ, Атрибут1, Атрибут2, …, АтрибутN). Ключ может быть составным. Удобно имена атрибутов в масштабе ER-модели сделать уникальными, тогда при построении реляционной модели их (почти никогда) не придется переименовывать.
Преобразование множеств сущностей (для краткости - сущностей)
Преобразование обычной сущности
Рис. 3 – Преобразование обычной сущности
Обычная сущность преобразуется в отдельную таблицу, полями таблицы будут все атрибуты сущности: Сущность (Ключ, Атрибут1, Атрибут2)
Преобразование слабой сущности
Слабая сущность преобразуется в отдельную таблицу, полями таблицы будут все атрибуты сущности плюс ключевые атрибуты всех сущностей, с помощью которых данная слабая сущность идентифицируется.
Ключевые поля всех родительских таблиц войдут в ключ дочерней таблицы. Для дочерней таблицы они будут называться внешним ключом: Сущность1 (Ключ1, Ключ2, Атрибут1, Атрибут2).
Ключ 1
Атрибут 1
Атрибут 2
Сущность 1
Сущность 2
Ключ 2
Рис. 4 – Преобразование слабой сущности
Преобразование подтипов сущностей
1 способ. Создается одна таблица, в которую помещают все атрибуты. Для того, чтобы указать, к какому подтипу относится объект, приходится вводить дополнительное поле-признак: Сущность1(Ключ, Атрибут1, Атрибут2, Атрибут3, Атрибут4, Атрибут4, Признак).
Недостатком этого способа является то, что в таблице остается много незаполненных полей: для объекта подтипа 1 атрибуты 4 и 5, а для объекта подтипа 2 - атрибуты 2 и 3 останутся пустыми.
2 способ. Создается отдельная таблица для каждого подтипа. В нее включаются все атрибуты этого подтипа и все атрибуты надтипа:
Подтип1(Ключ, Атрибут1, Атрибут2, Атрибут3)
Подтип2(Ключ, Атрибут1, Атрибут4, Атрибут5)
Недостатком этого подхода является то, что подтипы теперь никак не связаны друг с другом.
3 способ. Создается одна таблица для надтипа, и по одной таблице для каждого подтипа, в которую включаются ключевые поля надтипа:
Сущность1(Ключ, Атрибут1)
Подтип1(Ключ, Атрибут2, Атрибут3)
Подтип2(Ключ, Атрибут4, Атрибут5)
Недостатком этого подхода является то, что информация о каждом объекте теперь раскидана по двум таблицам.
Рис. 5 – Преобразование подтипов сущностей
Связь М:М
Преобразование связей
Для связей – двойных ромбов ничего делать не нужно, вся информация уже хранится в таблице слабой сущности.
Рис. 6 – Связь М:М
Создается новая таблица, содержащая ключевые поля каждой сущности, участвующей в связи, и собственные атрибуты связи, если таковые имеются. В названии обычно отражают, какие именно сущности связываются, или называют новую таблицу именем связи.
Сущность1Сущность2(Ключ1, Ключ2, Атрибут1).
Если собственный атрибут связи является ключевым, то на самом деле это уже не бинарная связь, а связь большей арности, т.е. этот атрибут может быть заменен на новую сущность, по направлению к которой существует связь "к одному". В этом случае нужно применять правила для тернарных и других связей
Связь 1:М
Рис. 7 – Связь 1:М
1 способ. Точно так же, как и в случае М:М, создается новая таблица, содержащая ключевые поля каждой сущности, участвующей в связи. В названии обычно отражают, какие именно сущности связываются, или называют новую таблицу именем связи. Ключом будет ключ второй сущности.
Сущность1Сущность2(Ключ1, Ключ2).
2 способ. Новая таблица не создается, а в таблицу дочерней сущности добавляют ключевые поля родительской сущности (в ключ дочерней сущности они входить не будут). Ключевые поля родительской сущности представляют собой внешний ключ (foreign key) для дочерней сущности.
Этот способ предпочтительнее использовать в том случае, если связь является связью "ровно к одному", то есть все экземпляры сущностей участвуют в связи. В этом случае поле внешнего ключа никогда не будет пустым.
Таблица дочерней сущности: Сущность2(Ключ2, Атрибут1, Ключ1).
Связь 1:1
Рис. 8 – Связь 1:1
1 способ. Точно так же, как и в случае М:М, создается новая таблица, содержащая ключевые поля каждой сущности, участвующей в связи. В названии обычно отражают, какие именно сущности связываются, или называют новую таблицу именем связи. Ключом будет ключ любой сущности.
Этот способ предпочтительнее использовать в том случае, если связь не является "ровно к одному", то есть не все экземпляры сущностей участвуют в связи.
Сущность1Сущность2(Ключ1, Ключ2) или Сущность1Сущность2(Ключ1, Ключ2).
2 способ. Точно так же, как и во 2 случае 1:М, новая таблица не создается, а в таблицу одной из сущностей (будем считать ее дочерней) добавляют ключевые поля другой сущности (будем считать ее родительской).
Если связь не является связью "ровно к одному" по отношению к родительской таблице, то есть не все экземпляры сущностей участвуют в связи, поле внешнего ключа в некоторых записях может быть пустым.
Таблица дочерней сущности: Сущность1(Ключ1, Атрибут1, Ключ2),
или Сущность2(Ключ2, Атрибут2, Ключ1).
3 способ. Две таблицы для сущностей, связанных 1:1, объединяются в одну. Ключом новой таблицы может быть комбинация ключей обеих таблиц. Если хотя бы в одном направлении связь "ровно к одному", то ключ этой сущности можно считать ключом объединенной таблицы.
Таблицы: Сущность1(Ключ1, Атрибут1) и Сущность2(Ключ2, Атрибут2) заменяются на
Сущность1Сущность2(Ключ1, Атрибут1, Ключ2, Атрибут2)
или, возможно, Сущность1Сущность2(Ключ1, Атрибут1, Ключ2, Атрибут2),
или Сущность1Сущность2(Ключ1, Атрибут1, Ключ2, Атрибут2).
Для связи сущности с самой собой применяются те же правила, но, так как одна и та же сущность участвует в связи дважды, ключевые поля должны войти в одну и ту же таблицу два раза. Поэтому приходится переименовывать один из ключей.
Рассмотрим связь 1:M, способ 2. Переименован внешний ключ.
Рис. 9 – Связь 1:М, переименован внешний ключ
Сущность1(Ключ1, Атрибут1, ЕщеОдинКлюч1).
Для связей с арностью более 2 обычно применяется тот же способ, что и для бинарной связи M:M - создается новая таблица, содержащая ключевые поля всех связанных таблиц: Сущность1Сущность2Сущность3(Ключ1, Ключ2, Ключ3).
Правила преобразования ER-модели в реляционную
Правило 1. Каждой сущности ставится в соответствие отношение реляционной модели данных. При этом имена сущности и отношения могут быть различными, потому что на имена сущностей могут не накладываться дополнительные синтаксические ограничения, кроме уникальности имени в рамках модели. Имена отношений могут быть ограничены требованиями конкретной СУБД, чаще всего эти имена являются идентификаторами в некотором базовом языке, они ограничены по длине и не должны содержать пробелов и некоторых специальных символов. Например, сущность может быть названа «Книжный каталог», а соответствующее ей отношение желательно назвать, например, BOOKS (без пробелов и латинскими буквами).
Правило 2. Каждый атрибут сущности становится атрибутом соответствующего отношения. Для каждого атрибута задается конкретный допустимый в СУБД тип данных и обязательность или необязательность данного атрибута (то есть допустимость или недопустимость NULL значений для него).
Правило 3. Первичный ключ сущности становится PRIMARY KEY соответствующего отношения. Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство обязательности (NOT NULL).
Правило 4. В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности.
В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом (FOREING KEY).
Для моделирования необязательного типа связи на физическом уровне у атрибутов, соответствующих внешнему ключу, устанавливается свойство допустимости неопределенных значений (признак NULL). При обязательном типе связи атрибуты получают свойство отсутствия неопределенных значений (признак NOT NULL).
Теория нормализации
Нормализация отношений (таблиц) – одна из основополагающих частей теории реляционных баз данных. Нормализация имеет своей целью избавиться от избыточности в отношениях и модифицировать их структуру таким образом, чтобы процесс работы с ними не был обременён различными посторонними сложностями. При игнорировании такого подхода эффективность проектирования стремительно снижается, что вкупе с прочими подобными вольностями может привести к критическим последствиям.
Первая нормальная форма
Отношение находится в первой нормальной форме (сокращённо 1НФ), если все его атрибуты атомарны, то есть если ни один из его атрибутов нельзя разделить на более простые атрибуты, которые соответствуют каким-то другим свойствам описываемой сущности.
Будем называть исходное отношение основным, а значение неатомарного атрибута – подчинённым.
Для того, чтобы нормализовать исходное отношение, атрибуты которого неатомарны, необходимо объединить схемы основного и подчинённого отношений. Кроме того, если, например, таблица, соответствующая ненормализованному отношению уже содержится в БД и заполнена информацией, задача усложняется тем, что значение неатомарного атрибута может в свою очередь содержать несколько кортежей.
Рассмотрим отношение, имеющее атрибуты «Код сотрудника», «ФИО», «Должность», «Проекты». Очевидно, что один сотрудник может работать над несколькими проектами. Предположим, что проект описывается идентификатором, названием и датой сдачи.
Код сотрудника
ФИО
Должность
Проекты
Иванов Иван Иванович
Программист
ID: 123; Название: Система управления паровым котлом; Дата сдачи: 30.09.2011
ID: 231; Название: ПС для контроля и оповещения о превышениях ПДК различных газов в помещении; Дата сдачи: 30.11.2011
ID: 321; Название: Модуль распознавания лиц для защитной системы; Дата сдачи: 01.12.2011
Нетрудно заметить, что не все атрибуты этого отношения атомарны (неделимы). В частности, атрибут «Проекты» можно разделить на три более простых атрибута: «Код проекта», «Название», «Дата сдачи», а значение этого атрибута для сотрудника Иван Иванович Иванов содержит несколько кортежей – информацию о трёх проектах.
Рассмотрим алгоритм нормализации отношения до 1НФ.
Создать новое отношение, схема которого будет получена путём слияния основной и подчинённой схем исходного отношения в одну.
Для каждого кортежа исходного отношения включить в новое столько строк, сколько кортежей содержится в подчинённом отношении этого кортежа.
Заполнить значения атрибутов нового отношения, соответствующих атрибутам подчинённого отношения. Заполнить строки нового отношения значениями атомарных атрибутов исходного.
Применим этот алгоритм к приведённому выше отношению. Схема нового отношения будет состоять из 6 атрибутов: «Код сотрудника», «ФИО», «Должность», «Код проекта», «Название», «Дата сдачи». Для одного единственного кортежа заданного отношения, добавим в новое три строки, по одной для каждого проекта (по количеству кортежей в подчинённом отношении). Теперь можно заполнить значения разделенных атрибутов кортежами из подчинённого отношения. Затем перенесем в каждую из этих строк значения атомарных атрибутов: «Код сотрудника», «ФИО», «Должность» (все три строки будут содержать одинаковые значения этих атрибутов).
Результат будет выглядеть так:
Код сотрудника
ФИО
Должность
Код проекта
Название
Дата сдачи
Иванов Иван Иванович
Программист
123
Система управления паровым котлом
30.09.2011
Иванов Иван Иванович
Программист
231
ПС для контроля и оповещения о превышениях ПДК различных газов в помещении
30.11.2011
Иванов Иван Иванович
Программист
321
Модуль распознавания лиц для защитной системы
01.12.2011
Вторая нормальная форма
Отношение, находящееся в 1НФ, также может обладать избыточностью. Для её устранения предназначена вторая нормальная форма. Но прежде чем приступить к её описанию, сначала следует выявить недостатки первой.
Пусть исходное отношение содержит информацию о поставке некоторых товаров и их поставщиках.
Код поставщика
Город
Статус города
Код товара
Количество
Москва
300
Москва
400
Москва
100
Ярославль
200
Ставрополь
300
Ставрополь
400
Псков
100
Заранее известно, что в этом отношении содержатся следующие функциональные зависимости:
{ {Код поставщика, Код товара} -> { Количество},
{Код поставщика} -> {Город},
{Код поставщика} -> {Статус},
{Город} -> {Статус} }
Первичный ключ в отношении: {Код поставщика, Код товара}.
Очевидно, что отношение обладает избыточностью: оно описывает две сущности – поставку и поставщика. В связи с этим возникают следующие аномалии:
Аномалия вставки. В отношение нельзя добавить информацию о поставщике, который ещё не поставил ни одного товара.
Аномалия удаления. Если от поставщика была только одна поставка, то при удалении информации о ней будет удалена и вся информация о поставщике.
Аномалия обновления. Если необходимо изменить какую-либо информацию о поставщике (например, поставщик переехал в другой город), то придётся изменять значения атрибутов во всех записях о поставках от него.
Физический смысл избыточности исходного отношения заключается в том, что оно описывает не одну сущность, а две – поставку и поставщика.
Чтобы устранить эти аномалии, необходимо разбить исходное отношение на проекции:
В первую следует включить первичный ключ и все неключевые атрибуты явно зависимые от него;
В остальные проекции (в данном случае она одна) будут включены неключевые атрибуты, зависящие от первичного ключа неявно, вместе с той частью первичного ключа, от которой эти атрибуты зависят явно.
В итоге будут получены два отношения:
Код поставщика
Код товара
Количество
300
400
100
200
300
400
100
Первому отношению теперь соответствуют следующие функциональные зависимости: {Код поставщика, Код товара} -> {Количество}
Код поставщика
Город
Статус города
Москва
Ярославль
Ставрополь
Псков
Второму отношению соответствуют:
{ {Код поставщика} -> {Город},
{Код поставщика} -> {Статус},
{Город} -> {Статус} }
Такое разбиение устранило аномалии, описанные выше: можно добавить информацию о поставщике, который ещё не поставлял товар, удалить информацию о поставке без удаления информации о поставщике, а также легко обновить информацию в случае если поставщик переехал в другой город.
Определение второй нормальной формы: отношение находится во второй нормальной форме (сокращённо 2НФ) тогда и только тогда, когда оно находится в первой нормальной форме и каждый его неключевой атрибут неприводимо зависим от первичного ключа.
Семантическое моделирование
Широкое распространение реляционных СУБД и их использование в самых разнообразных приложениях показывает, что реляционная модель данных достаточна для моделирования предметных областей. Однако проектирование реляционной базы данных в терминах отношений на основе кратко рассмотренного нами механизма нормализации часто представляет собой очень сложный и неудобный для проектировщика процесс.
При этом проявляется ограниченность реляционной модели данных в следующих аспектах:
Модель не предоставляет достаточных средств для представления смысла данных. Семантика реальной предметной области должна независимым от модели способом представляться в голове проектировщика. В частности, это относится к упоминавшейся нами проблеме представления ограничений целостности.
Для многих приложений трудно моделировать предметную область на основе плоских таблиц. В ряде случаев на самой начальной стадии проектирования проектировщику приходится производить насилие над собой, чтобы описать предметную область в виде одной (возможно, даже ненормализованной) таблицы.
Хотя весь процесс проектирования происходит на основе учета зависимостей, реляционная модель не предоставляет каких-либо средств для представления этих зависимостей.
Несмотря на то, что процесс проектирования начинается с выделения некоторых существенных для приложения объектов предметной области ("сущностей") и выявления связей между этими сущностями, реляционная модель данных не предлагает какого-либо аппарата для разделения сущностей и связей.
Потребности проектировщиков баз данных в более удобных и мощных средствах моделирования предметной области вызвали к жизни направление семантических моделей данных. При том, что любая развитая семантическая модель данных, как и реляционная модель, включает структурную, манипуляционную и целостную части, главным назначением семантических моделей является обеспечение возможности выражения семантики данных.
Наиболее часто на практике семантическое моделирование используется на первой стадии проектирования базы данных. При этом в терминах семантической модели производится концептуальная схема базы данных, которая затем вручную преобразуется к реляционной (или какой-либо другой) схеме. Этот процесс выполняется под управлением методик, в которых достаточно четко оговорены все этапы такого преобразования.
Менее часто реализуется автоматизированная компиляция концептуальной схемы в реляционную. При этом известны два подхода: на основе явного представления концептуальной схемы как исходной информации для компилятора и построения интегрированных систем проектирования с автоматизированным созданием концептуальной схемы на основе интервью с экспертами предметной области. И в том, и в другом случае в результате производится реляционная схема базы данных в третьей нормальной форме (более точно следовало бы сказать, что автору неизвестны системы, обеспечивающие более высокий уровень нормализации).
Наконец, третья возможность, которая еще не вышла (или только выходит) за пределы исследовательских и экспериментальных проектов, - это работа с базой данных в семантической модели, т.е. СУБД, основанные на семантических моделях данных. При этом снова рассматриваются два варианта: обеспечение пользовательского интерфейса на основе семантической модели данных с автоматическим отображением конструкций в реляционную модель данных (это задача примерно такого же уровня сложности, как автоматическая компиляция концептуальной схемы базы данных в реляционную схему) и прямая реализация СУБД, основанная на какой-либо семантической модели данных. Наиболее близко ко второму подходу находятся современные объектно-ориентированные СУБД, модели данных которых по многим параметрам близки к семантическим моделям (хотя в некоторых аспектах они более мощны, а в некоторых - более слабы).
Расширенная ER-модель (EER-модель)
Понятий обычной ER-модели достаточно для представления большинства схем баз данных, например, для большинства коммерческих систем БД. Однако такие области, как системы автоматизированного проектирования, системы автоматизированной подготовки производства и др. предъявляют более сложные требования к БД. Для их семантического моделирования ER-модель была дополнена новыми понятиями и трансформирована в EER-модель (Enhanced ER – model – расширенная модель «сущность–связь»). Такая модель содержит все элементы ER – модели плюс дополнительные понятия, а именно понятия генерализации, специализации, и агрегирования.
Генерализация – это объединение набора классов (типов) сущностей в более общий тип сущности – суперкласс. Если в процессе анализа сущностей обнаруживается, что два или более классов (типов) сущностей имеют общие наборы атрибутов, то такие классы можно объединить в суперкласс.
Специализация противоположна генерализации. Она заключается в том, что некоторый общий (агрегированный, суперкласс) класс или тип разделяется на несколько более частных (специализированных) подклассов.
Агрегирование – это процесс объединения нескольких независимых сущностей (типов) в агрегированный (комплексный) тип.
Концептуальные ER-модели
В соответствии с основными этапами проектирования базы данных после построения концептуальной модели выбирается система управления базой данных, с помощью которой будет организована база данных и работа с ней. Каждая СУБД поддерживает определенные виды и типы данных, а также средства представления связей между данными, составляющими модель данных СУБД. Вторая стадия проектирования базы данных состоит в представлении построенной на предыдущей стадии концептуальной модели средствами модели данных СУБД или в отображении концептуальной модели в модель данных СУБД. Этот этап часто называют логическим проектированием базы данных. Полученная при этом модель часто также называется концептуальной моделью или схемой, но специфицированной к понятиям модели данных СУБД. В некоторых источниках полученную модель называют логической структурой данных или моделью данных базы данных.
Можно по-разному характеризовать понятие модели данных СУБД. С одной стороны, модель данных СУБД – это способ структурирования данных, которые рассматриваются как некоторая абстракция в отрыве от предметной области. С другой стороны, модель данных СУБД – это инструмент представления концептуальной модели предметной области и динамики ее изменения в виде базы данных.
Учитывая обе вышеуказанные стороны, определим основные структуры моделей данных СУБД, используемые для представления концептуальной модели предметной области (сущностей, атрибутов, связей).
Элемент данных (поле) – наименьшая поименованная единица данных. Используется для представления значения атрибута.
С элементом данных неразрывно связано понятие «тип данных», который может принимать соответствующее поле. В разных СУБД могут использоваться разные типы данных, наиболее распространенными из которых, используемые во многих СУБД, являются следующие: числовой (numeric), символьный (char), дата (date) и т.д.
Запись – поименованная совокупность полей. Используется для представления совокупности атрибутов сущности (записи о сущности).
Экземпляр записи – запись с конкретными значениями полей.
Первичный ключ – минимальный набор полей записи, однозначно идентифицирующий экземпляр записи файла.
Файл – поименованная совокупность экземпляров записей одного типа. Используется для представления однородного набора сущностей.
Набор файлов – поименованная совокупность файлов, обрабатываемых в системе. Используется для представления нескольких наборов сущностей.
Понятие «группа» является обобщающим понятием «файл» и «запись».
Группа – это поименованная совокупность элементов данных и других групп.
Важнейшим понятием концептуальной модели является понятие связи между сущностями (наборами сущностей). В моделях данных СУБД соответствующее понятие отражается понятием «групповое отношение».
Групповое отношение – поименованное бинарное отношение, заданное на двух множествах экземпляров рассматриваемых групп. По характеру бинарных связей различают групповые отношения вида 1:1, 1:M, M:1, M:N. Пары чисел называют коэффициентами группового отношения. В групповом отношении один член группы назначается владельцем отношения, другой – членом.
Для представления группового отношения используется две формы:
а) Графовая. Группы изображаются вершинами графа, связи между группами – дугами, направленными от группы-владельца к группе-члену с указанием имени отношения и коэффициента.
По типу графов различают:
иерархическую модель (граф без циклов – дерево);
сетевую модель (ориентированный граф общего вида).
б) Табличная. Связь между группами изображается таблицей, столбцы которой представляют ключи соответствующих групп. Для формального описания таблицы используется математическое (теоретико-множественное) понятие отношения. Соответствующая модель данных называется реляционной моделью.
Примеры ER-моделей
Пример 1
ER-модель: ЖЭК
Описание задачи: Сотрудникам ЖЭКа необходима база данных для хранения информации о поступающих от жильцов заявок на ремонт. ЖЭК обслуживает группу домов, включающую несколько улиц. Заявка поступает от квартиры. Заявку принимает диспетчер, он задает номер и дату поступления заявки, определяет тип заявки и срок ее выполнения. Заявку выполняет бригада специалистов. Каждый специалист может работать только в одной бригаде, у каждой бригады есть бригадир.
Рис. 10 – Пример ER-модели ЖЭКа
Пример 2
ER -модель конторы «Рога и копыта»
Описание задачи: Контора «Рога и копыта» занимается коммерческой деятельностью по реализации продукции, произведенной из рогов и копыт, и предоставлению магических услуг.
Сотрудник организации имеет ФИО, табельный номер, должность. Сотрудники распределены по нескольким отделам. Каждый отдел имеет номер, название и руководителя. Сотрудник не может руководить более чем одним отделом.
Организация работает с предприятиями-клиентами. Каждое предприятие имеет название и адрес. С предприятием может быть заключено несколько договоров.
Договор характеризуется уникальным номером, датой и типом. Каждый договор курирует некоторый сотрудник. По мере реализации клиенту товаров и услуг по договору с некоторой периодичностью выставляются счета.
Счет характеризуется уникальным номером, датой выставления, сроком оплаты и суммой, а также списком реализованных товаров и услуг с указанием их количества. По неоплаченным счетам начисляются пени. Счет может быть оплачен в несколько приемов, каждый платеж характеризуется номером, датой и суммой. Номер платежа уникален в пределах его счета. Цены на товары и услуги могут изменяться со временем.
Рис. 11 – Пример ER-модели конторы «Рога и копыта»
Пример разработки простой ER-модели
При разработке ER-моделей мы должны получить следующую информацию о предметной области:
1. Список сущностей предметной области.
2. Список атрибутов сущностей.
3. Описание взаимосвязей между сущностями.
ER-диаграммы удобны тем, что процесс выделения сущностей, атрибутов и связей является итерационным. Разработав первый приближенный вариант диаграмм, мы уточняем их, опрашивая экспертов предметной области. При этом документацией, в которой фиксируются результаты бесед, являются сами ER-диаграммы.
Предположим, что перед нами стоит задача разработать информационную систему по заказу некоторой оптовой торговой фирмы. В первую очередь мы должны изучить предметную область и процессы, происходящие в ней. Для этого мы опрашиваем сотрудников фирмы, читаем документацию, изучаем формы заказов, накладных и т.п.
Например, в ходе беседы с менеджером по продажам, выяснилось, что он (менеджер) считает, что проектируемая система должна выполнять следующие действия:
Хранить информацию о покупателях.
Печатать накладные на отпущенные товары.
Следить за наличием товаров на складе.
Выделим все существительные в этих предложениях - это будут потенциальные кандидаты на сущности и атрибуты, и проанализируем их (непонятные термины будем выделять знаком вопроса):
Покупатель - явный кандидат на сущность.
Накладная - явный кандидат на сущность.
Товар - явный кандидат на сущность
(?) Склад - а вообще, сколько складов имеет фирма? Если несколько, то это будет кандидатом на новую сущность.
(?) Наличие товара – это, скорее всего, атрибут, но атрибут какой сущности?
Сразу возникает очевидная связь между сущностями - "покупатели могут покупать много товаров" и "товары могут продаваться многим покупателям". Первый вариант диаграммы выглядит так:
Рис. 12 – Первый вариант ER-диаграммы
Задав дополнительные вопросы менеджеру, мы выяснили, что фирма имеет несколько складов. Причем, каждый товар может храниться на нескольких складах и быть проданным с любого склада.
Куда поместить сущности "Накладная" и "Склад" и с чем их связать? Спросим себя, как связаны эти сущности между собой и с сущностями "Покупатель" и "Товар"? Покупатели покупают товары, получая при этом накладные, в которые внесены данные о количестве и цене купленного товара. Каждый покупатель может получить несколько накладных. Каждая накладная обязана выписываться на одного покупателя. Каждая накладная обязана содержать несколько товаров (не бывает пустых накладных). Каждый товар, в свою очередь, может быть продан нескольким покупателям через несколько накладных. Кроме того, каждая накладная должна быть выписана с определенного склада, и с любого склада может быть выписано много накладных. Таким образом, после уточнения, диаграмма будет выглядеть следующим образом:
Рис. 12 – Второй вариант ER-диаграммы
Теперь необходимо задуматься об атрибутах сущностей. Выясняется следующее:
Каждый покупатель является юридическим лицом и имеет наименование, адрес, банковские реквизиты.
Каждый товар имеет наименование, цену, а также характеризуется единицами измерения.
Каждая накладная имеет уникальный номер, дату выписки, список товаров с количествами и ценами, а также общую сумму накладной. Накладная выписывается с определенного склада и на определенного покупателя.
Каждый склад имеет свое наименование.
Снова выпишем все существительные, которые будут потенциальными атрибутами, и проанализируем их:
Юридическое лицо – термин риторический, мы не работаем с физическими лицами. Не обращаем внимания.
Наименование покупателя – явная характеристика покупателя.
Адрес – явная характеристика покупателя.
Банковские реквизиты – явная характеристика покупателя.
Наименование товара – явная характеристика товара.
(?) Цена товара – похоже, что это характеристика товара. Отличается ли эта характеристика от цены в накладной?
Единица измерения – явная характеристика товара.
Номер накладной – явная уникальная характеристика накладной.
Дата накладной – явная характеристика накладной.
(?) Список товаров в накладной – список не может быть атрибутом. Вероятно, нужно выделить этот список в отдельную сущность.
(?) Количество товара в накладной – это явная характеристика, но характеристика чего? Это характеристика не просто "товара", а "товара в накладной".
(?) Цена товара в накладной – опять же это должна быть не просто характеристика товара, а характеристика товара в накладной. Но цена товара уже встречалась выше – это одно и то же?
Сумма накладной – явная характеристика накладной. Эта характеристика не является независимой. Сумма накладной равна сумме стоимостей всех товаров, входящих в накладную.
Наименование склада – явная характеристика склада.
Каждый товар имеет некоторую текущую цену. Эта цена, по которой товар продается в данный момент. Естественно, что эта цена может меняться со временем. Цена одного и того же товара в разных накладных, выписанных в разное время, может быть различной. Таким образом, имеется две цены - цена товара в накладной и текущая цена товара.
С возникающим понятием "Список товаров в накладной" все довольно ясно. Сущности "Накладная" и "Товар" связаны друг с другом отношением типа много-ко-многим. Такая связь должна быть расщеплена на две связи типа один-ко-многим. Для этого требуется дополнительная сущность. Этой сущностью и будет сущность "Список товаров в накладной". Связь ее с сущностями "Накладная" и "Товар" характеризуется следующими фразами - "каждая накладная обязана иметь несколько записей из списка товаров в накладной", "каждая запись из списка товаров в накладной обязана включаться ровно в одну накладную", "каждый товар может включаться в несколько записей из списка товаров в накладной", " каждая запись из списка товаров в накладной обязана быть связана ровно с одним товаром". Атрибуты "Количество товара в накладной" и "Цена товара в накладной" являются атрибутами сущности " Список товаров в накладной".
Точно также поступим со связью, соединяющей сущности "Склад" и "Товар". Введем дополнительную сущность "Товар на складе". Атрибутом этой сущности будет "Количество товара на складе". Таким образом, товар будет числиться на любом складе и количество его на каждом складе будет свое.
Теперь можно внести все это в диаграмму:
Рис. 13 – Третий (итоговый) вариант ER-диаграммы
Список литературы:
Информационные системы в экономике: Учебник для студ. высш. учеб, заведений / В.Б. Уткин, К.В. Балдин. – М.: Издательский центр «Академия», 2004. – 288 с.
Разработка и эксплуатация автоматизированных информационных систем: учеб. пособие / Под ред. проф. Л.Г. Гагариной. – М.: ИД «ФОРУМ»: ИНФРА-М, 2007. – 384 с.: ил. – (Профессиональное образование).
Дейт К. Введение в системы баз данных. – М.: Диалектика, 2000.
Першиков В. И., Савинков В. М. Толковый словарь по информатике. – М.: Финансы и статистика, 2001.
Райордан Р. Основы реляционных баз данных. – М.: Русская редакция, 2001.
Саукап Р. Проектирование реляционных систем баз данных. – М.: Русская редакция, 2006.
Системы управления базами данных и знаниями / Под ред. А. Н. Наумова. – М.: Финансы и статистика, 2005.
Спортак М., Паппас Ф. Компьютерные сети и сетевые технологии. – Киев: ООО «ТИД «ДС», 2002.
Уткин В. Б. Основы автоматизации профессиональной деятельности. – М.: РДЛ, 2001.
Уткин В. Б., Сазанович А.Н., Мдичарадзе В. Г. Информатика. – М.: РДЛ, 2007.
MegaPlus: Электроника, компьютеры, связь.2010. – № 5.