Создать er и uml диаграммы данных. Er-диаграммы
При построении моделей информационных систем важнейшей методикой является ER-моделирование или построение диаграмм сущность-связь. Сущность представляет собой класс одинаковых по смыслу элементов, используемых в информационной системе. Сущность всегда должна иметь имя.
Сущности представлены на модели информационной системы при помощи экземпляров. Экземпляр - конкретный объект представляющий заданную сущность. Приведем пример: экземпляром сущности «Ученик» будет являться «Ученик Сидоров».
В рамках построения информационной системы объекты имеют различные атрибуты. Обычно их бывает один или несколько. Атрибут - свойство, присущее данной сущности. Приведем пример для нашей сущности «Ученик»: «Фамилия», «Имя», «Отчество», «Класс».
Набор различных атрибутов, имеющих значения, определенные особенными для всех экземпляров объекта, называют ключом сущности. В нашей ситуации если удалить атрибут - нарушится его уникальность, именно этим достигается неизбыточность. Объекты взаимодействуют друг с другом посредством связей. Связи объектов - метод взаимодействия двух элементов информационной системы. Объекты обычно связаны как с другими объектами ИС. Связи объектов обеспечивают возможность нахождения требуемых элементов при помощи установления их отношений с изначальными. Выглядит связь обычно в виде стрелки или линии, соединяющей различные сущности или соединяющая саму себя.
Различают три типа связей:
- 1) 1-к-1. В данном виде связи экземпляр первого объекта связан с одним экземпляром второго объекта. Как правило, от таких связей следует отказаться;
- 2) 1-к-n. При такой связи один экземпляр первого объекта связан с некоторыми экземплярами второго объекта. В информационных системах это наиболее часто встречаемый вид связи. При такой структуре первый объект называется родительской сущностью, а второй - дочерней.
- 3) n-к-n. При такой связи несколько экземпляров первого объекта связано с несколькими экземплярами второго объекта. На практике это означает, что система находится в промежуточном этапе разработки и при дальнейшем анализе данный вид связи будет заменен на 1-к-n с созданием промежуточных сущностей и переназначением связей.
Принципиально отличие создает модальность при использование связей. В случае если объект «Может» быть связан с другим, то это представляет ему возможность иметь взять с различными экземплярами другого объекта, но при этом он не обязан иметь связь. В другой ситуации, если объект «Должен» иметь связь с экземпляром другого объекта, то он обязан иметь не меньше одной связи. При проведении моделирования информационной системы при помощи ER-нотации необходимо провести анализ предметной области с целью построения следующих графических данных:
- 1) Списка объектов;
- 2) Списка связанных атрибутов объектов;
- 3) Построения корректных взаимосвязей между различными объектами.
При построении диаграмм в нотации ER, процесс моделирования носит итерационный характер. После использования функции обратной разработки или выделения приблизительной модели ее процесс преобразования и улучшения может занимать продолжительное время, а сама модель может дополняться и уточняться в соответствии с полученными новыми данными. Существует два принципиально различающихся вида ER диаграмм:
- 1) Концептуальные;
- 2) Физические.
На примере, описанном на рис. 11 мы можем видеть модель концептуальную модель торгового предприятия описанную в нотации ER. Такая модель описывает связи между различными сущностями данной информационной системы, однако не учитывает особенностей базы данных, а следовательно не может быть использована для дальнейшего компьютерного проектирования. Концептуальные модели используются для дальнейшей постройки физических диаграмм, которая уже включает в себя наименования таблиц, поля, типы различных переменных. Изображенная на рисунке концептуальная модель отображает все объекты данной информационной системы и устанавливает их связи.
После преобразования мы видим, что данная физическая диаграмма теперь передает информацию о ключах, помимо того, что определят связь между ее объектами. Каждая таблица хранит в себе представление о типе передаваемых и хранимых данных. Данная нотация ER диаграмм наиболее близка к стандартному отображению баз данных. В данном представлении таблицы содержат в себе список связанных с объектом атрибутов. Такое представление позволяет быстро переходить от разработки модели к программному коду SQL и обратно при помощи функций обратного разработчика. В данной ситуации мы имеет дело с семантическим моделированием посредством использования диаграмм сущность-связь. Подобные диаграммы дают нам широкое представление о разрабатываемой информационной системе, а визуализация позволяет упростить процесс группировки элементов и приведение базы данных к требуемому каноническому виду. Преимущество физических диаграмм над концептуальными моделями очевидно, поэтому многие современные инструментальные средства моделирования позволяют переходить от одной формы представления к другой моментально. Концептуальные модели требуются тогда, когда глубинный анализ базы данных не требуется, а для модернизации системы достаточно понять и изменить логику связи ее элементов .
0(Лекция 8)
Разработка концептуального уровня БД
Целью данного этапа является последовательная разработка концептуальной информационно-логической модели предметной области, отражающей логику информации предприятия и даталогической модели базы данных.
Инфологическая модель предметной области
Исходными данными для построения ИЛМ предметной области являются результаты анализа предметной области, представленные в виде описания классов объектов и связей между ними. Чаще всего ИЛМ предметной области представляют в терминах семантической модели данных, в виде ER - диаграммы предметной области.
Необходимо отметить, что выявление в предметной области классов объектов, связей, описание и отображение их в диаграмме происходит параллельно.
Методологии построения ER-диаграмм
В настоящее время существуют разнообразные методологий (нотации) построения ER-модели.
1 Методология Питера Чена. В 1976 году Питером Ченом была предложена семантическая модель "сущность-связь" - ER-модель, которая в настоящее время стала самой распространенной.
Соглашения, используемые при изображении диаграммы:
Классы объектов отображаются прямоугольником, свойства эллипсами, связи ромбами;
Уникальный идентификатор (первичный ключ) отображается в виде эллипса, обведенного двойной линией;
Мощность связи «один» отображается линией, «много» - линией со стрелкой.
Особенности этой методологии:
Метод позволяет показать связь между двумя, тремя и более классами объектов (сущностями);
Связь может иметь собственные атрибуты;
Нет возможности отображения взаимоисключающих связей и непереносимости связей;
Взаимоисключающие связи неявно реализуются в виде супертипов и подтипов;
Нельзя выразить опциональность атрибутов и связей.
На рисунке 6 приведен пример фрагмента ER-диаграммы в методологии Питера Чена.
Рисунок 6 - Пример фрагмента ER-диаграммы в методологии Питера Чена
На диаграмме отображены следующие бизнес-правила предприятия: «Каждому заказу, имеющему такие свойства как номер и дата, должна соответствовать одна или более позиций заказа, имеющей такие свойства, как номер, цену за единицу товара, количество товара»; с другой стороны - «Каждая позиция товара должна относиться к одному и только одному заказу».
Необходимо отметить, что в примере приведен фрагмент описания предметной области. В ней также должны существовать такие классы объектов, как «Товар», «Единица измерения» и другие.
2 Методология IDEF1. Используется в CASE-средствах ERwin, Design/IDEF. В методологии используются следующие соглашения:
Каждому классу объектов присваивается уникальное имя и номер;
Обязательная связь отображается сплошной линией, необязательная -пунктирной;
Мощность связи "один" отображается линией, "много" - точкой;
Связь может дополнительно определяться с помощью указания мощности (типа) связи. Мощность может принимать следующие значения: N - ноль, один или более (принимается по умолчанию); Z - ноль или один, P - один или более.
Свойства класса объектов отображаются в виде списка имен внутри блока, отображающего класс объектов;
Атрибуты первичного ключа изображаются вверху и отделяются от других.
Пример представления ER-диаграммы в методологии IDEF1 приведен на рисунке 7.
Рисунок 7 - Пример представления ER-диаграммы в методологии IDEF1.
На рисунке 7 отображена та же ситуация в предметной области, что и на рисунке 6.
3 Методология Ричарда Баркера. Используемые в методологии элементы: класс объектов, свойство класса объектов, уникальные идентификаторы, опциональность свойств, связи, мощность (тип), опциональность и переносимость связей, уникальность объекта из связи, супертипы, подтипы, арки.
Используются следующие соглашения:
Класс объектов отображается в виде четырехугольника с закругленными углами. Имя класса объектов указывается внутри четырехугольника, это имя существительное в единственном числе, отображенное заглавными буквами;
Свойства записываются внутри четырехугольника, отображающего класс объектов строчными буквами, это имя существительное в единственном числе;
Четырехугольник, отображающий класс объектов, можно увеличивать до любых размеров, четырехугольники могут быть разных размеров;
Опциональность свойств помечается: обязательное свойство - звездочкой (*), необязательное - кружочком (о);
Уникальный идентификатор помечается #, если уникальных идентификаторов несколько, тогда каждый помечается номером, указанным в скобках, например, # (1), #(2);
Обязательная связь помечается сплошной линией, необязательная -пунктирной;
Тип (мощность) связи «один» помечается линией, «много» - «вороньей лапой».
Более сложные элементы, используемые в ER-диаграмме, построенной по методологии Ричарда Баркера, рассмотрим далее в примерах.
Шаблоны моделирования
Любая рассматриваемая предметная область имеет свои особенности. Но в тоже время обладает и общими для всех предметных областей элементами. Так, в основной массе решаемых задач автоматизации обязательно фигурируют такие классы объектов, как предприятие (организация), структурная единица предприятия (цех, отдел, факультет, отделение и т.п.), люди, или физические лица, разного рода материальные объекты. Все процессы, происходящие в предметной области и которые необходимо учитывать в базе данных, осуществляются на основе документов, которые в свою очередь фиксируют сбор, перемещение, расход каких- либо данных. Таким образом, многие ситуации можно смоделировать, применяя существующие шаблоны. Мы рассмотрим шаблоны моделирования на примере построения фрагментов ER - диаграмм по методологии Ричарда Баркера.
1 Моделирование семейного положения. Например, ситуацию предметной области, описанную следующими предложениями: «каждое ФИЗИЧЕСКОЕ ЛИЦО (мужского пола) может являться супругом другого ФИЗИЧЕСКОГО ЛИЦА (женского пола)» и, с обратной стороны, «каждое ФИЗИЧЕСКОЕ ЛИЦО (женского пола) может являться супругой другого ФИЗИЧЕСКОГО ЛИЦА (мужского пола», можно смоделировать, используя рекурсивную связь. Это связь между объектами одного класса объектов. Такая связь может обладать всеми свойствами, присущими любой другой связи. Пример приведен на рисунке 8. На рисунке 8 изображена рекурсивная связь, имеющая с обеих сторон одинаковый тип («один») и опциональность «необязательная». В методологии Ричарда Баркера на ER- диаграмме можно отображать и названия связей.
Рисунок - Пример рекурсивной связи - «необязательное свиное ухо»
2 Моделирование иерархии данных. Иерархия данных наблюдается, если в модели предметной области присутствует:
Произвольное число иерархий классов объектов;
Одинаковые свойства у классов объектов, входящих в иерархию;
Связи между такими классами объектов одинаковые.
На рисунке 9 представлен фрагмент ER-диаграммы, выполненный по методологии Ричарда Баркера и отображающий пример иерархии данных.
Рисунок - Пример иерархии данных
На любом предприятии организационная структура обычно бывает иерархическая. Так и в этом примере представлена организационная структура высшего учебного заведения. Классы объектов отображают структурные единицы вуза, располагающиеся на разных уровнях иерархической структуры подчинения. Классы объектов имеют одинаковые свойства, между классами объектов, расположенных на разных уровнях иерархии присутствуют одинаковые связи. Прочитав фрагмент такой предметной области, можно убедиться в её адекватности. Однако такое представление имеет некоторый недостаток - при добавлении ещё одного уровня иерархии, например, добавления структурной единицы «Лаборатория» в подчинение какой-либо кафедре потребует добавления ещё одного класса объектов в модель, то есть любое изменение в организационной структуре предприятия потребует корректировки модели.
Для моделирования подобной иерархии данных можно использовать шаблон модели - рекурсивную связь. При этом рекурсивная связь должна иметь тип 1:М и должна быть необязательной в обоих направлениях. Сторона «один» отображает правило «имеет в подчинении», сторона «много» - «подчиняется». Самый верхний элемент иерархии никому «не подчиняется», самый нижний элемент никого «не имеет в подчинении». Использование шаблона позволяет добавлять и удалять уровни иерархии в соответствии с требованиями предметной области, не меняя базовую модель.
Замена иерархии данных рекурсивной связью осуществляется по следующему алгоритму:
Создается один класс объектов, содержащий свойства, присущие каждому классу объектов в иерархии данных;
Классу объектов присваивается общее имя (в иерархии подчинения подразделений предприятия это может быть, например, класс объектов с именем «СТРУКТУРНАЯ ЕДИНИЦА ПРЕДПРИЯТИЯ»;
Создается дополнительный класс объектов, который будет отображать название для отличия каждого узла иерархии данных, например, класс объектов «ТИП СТРУКТУРНОЙ ЕДИНИЦЫ ПРЕДПРИЯТИЯ».
Как вывод, необходимо сделать следующие замечания:
Шаблон имеет один недостаток: классы объектов, находящиеся на всех уровнях иерархии должны иметь одинаковые свойства;
Иерархия, смоделированная как рекурсивная связь, должна быть необязательной в обоих направлениях. Обязательная ветвь, направленная вверх или вниз, создает бесконечную иерархию, не имеющую применения в реальном мире;
Если при преобразовании модели предметной области происходит слияние частей диаграммы в одну, то необходимо найти в предметной области класс объектов «ТИП», который позволит отобразить уникальность каждой части
Пример использования шаблона, моделирующего иерархию данных, приведен на рисунке.
Рисунок - Пример использования шаблон для моделирования иерархии данных.
3 Разрыв связей M:M. Наличие связи M:M в ER - диаграмме допустимо, но необходимо помнить, что это не адекватное отображение предметной области, есть предметная область не дообследована. Необходимо найти класс объектов (сущность), который разорвет такую связь. Как правило, это какой-либо документ, или позиция документа. Например, связь «многие ко многим» между классами объектов «ПОСТАВЩИК» и «ТОВАР» («каждый ПОСТАВЩИК может поставлять много ТОВАРОВ» и «каждый ТОВАР может поставляться разными ПОСТАВЩИКАМИ») может быть разорвана с помощью таких классов объектов, как «ПОЗИЦИЯ НАКЛАДНОЙ», «ПОЗИЦИЯ ПРАЙС - ЛИСТА», «ПОЗИЦИЯ ДОГОВОРА» и другие. На рисунке 11 приведен пример разрыва связи М:М. В роли поставщика в примере выступает юридическое лицо.
Рисунок - Разрыв связи М:М
Необходимо отметить, что классы объектов, разрывающие связь М:М, как правило, содержат свойства, значения которых динамически меняется. Это такие свойства, как «количество», «цена».
Разрыв рекурсивной связи М:М. (Моделирование сетевой структуры)
Такая структура очень распространена в предметной области на первых этапах поектировнаия. Пример 1
Каждый КОМПОНЕНТ может состоять из нескольких КОМПОНЕНТОВ Каждый КОМПОНЕНТ может входить в один или несколько КОМПОНЕНТОВ
Для моделирования использована необязательная рекурсивная связь типа М:М.
Каждое ЮРИДИЧЕСКОЕ ЛИЦО может пользоваться многими ЮРИДИЧЕСКИМИ ЛИЦАМИ для осуществления перевозок
Каждое ЮРИДИЧЕСКОЕ ЛИЦО может оказывать много услуг ЮРИДИЧЕСКИМ ЛИЦАМ по осуществлению перевозок.
Рекурсивную связь "многие_ко_многим" необходимо разбивать, т.к. негде разместить, например, такие свойства как "количество компонентов одного вида для сборки компонента более высокого уровня", "дата перевозки", "количество перевезенных вещей" и т.п., т.е. при более тщательном анализе предметной области можно увидеть такие классы объектов как "Правило сборки" и "Перевозка".
Каждое ПРАВИЛО СБОРКИ применяется к одному
КОМПОНЕНТ для сборки
Каждое ПРАВИЛО СБОРКИ применяется к одному КОМПОНЕНТ, входящему в сборку другого
КОМПОНЕНТ.
Каждый КОМПОНЕНТ может включать много ПРАВИЛО СБОРКИ для входящих в него компонентов.
Каждый Компонент может входить во много
ПРАВИЛО СБОРКИ.
Пример 2
Каждая ПЕРЕВОЗКА должна осуществляться ЮРИДИЧЕСКИМ ЛИЦОМ
Каждая ПЕРЕВОЗКА должна осуществляться для ЮРИДИЧЕСКОГО ЛИЦА Каждое ЮРИДИЧЕСКОЕ ЛИЦО может осуществлять много ПЕРЕВОЗОК Каждое ЮРИДИЧЕСКОЕ ЛИЦО может участвовать во многих ПЕРЕВОЗКАХ как клиент.
Параллельные связи м.б. разной опциональности и типа.
Замечание: с помощью рекурсивных связей моделируются сетевые структуры и их частные случаи
Иерархии.
4 Моделирование ролей. Под ролями человека или организации в предметной области понимаются должности, обязанности, прозвища. В разных классах объектов, представляющих роли объекты могут перекрывать, дублировать друг друга. Например, класс объектов «ВРАЧ» и класс объектов «ПАЦИЕНТ» отображают разные роли человека - один лечит, другой лечится. Но в случае, если врач становится пациентом в той же предметной области, то информация о нем должна быть отображена в классе объектов «ПАЦИЕНТ», два объекта в двух классах объектов будут информационно дублировать, перекрывать друг друга. Роли должны моделироваться с помощью связей, необходимо чтобы объект одного и того же класса объектов мог выступать в нескольких ролях.
Пример неправильного и правильного моделирования ролей приведен на рисунках.
Рисунок - Неправильное моделирование ролей
Рисунок - Правильное моделирование ролей
На рисунке с неправильным моделированием ролей классы объектов «ПОСТАВЩИК» и «ПОТРЕБИТЕЛЬ» выделены отдельно. При возникновении ситуации, что какое-то юридическое лицо станет выступать как в роли поставщика, так и в роли потребителя, модель будет неадекватно отображать предметную область - информация будет продублирована. Правильным моделированием ситуации будет выделение одного класса объектов «ЮРИДИЧЕСКОЕ ЛИЦО», а роли «поставщик» и «потребитель» отобразить в виде соответствующих связей (рисунок с правильным моделированием ролей).
Примеры предметных областей, где необходимо моделировать роли, приведены в таблице 9.
Таблица 9 - Примеры моделирования ролей.
|
Предметная область |
Неправильное моделирование |
Правильное моделирование |
|
Купля-продажа, поставка товара |
Классы объектов: ПОКУПАТЕЛЬ, ПРОДАВЕЦ, ПОСТАВЩИК |
Классы объектов: ЮРИДИЧЕСКОЕ ЛИЦО или ФИЗИЧЕСКОЕ ЛИЦО. Связи (роли): покупает, продает, поставляет |
|
Образовательное учреждение, обучение |
Классы объектов: АБИТУРИЕНТ, СТУДЕНТ, ПРЕПОДАВАТЕЛЬ, АСПИРАНТ |
Классы объектов: ФИЗИЧЕСКОЕ ЛИЦО, РАБОТА ФИЗИЧЕСКОГО ЛИЦА, ОБУЧЕНИЕ ФИЗИЧЕСКОГО ЛИЦА, ТИП ОБУЧЕНИЯ ФИЗИЧЕСКОГО ЛИЦА, ТИП ПЕРЕМЕЩЕНИЯ ФИЗИЧЕСКОГО ЛИЦА. Связи (роли): сдает документы, работает, обучается. |
|
Документооборот |
Классы объектов: ВХОДЯЩИЙ ДОКУМЕНТ, ИСХОДЯЩИЙ ДОКУМЕНТ, ПРИКАЗ, РАСПОРЯЖЕНИЕ |
Классы объектов: ДОКУМЕНТ, ПОЗИЦИЯ ДОКУМЕНТА, ТИП ДОКУМЕНТА, ТИП ПЕРЕМЕЩЕНИЯ ДОКУМЕНТА. Связи (роли): относится (к типу) |
На рисунке приведен фрагмент ER-диаграммы, отображающей предметную область «Кадры предприятия». Класс объектов «ПОЗИЦИЯ ПРИКАЗА О ПЕРЕМЕЩЕНИИ» отображает сведения о перемещениях сотрудников (физических лиц) на предприятии, класс объектов «ВИД ПЕРЕМЕЩЕНИЯ» - виды кадровых перемещений - прием, перевод, увольнение и тому подобное. Между классами объектов «ПРИКАЗ О ПЕРЕМЕЩЕНИИ» и «ПОЗИЦИЯ ПРИКАЗА О ПЕРЕМЕЩЕНИИ» присутствуют три связи, две из них - моделируют роли:
- «каждый ПРИКАЗ О ПЕРЕМЕЩЕНИИ должен быть подписан одним сотрудником, являющимся начальником отдела кадров, о чем есть соответствующая информация в классе объектов ПОЗИЦИЯ ПРИКАЗА О ПЕРЕМЕЩЕНИИ», начальник отдела кадров может подписывать много приказов»;
Рисунок - Пример моделирования ролей
- «каждый ПРИКАЗ О ПЕРЕМЕЩЕНИИ должен быть подписан одним сотрудником, являющимся руководителем предприятия, о чем есть соответствующая информация в классе объектов «ПОЗИЦИЯ ПРИКАЗА О ПЕРЕМЕЩЕНИИ», руководитель предприятия может подписывать много приказов».
Представленный на рисунке фрагмент описания предметной области можно назвать шаблоном, который может быть использован для отображения ситуации, когда какие-либо документы подписываются должностными лицами и в базе данных необходимо отслеживать историю - кто и когда из физических лиц и когда, находясь в той или иной должности, визировал тот или иной документ. Это важно, поскольку документы в предметной области отображают, как правило, перемещение (приход, расход) материальных и не материальных объектов (приход, расход товаров на склад, перемещение кадров, движение контингента больных, учет выпущенных в эфир передач и тому подобное).
Скачать лекцию: У вас нет доступа к скачиванию файлов с нашего сервера.
В реальном проектировании структуры базы данных применяется метод - так называемое, семантическое моделирование . Семантическое моделирование представляет собой моделирование структуры данных, опираясь на смысл этих данных. В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-Relationship ).
Первый вариант модели сущность-связь был предложен в 1976 г. Питером Пин-Шэн Ченом. В дальнейшем многими авторами были разработаны свои варианты подобных моделей (нотация Мартина, нотация IDEF1X, нотация Баркера и др.). Кроме того, различные программные средства, реализующие одну и ту же нотацию, могут отличаться своими возможностями. По сути, все варианты диаграмм сущность-связь исходят из одной идеи - рисунок всегда нагляднее текстового описания. Все такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями.
Мы опишем работу с ER-диаграммами близко к нотации Баркера, как довольно легкой в понимании основных идей. Данная глава является скорее иллюстрацией методов семантического моделирования, чем полноценным введением в эту область.
Основные понятия ER-диаграмм
Определение 1
: Сущность
- это класс однотипных объектов, информация о которых должна быть учтена в модели.
Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. Примерами сущностей могут быть такие классы объектов как "Поставщик", "Сотрудник", "Накладная". Каждая сущность в модели изображается в виде прямоугольника с наименованием:
Рис. 1
Определение 2
: Экземпляр сущности
- это конкретный представитель данной сущности.
Например, представителем сущности "Сотрудник" может быть "Сотрудник Иванов". Экземпляры сущностей должны быть различимы, т.е. сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности.
Определение 3
: Атрибут сущности
- это именованная характеристика, являющаяся некоторым свойством сущности.
Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными). Примерами атрибутов сущности "Сотрудник" могут быть такие атрибуты как "Табельный номер", "Фамилия", "Имя", "Отчество", "Должность", "Зарплата" и т.п. Атрибуты изображаются в пределах прямоугольника, определяющего сущность:
Рис. 2
Определение 4 : Ключ сущности - это неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности. Неизбыточность заключается в том, что удаление любого атрибута из ключа нарушается его уникальность. Сущность может иметь несколько различных ключей. Ключевые атрибуты изображаются на диаграмме подчеркиванием:
Рис. 3
Определение 5
: Связь
- это некоторая ассоциация между двумя сущностями. Одна сущность может быть связана с другой сущностью или сама с собою.
Связи позволяют по одной сущности находить другие сущности, связанные с нею. Например, связи между сущностями могут выражаться следующими фразами - "СОТРУДНИК может иметь несколько ДЕТЕЙ", "каждый СОТРУДНИК обязан числиться ровно в одном ОТДЕЛЕ". Графически связь изображается линией, соединяющей две сущности:
Рис. 4
Каждая связь имеет два конца и одно или два наименования. Наименование обычно выражается в неопределенной глагольной форме: "иметь", "принадлежать" и т.п. Каждое из наименований относится к своему концу связи. Иногда наименования не пишутся ввиду их очевидности.
Каждая связь может иметь один из следующих типов связи :
Рис. 5
Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой). Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две.
Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны "один") называется родительской , правая (со стороны "много") - дочерней . Характерный пример такой связи приведен на Рис. 4.
Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи много-ко-многим является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-многим путем создания промежуточной сущности.
Каждая связь может иметь одну из двух модальностей связи :
Рис. 6
Модальность "может
" означает, что экземпляр одной сущности может быть связан с одним или несколькими экземплярами другой сущности, а может быть и не связан ни с одним экземпляром.
Модальность "должен
" означает, что экземпляр одной сущности обязан быть связан не менее чем с одним экземпляром другой сущности.
Связь может иметь разную модальность с разных концов (как на Рис. 4). Описанный графический синтаксис позволяет однозначно читать диаграммы, пользуясь следующей схемой построения фраз:
<Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>
Каждая связь может быть прочитана как слева направо, так и справа налево. Связь на Рис. 4 читается так:
Слева направо: "каждый сотрудник может иметь несколько детей".
Справа налево: "Каждый ребенок обязан принадлежать ровно одному сотруднику".
Пример разработки простой ER-модели
При разработке ER-моделей мы должны получить следующую информацию о предметной области:
- Список сущностей предметной области.
- Список атрибутов сущностей.
- Описание взаимосвязей между сущностями.
ER-диаграммы удобны тем, что процесс выделения сущностей, атрибутов и связей является итерационным. Разработав первый приближенный вариант диаграмм, мы уточняем их, опрашивая экспертов предметной области. При этом документацией, в которой фиксируются результаты бесед, являются сами ER-диаграммы.
Предположим, что перед нами стоит задача разработать информационную систему по заказу некоторой оптовой торговой фирмы. В первую очередь мы должны изучить предметную область и процессы, происходящие в ней. Для этого мы опрашиваем сотрудников фирмы, читаем документацию, изучаем формы заказов, накладных и т.п.
Например, в ходе беседы с менеджером по продажам, выяснилось, что он (менеджер) считает, что проектируемая система должна выполнять следующие действия:
- Хранить информацию о покупателях.
- Печатать накладные на отпущенные товары.
- Следить за наличием товаров на складе.
Выделим все существительные в этих предложениях - это будут потенциальные кандидаты на сущности и атрибуты, и проанализируем их (непонятные термины будем выделять знаком вопроса):
- Покупатель - явный кандидат на сущность.
- Накладная - явный кандидат на сущность.
- Товар - явный кандидат на сущность
- (?)Склад - а вообще, сколько складов имеет фирма? Если несколько, то это будет кандидатом на новую сущность.
- (?)Наличие товара - это, скорее всего, атрибут, но атрибут какой сущности?
Сразу возникает очевидная связь между сущностями - "покупатели могут покупать много товаров" и "товары могут продаваться многим покупателям". Первый вариант диаграммы выглядит так:
Рис. 7
Задав дополнительные вопросы менеджеру, мы выяснили, что фирма имеет несколько складов. Причем, каждый товар может храниться на нескольких складах и быть проданным с любого склада.
Куда поместить сущности "Накладная" и "Склад" и с чем их связать? Спросим себя, как связаны эти сущности между собой и с сущностями "Покупатель" и "Товар"? Покупатели покупают товары, получая при этом накладные, в которые внесены данные о количестве и цене купленного товара. Каждый покупатель может получить несколько накладных. Каждая накладная обязана выписываться на одного покупателя. Каждая накладная обязана содержать несколько товаров (не бывает пустых накладных). Каждый товар, в свою очередь, может быть продан нескольким покупателям через несколько накладных. Кроме того, каждая накладная должна быть выписана с определенного склада, и с любого склада может быть выписано много накладных. Таким образом, после уточнения, диаграмма будет выглядеть следующим образом:
Рис. 8
Пора подумать об атрибутах сущностей. Беседуя с сотрудниками фирмы, мы выяснили следующее:
- Каждый покупатель является юридическим лицом и имеет наименование, адрес, банковские реквизиты.
- Каждый товар имеет наименование, цену, а также характеризуется единицами измерения.
- Каждая накладная имеет уникальный номер, дату выписки, список товаров с количествами и ценами, а также общую сумму накладной. Накладная выписывается с определенного склада и на определенного покупателя.
- Каждый склад имеет свое наименование.
- Снова выпишем все существительные, которые будут потенциальными атрибутами, и проанализируем их:
- Юридическое лицо - термин риторический, мы не работаем с физическими лицами. Не обращаем внимания.
- Наименование покупателя - явная характеристика покупателя.
- Адрес - явная характеристика покупателя.
- Банковские реквизиты - явная характеристика покупателя.
- Наименование товара - явная характеристика товара.
- (?)Цена товара - похоже, что это характеристика товара. Отличается ли эта характеристика от цены в накладной?
- Единица измерения - явная характеристика товара.
- Номер накладной - явная уникальная характеристика накладной.
- Дата накладной - явная характеристика накладной.
- (?)Список товаров в накладной - список не может быть атрибутом. Вероятно, нужно выделить этот список в отдельную сущность.
- (?)Количество товара в накладной - это явная характеристика, но характеристика чего? Это характеристика не просто "товара", а "товара в накладной".
- (?)Цена товара в накладной - опять же это должна быть не просто характеристика товара, а характеристика товара в накладной. Но цена товара уже встречалась выше - это одно и то же?
- Сумма накладной - явная характеристика накладной. Эта характеристика не является независимой. Сумма накладной равна сумме стоимостей всех товаров, входящих в накладную.
- Наименование склада - явная характеристика склада.
В ходе дополнительной беседы с менеджером удалось прояснить различные понятия цен. Оказалось, что каждый товар имеет некоторую текущую цену. Эта цена, по которой товар продается в данный момент. Естественно, что эта цена может меняться со временем. Цена одного и того же товара в разных накладных, выписанных в разное время, может быть различной. Таким образом, имеется две цены - цена товара в накладной и текущая цена товара.
С возникающим понятием "Список товаров в накладной" все довольно ясно. Сущности "Накладная" и "Товар" связаны друг с другом отношением типа много-ко-многим. Такая связь, как мы отмечали ранее, должна быть расщеплена на две связи типа один-ко-многим. Для этого требуется дополнительная сущность. Этой сущностью и будет сущность "Список товаров в накладной". Связь ее с сущностями "Накладная" и "Товар" характеризуется следующими фразами - "каждая накладная обязана иметь несколько записей из списка товаров в накладной", "каждая запись из списка товаров в накладной обязана включаться ровно в одну накладную", "каждый товар может включаться в несколько записей из списка товаров в накладной", " каждая запись из списка товаров в накладной обязана быть связана ровно с одним товаром". Атрибуты "Количество товара в накладной" и "Цена товара в накладной" являются атрибутами сущности " Список товаров в накладной".
Точно также поступим со связью, соединяющей сущности "Склад" и "Товар". Введем дополнительную сущность "Товар на складе". Атрибутом этой сущности будет "Количество товара на складе". Таким образом, товар будет числиться на любом складе и количество его на каждом складе будет свое.
Теперь можно внести все это в диаграмму:
Рис. 9
Концептуальные и физические ER-модели
Разработанный выше пример ER-диаграммы является примером концептуальной диаграммы . Это означает, что диаграмма не учитывает особенности конкретной СУБД. По данной концептуальной диаграмме можно построить физическую диаграмму , которая уже будут учитываться такие особенности СУБД, как допустимые типы и наименования полей и таблиц, ограничения целостности и т.п. Физический вариант диаграммы, приведенной на Рис. 9 может выглядеть, например, следующим образом:
Рис. 10
На данной диаграмме каждая сущность представляет собой таблицу базы данных, каждый атрибут становится колонкой соответствующей таблицы. Обращаем внимание на то, что во многих таблицах, например, "CUST_DETAIL" и "PROD_IN_SKLAD", соответствующих сущностям "Запись списка накладной" и "Товар на складе", появились новые атрибуты, которых не было в концептуальной модели - это ключевые атрибуты родительских таблиц, мигрировавших в дочерние таблицы для того, чтобы обеспечить связь между таблицами посредством внешних ключей.
Легко заметить, что полученные таблицы сразу находятся в 3НФ.
Выводы
Реальным средством моделирования данных является не формальный метод нормализации отношений, а так называемое семантическое моделирование .
В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-Relationship ).
Диаграммы сущность-связь позволяют использовать наглядные графические обозначения для моделирования сущностей и их взаимосвязей.
Различают концептуальные и физические ER-диаграммы. Концептуальные диаграммы не учитывают особенностей конкретных СУБД. Физические диаграммы строятся по концептуальным и представляют собой прообраз конкретной базы данных. Сущности, определенные в концептуальной диаграмме становятся таблицами, атрибуты становятся колонками таблиц (при этом учитываются допустимые для данной СУБД типы данных и наименования столбцов), связи реализуются путем миграции ключевых атрибутов родительских сущностей и создания внешних ключей.
При правильном определении сущностей, полученные таблицы будут сразу находиться в 3НФ. Основное достоинство метода состоит в том, модель строится методом последовательных уточнений первоначальных диаграмм.
В данной главе, являющейся иллюстрацией к методам ER-моделирования, не рассмотрены более сложные аспекты построения диаграмм, такие как подтипы, роли, исключающие связи, непереносимые связи, идентифицирующие связи и т.п.
Связь « Один – к одному » Один – к одному. Этот тип связи означает, что каждому объекту первого вида соответствует не более одного объекта второго вида, и наоборот. Например: сотрудник может руководить только одним отделом, и у каждого отдела есть только один руководитель.
Связь « Один – ко многим » Один – ко многим (или в обратную сторону Многие – к одному). Этот тип связи означает, что каждому объекту первого вида может соответствовать более одного объекта второго вида, но каждому объекту второго вида соответствует не более одного объекта первого вида. Например: в каждом отделе может быть множество сотрудников, но каждый сотрудник работает только в одном отделе.
Связь « Многие – ко многим » Многие – ко многим. Этот тип связи означает, что каждому объекту первого вида может соответствовать более одного объекта второго вида, и наоборот. У этого типа связи иногда бывают собственные атрибуты. Например: каждый счет может включать множество товаров, и каждый товар может входить в разные счета.
Слабая сущность Это сущность, которая не может быть однозначно идентифицирована с помощью собственных атрибутов, а только через связь с другой сущностью. Пусть, например, номер сотрудника является уникальным только в пределах отдела, т. е. в разных отделах могут быть сотрудники с одинаковыми номерами. Уникальной в данном случае будет комбинация атрибутов « НомерСотрудника, НомерОтдела ». Сущность « Сотрудник » является слабой.
Бинарные, тернарные связи Если связь соединяет две сущности, она называется бинарной. Связь может соединять более двух сущностей, например, связь, соединяющая три сущности, называется тернарной: Связь с арностью более 2 обычно имеет тип многие – ко многим по отношению ко всем связанным сущностям.
Пример ER- модели: Контора « Рога и копыта » Описание задачи Контора « Рога и копыта » занимается коммерческой деятельностью по реализации продукции, произведенной из рогов и копыт, и предоставлению магических услуг. Сотрудник организации имеет ФИО, табельный номер, должность. Сотрудники распределены по нескольким отделам. Каждый отдел имеет номер, название и руководителя. Сотрудник не может руководить более чем одним отделом. Организация работает с предприятиями - клиентами. Каждое предприятие имеет название и адрес. С предприятием может быть заключено несколько договоров. Договор характеризуется уникальным номером, датой и типом. Каждый договор курирует некоторый сотрудник. По мере реализации клиенту товаров и услуг по договору с некоторой периодичностью выставляются счета. Счет характеризуется уникальным номером, датой выставления, сроком оплаты и суммой, а также списком реализованных товаров и услуг с указанием их количества. По неоплаченным счетам начисляются пени. Счет может быть оплачен в несколько приемов, каждый платеж характеризуется номером, датой и суммой. Номер платежа уникален в пределах его счета. Цены на товары и услуги могут изменяться со временем.
Пример ER- модели: « Музыканты » Описание задачи Необходимо разработать базу данных для хранения информации о музыкантах, сочинениях и концертах. Музыкант характеризуется именем, датой рождения и страной рождения. Сочинение включает информацию о названии, композиторе и дате первого исполнения. Музыкант может играть на разных инструментах с разной степенью квалификации. Из музыкантов - исполнителей формируются ансамбли. Каждый ансамбль, кроме своих участников, содержит информацию о названии, стране и руководителе. Наконец, исполнения произведений характеризуются датой, страной, городом исполнения, а также ансамблем, дирижером и собственно исполняемым произведением.
17
Еще примеры В учебнике « Базы данных » на сайте
ER-модель базы данных
Модель сущность-связь (англ. entity-relationship model, ERM, ER-модель) позволяет описывать концептуальные схемы предметной области.
ER-модель используется при высокоуровневом проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями. ER-модель это формальная конструкция, не определяющая графических средств её представления. В качестве стандартного графического представления ER-модели, была разработана диаграмма сущность-связь ER-диаграмма (Entity Relationship Diagram - ER - диаграмма). При проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных.
Как известно, базовым понятием реляционных БД является таблица (отношение). Таблица используется для структуризации и хранения информации. В реляционных БД каждая ячейка таблицы содержит одно значение. Кроме того, внутри одной БД существуют взаимосвязи между таблицами, каждая из которых задает совместное пользование данными таблицы.
ER-диаграмма графически представляет структуру данных проектируемой БД. Сущности отображаются при помощи прямоугольников, таблиц, содержащих имя сущности - таблицы БД. Взаимосвязи сущностей отображаются в виде линий, соединяющих отдельные сущности.
Взаимосвязь показывает, что данные одной сущности ссылаются или связаны с данными другой.
Степень конца связи указывается графически, множественность связи изображается в виде "вилки" на конце связи. Модальность связи так же изображается графически - необязательность связи помечается кружком на конце связи. Именование связи выражается одним глаголом (рис.13).
Рис.13.
Атрибуты сущности записываются внутри прямоугольника, изображающего сущность, и выражаются существительным в единственном числе.
Среди атрибутов выделяется ключ сущности. При создании сущности необходимо выделить группу атрибутов, которые могут быть первичным ключом, затем произвести отбор атрибутов для включения в состав первичного ключа:
· Первичный ключ должен быть подобран таким образом, чтобы по значениям атрибутов, в него включенных, можно было точно идентифицировать экземпляр сущности.
· Никакой из атрибутов первичного ключа не должен иметь нулевое значение.
· Значения атрибутов первичного ключа не должны меняться. Если значение изменилось, значит, это уже другой экземпляр сущности.
При выборе первичного ключа, как правило, в сущность вводится дополнительный атрибут, который становиться ключом.
Так, для определения первичного ключа часто используют уникальные номера, которые могут автоматически генерироваться системой при добавлении экземпляра сущности в БД. Применение уникальных номеров облегчает процесс индексации и поиска в БД.
Первым шагом при создании логической модели БД является построение ER-диаграммы, состоящей из трех частей: сущностей, атрибутов и взаимосвязей.
Разработано множество инструментов визуального создания ER - диаграмм для различны платформ. В настоящем проекте использовалась разработка MySQL Workbench .
Этот инструмент упрощает проектирование баз данных и обслуживание, автоматизирует, отнимающие много времени и подверженные ошибкам задачи и улучшает связь среди команд разработчиков и архитекторами БД. Он позволяет архитекторам данных визуализировать требования, общаться с заинтересованными лицами по вопросам проектирования прежде, чем будут сделаны инвестиции в проект. Это обеспечивает управляемое моделью проектирование баз данных, которое является самой эффективной методологией для того, чтобы создать реальные и хорошо продуманные базы данных. ER - диаграмма базы данных системы дистанционного тестирования (control_tests ) изображена на рисунке (рис.14). Две вертикальные черточки с одной стороны и "трезубец" с другой обозначают соответственно "связь один ко многим".
Рис. 14. ER - диаграмма базы данных control_test системы дистанционного тестирования
Нормализация базы данных
В реляционной теории БД нет универсальных предписаний, законов для проектирования надежной, спроектированной раз и навсегда базы данных. Разработчики выбирают свои решения по проекту базы данных, полагаясь во многом на опыт, интуицию, различные инструменты и методы проектирования.
Тем не менее, некоторые каноны, правила все-таки существуют. К таким правилам относятся правила нормализации, т.е. приведения отношений к нормальной форме.