Учимся проектированию Entity Relationship — диаграмм
Здравствуйте. Данная статья посвящена одной из самых популярных, а также и многим знакомой, модели проектирования — ER(Entity Relationship), которая была предложена учёным, в области информатики — Питером Ченом, в 1976 году.
По ходу статьи простым языком на простых примерах из жизни — мы с Вами разработаем разные варианты диаграммы, которые будут зависеть от их типа связи. Начнём!
Объектно Ориентированное Проектирование
В первую очередь, хотелось бы сказать пару слов об ООП(Объектно Ориентированном Программировании/Проектировании), чтобы не было проблем с пониманием парадигмы самой диаграммы. Мне удобнее абстрагировать эту модель с принципом ООП, где сущность — объект, атрибуты — его характеристики, а связи — что-то вроде посредника(в некоторых случаях — как метод).
Быстрый старт
Главный плюс модели проектирования Entity Relationship — это то, что она универсальна. Вы можете проектировать БД(Базы данных), работу какой-либо программы, принципы взаимодействия и др.
Что нужно знать на старте изучения?
— Нужно знать на старте то, что основная работа проводится над взаимоотношением сущности и связи. Для более легкого восприятия, стоит запомнить, что сущность — существительное, которое находится в прямоугольнике, а связь — глагол, который находится в ромбе. Приведём пример:
Думаю, Вы поняли, что к чему. Наш Программист учит Python. Вроде, всё логично. Но вот, только, что это за единички в примере?
— Это показатель типа связи! В данном примере используется вид связи — Один к одному:
К видам связи мы ещё вернёмся, но чуть позже, а сейчас нужно разобрать ещё одно НО:
— Диаграмма должна читаться в обе стороны. Если прочесть слева на право, то всё логично, как было сказано ранее, но если наоборот… то мы ещё несколько раз задумаемся о том, что такое логика. Действительно, так записано и это правильно! Это лишь одна из некоторых особенностей данной модели, что иногда может запутать. Однако, ничто не мешает Вам, как и многим, со стороны единицы, добавить стрелочку, как на примере ниже:
P.S. Надеюсь, Вы заинтересованы. Такие диаграммы Вы можете создавать в редакторе диаграмм — Dia.
Атрибуты
Так, у нас есть программист, но мы ничего о нём не знаем… Без чего программист не программист?
— Без каких-то атрибутов!
Дополним наш пример:
Да, атрибуты не особо отличают нашего программиста от обычного человека… но в будущем мы это исправим новыми атрибутами! В моём представлении, атрибут — это COLUMN(столбец) в таблице Базы Данных.
Атрибуты бывают и пустыми
Если в таблице Вашей БД необязательно указывать фамилию(то атрибут будет необязательным), тогда атрибут должен состоять из двух овалов: внешнего и внутреннего(внутри которого название атрибута).
Индентифицирующие атрибуты
Вы можете встретить подчеркивание названия атрибута в диаграмме — это нормально. Пугаться этого не стоит, тк это просто индентифицирующий атрибут. То-есть, это атрибут, который должен быть заполнен всегда, который является обязательным(первичным ключом). Как пример — всем известный id.
Хорошо, а теперь нам нужно дать программисту знания(то, какие языки, технологии он знает).
— Но мы же не будем сразу перечислять каждым отдельным атрибутом составляющие его знаний?
Верно, мы воспользуемся составным атрибутом(атрибут, который состоит из атрибутов-составляющих)! Хочу отметить то, что атрибуты-составляющие — тоже могут быть составными. Вопрос лишь в том, как Вы будете это реализовывать.
Типы связи
Отлично. С этим мы смогли разобраться. Теперь рассмотрим оставшиеся типы связи!
Продолжим с типа связи — Один ко многому:
Покажу на примере:
Теперь наш программист изучает ещё и Perl. Неплохо.
Однако, хочу отметить, что пример, указанный выше — лишь исключение, для того, чтобы показать наглядно, к чему идёт отношение, потому что ответвлений может быть тысяча, что глупо будет чертить. В будущем, мы вернёмся к сокращенной и правильной записи, а этот хиленький паттерн стоит просто запомнить, чтобы было общее представление, что к чему. Надеюсь, что у меня получилось объяснить Вам, что представляет тип связи «Один ко многому».
*Отношение одной сущности к нескольким и наоборот*
Перед продолжением изучения типов связи, Вы должны узнать, что атрибуты бывают и у связей.
Показывать на примере не буду — тк, это понять можно без проблем, на словах. Просто представьте, что у Вас есть связь «Транзакции». Допустим, что в Вашем проекте нужно сохранять всю информацию о сохранённых транзакциях, будь то сохранение в файле или бд — не важно. Вам нужно сохранять время, исключения(возникшие ошибки) и что-то ещё. В нашем случае, всё из перечисленного — атрибуты, которые будут принадлежать связи. Такие атрибуты тоже могут быть составными, идентифицирующими, необязательными. Вопрос только в реализации. Продолжим.
Остался последний тип связи — Многое ко многому:
Как обычно, покажу Вам на примере, но уже не с Программистом, а на примере взаимосвязи Зрителя с Фильмом, на каком-либо сервисе по просмотру Фильмов:
Тут два спорных момента. Начнём разбираться.
Первое:
— Почему связь больше смахивает на сущность?
Для упрощения связи типа «Многое ко многому» используются промежуточные сущности.
— Почему здесь нет ответвлений?
— Зритель может подписаться на много Фильмов.
— У Фильмов может быть много зрителей, которые подписаны на них.
А теперь рассмотрим другой способ реализации связи «Многое ко многому», который будет чуть сложнее в записи, но возможно понятнее тем, кто не знает о промежуточных сущностях:
Как Вы могли заметить, в данном примере есть тип связи «Один ко многому», и даже несколько.
Это правда и такое легко объяснить. Дело в том, тип связи «Многое ко многому» равняется двум «Один ко многому».
Наверное, Вы заинтересованы в том, почему у нас, между связью и сущностью, два ребра.
Это уже чуть сложнее объяснить. Читайте внимательно.
Дело в том, что бывают опциональные и обязательные связи. Запомните тождество:
Опциональные связи создают частичное участие, в то время как обязательные — полное.
— Что такое частичное и полное участия?
Частичное участие — тоже одно из исключений, похожее чем-то на необязательный атрибут, вот только зависит от сущности. Представьте картину. Есть две сущности:
Покупатель и Продукты. Тип связи — Один ко многому.
У них общая связь — Покупает. Но нам нужно понять другое. Без чего покупатель — не покупатель?
— Без хотя бы одной покупки!
Данный случай — представитель частичной связи, тк мы даём выбор «Покупать и стать покупателем или отказаться». В таком случае, у нас, будет одно ребро между связью «Покупает» и сущностью «Продукты». Теперь рассмотрим полное участие.
Полное участие представляет из себя тот случай, когда выбора нет. Наш программист останется программистом, даже если ничего не выучит, благодаря тому, что мы фиксируем на диаграмме то, что он должен что-то учить, а исключений быть не может. Фиксируем мы это дело двумя рёбрами. Тип участия зависит от того, как вы проектируете, нужна ли выборка на этапе связи.
С этим закончили. Продолжаем.
Вспомните пример «Один ко многому», где после связи «Учит» были названия ЯП(Языков программирования), что приводило к большому количеству разветвлений, потому как было не правильно в плане записи. Только подумайте, ведь нам не обязательно делать ответвления к каждому ЯП. Мы можем просто создать сущность «Язык программирования», в которой мы разместим атрибуты, которые будут отвечать за его название, возраст, мощность и многое другое. Думаю, Вы поняли. Советую использовать сокращенную запись «Многое ко многому».
Слабые сущности
Рассмотрим заключительное понятие.
Представьте, что у Вас в существует таблица «Родитель» и «Ребенок», соответственно такие-же сущности в диаграмме. Может ли одно существовать без другого? Я думаю — нет. Как в биологическом, так и в целом логическом.
Слабая сущность: яблока без яблони быть не может
В этом примере сущность «Ребенок» — слабая сущность.
Слабые сущности — это те сущности, которые не могут существовать без другой сущности.
Мы создаём сущность «Ребёнок», в надежде на то, что у Родителя/Родителей нет детей с одинаковыми именами, тк иначе — нашу сущность, которая может являться таблицей в БД, будет сложно назвать Нормализованной(таблица, в которой соблюдаются правила Автомарности данных и существует Первичный ключ-идентификатор), ведь мы банально не сможем отличить детей.
Однако, такие случаи имеют место быть, но исправить это можно добавлением дополнительного атрибута. В таком случае, атрибут «Имя» — то, что и создает подобную ситуацию, а называется он компонентом ключа слабой сущности. Название подобных атрибутов, в овалах, подчеркиваются пунктиром, а сущность и связь помещаются в дополнительные фигуры, в которых они состоят.
Представлю вам это на примере:
Заключение
В заключение хочется сказать, что одна из основополагающих грамотной кооперативной работы — хорошее объяснение поставленных задач, хорошее представление продукта, который нужно разработать, в чём и помогают модели проектирования. Entity Relatioship — модель проектирования, которая пользуется популярностью не один десяток лет. Она позволяет строить изящные диаграммы, которые, при правильном подходе, можно в будущем дополнять и видоизменять. Не поленитесь изучить. Спасибо за внимание!
Источники
— Книга «Руководство по MySQL» Авторства:
Сейед М.М. «Saied» Тахагхогхи, Хью Е.Вильямс
— en.wikipedia.org/wiki/Entity–relationship_model
Создание ER-Диаграмм
Краткая теория вопроса
Информационная система (ИС) — программно-аппаратный комплекс, предназначенный для хранения и обработки информации о какой-либо предметной области.
Процесс создания ИС делится на ряд этапов. Обычно выделяют следующие этапы создания ИС:
- формирование требований к системе (анализ),
- проектирование,
- реализация,
- тестирование,
- ввод в действие,
- эксплуатация и сопровождение.
Важнейшим компонентом любой информационной системы является База данных (БД). База данных (Data Base) – структурированный, организованный набор данных, объединенный в соответствии с некоторой выбранной моделью и описывающий характеристики какой-либо физической или виртуальной системы.
Именно БД позволяет эксплуатировать ИС, выполнять ее текущее обслуживание, модифицировать и развивать её при модернизации предприятия (организации) или изменении информационных потоков, законодательства и форм отчетности предприятия (организации).
Согласно современной методологии, процесс создания ИС представляет собой процесс построения и последовательного преобразования ряда согласованных моделей на всех этапах жизненного цикла (ЖЦ) ИС. На каждом этапе ЖЦ создаются модели: организации, требований к ИС, проекта ИС, требований к приложениям и т. д.
Проектирование ИС охватывает три основные области:
- проектирование объектов данных ( создание моделей данных ) , которые будут реализованы в базе данных;
- проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
- учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т. п.
Модель – искусственный объект,представляющий собой отображение (образ) системы и её компонентов.
Модель данных (Data Model) – это графическое или текстовое представление анализа, который выявляет данные, необходимые организации с целью достижения ее миссии, функций, целей, стратегий, для управления и оценки деятельности организации. Модель данных выявляет сущности , домены (атрибуты) и связи с другими данными, а также предоставляет концептуальное представление данных и связи между данными.
Цель создания модели данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть интегрированы в любую базу данных.
При создании моделей данных используется метод семантического моделирования . Семантическое моделирование основывается на значении структурных компонентов или характеристик данных, что способствует правильности их интерпретации (понимания, разъяснения). В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER — Entity-Relationship) — ERD.
Существуют различные варианты отображения ERD , но все варианты диаграмм сущность-связь исходят из одной идеи — рисунок всегда нагляднее текстового описания. ER -диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов) , и взаимосвязей между сущностями.
Базовые понятия ERD
Сущность (таблица, отношение) — это представление набора реальных или абстрактных объектов (людей, вещей, мест, событий, идей, комбинаций и т. д.), которые можно выделить в одну группу, потому что они имеют одинаковые характеристики и могут принимать участие в похожих связях. Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. Каждая сущность в модели изображается в виде прямоугольника с наименованием.
Можно сказать, что Сущности представляют собой множество реальных или абстрактных вещей (людей, объектов, событий, идей и т. д.), которые имеют общие атрибуты или характеристики.
Экземпляр сущности (запись, кортеж)- это конкретный представитель данной сущности.
Атрибут сущности (поле, домен) — это именованная характеристика, являющаяся некоторым свойством сущности.
Связь — это некоторая ассоциация между двумя сущностями. Одна сущность может быть связана с другой сущностью или сама с собою. Связи позволяют по одной сущности находить другие сущности, связанные с ней.
Каждая связь может иметь один из следующих типов связи :
Один-к-одному, многое-ко-многим, один-ко-многим.
Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой). Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две.
Связь типа многое-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности , и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности . Тип связи много-ко-многим является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-многим путем создания промежуточной сущности.
Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны «один») называется родительской , правая (со стороны «много») — дочерней .
При разработке ER-моделей необходимо обследовать предметную область (организацию, предприятие) и выявить:
1) Сущности, о которых хранятся данные в организации (предприятии), например, люди, места, идеи, события и т.д., (будут представлены в виде блоков);
2) Связи между этими сущностями (будут представлены в виде линий, соединяющих эти блоки);
3) Свойства этих сущностей (будут представлены в виде имен атрибутов в этих блоках).
Задача: разработать информационную систему «Контингент студентов института» .
Необходимо: изучить предметную область (образовательное учреждение) и процессы, происходящие в ней.
Для этого обследуем объект: знакомимся с нормативной документацией, опрашиваем работников института, изучаем существующий документооборот института, анализируем ситуацию и т.п.
В результате обследования определяем цель и задачи системы и формулируем постановку задачи.
Краткая постановка задачи: главная задача системы – сбор и обработка информации об основных участниках учебного процесса: студентах и преподавателях, формирование необходимых печатных форм (документов), используемых преподавателями в период зачётной недели и экзаменационной сессии, генерация сводных отчётов по результатам сессии для работников деканатов, института. При разработке системы следует учитывать, что она основывается на документации, поступающей из приёмной комиссии, деканатов и других подразделений института. Информация об успеваемости студентов должна накапливаться и храниться в течение всего периода обучения. В системе должен использоваться справочник специальностей и дисциплин (предметов), изучаемых студентами.
Таким образом, проектируемая система должна выполнять следующие действия:
- Хранить информацию о студентах и их успеваемости.
- На факультетах по определённой специальности печатать экзаменационные ведомости и другие документы.
Выделим все существительные в этих предложениях — это предполагаемые сущности и проанализируем их:
- Студент — явная сущность.
- Успеваемость — явная сущность.
- ?Факультет — нужно выяснить один или несколько факультетов в институте? Если несколько, то это — предполагаемая новая сущность.
- ? Специальность — нужно выяснить одна или несколько специальностей на факультете? Если несколько, то это — ещё одна сущность.
- Предмет — предполагаемая сущность.
На первоначальном этапе моделирования данных информационной системы явно выделены две основные сущности: Студент и Успеваемость.
Критерием успеваемости является наличие отметки о сдачи экзаменов.
Сразу возникает очевидная связь между сущностями — «студент сдаёт несколько экзаменов » и «экзамены сдаются каждым студентом». Явная связь Один-ко-многим . Первый вариант диаграммы выглядит так:
Мы знаем, что студенты учатся на факультетах, на определённой специальности и сдают экзамены по дисциплинам (предметам). Анализ предметной области показал, что студенты учатся на нескольких факультетах института по нескольким специальностях и сдают экзамены по определённому перечню предметов.
Исходя из этого, мы добавляем в ER-модель ещё несколько сущностей. В результате она будет выглядеть так:
На следующей стадии проектирования модели вносим атрибуты сущностей в диаграмму (предполагаем, что атрибуты выявлены на стадии обследования объекта и при анализе аналогов существующих систем) и получаем окончательный вариант ER— диаграммы:
Отметим, что предложенные этапы моделирования являются условными и нацелены на формирование общих представлений о процессе моделирования.
Разработанный выше пример ER-диаграммы является примером концептуальной диаграммы, не учитывающей особенности конкретной СУБД. На основе данной концептуальной диаграммы можно построить физическую диаграмму , которая будут учитывать такие особенности СУБД, как допустимые типы, наименования полей и таблиц, ограничения целостности и т.п.
Для преобразования концептуальной модели в физическую необходимо знать, что:
Каждая сущность в ER-диаграмме представляет собой таблицу базы данных.
Каждый атрибут становится колонкой (полем) соответствующей таблицы.
В некоторых таблицах необходимо вставить новые атрибуты (поля), которых не было в концептуальной модели — это ключевые атрибуты родительских таблиц, перемещённых в дочерние таблицы для того, чтобы обеспечить связь между таблицами посредством внешних ключей.
Семантическое моделирование данных основывается на технологии определения значения данных через их взаимосвязи с другими данными.
В качестве инструмента семантического моделирования используются различные варианты (нотации) диаграмм сущность-связь — (Entity-Relationship) . Нотация — система условных обозначений, принятая в какой-либо области знаний или деятельности.
ER- диаграммы позволяют использовать наглядные графические обозначения для моделирования сущностей и их взаимосвязей. Основное достоинство метода состоит в том, модель строится методом последовательного уточнения и дополнения первоначальных диаграмм.
После создания концептуальной модели данных переходим к созданию физической модели средствами конкретной СУБД, а именно СУБД ACCESS. Для этого переходим к выполнению Практического задания №2
Приглашайте друзей на мой сайт
Поддержите проект! Выберите один из вариантов платежа:
С карты, с баланса сотового, из Кошелька
Что такое ER-диаграмма и как ее создать?
В этом разделе вы подробно познакомитесь с ER-диаграммами и моделями, их истоками, сферами применения, примерами, компонентами и ограничениями. Здесь же вы узнаете, как создать собственную ER-диаграмму на нашей платформе.
Читается за 12 мин.
Хотите создать собственную диаграмму? Попробуйте Lucidchart. Это быстро, легко и совершенно бесплатно.
Что такое ER-диаграмма?
Схема «сущность-связь» (также ERD или ER-диаграмма) — это разновидность блок-схемы, где показано, как разные «сущности» (люди, объекты, концепции и так далее) связаны между собой внутри системы. ER-диаграммы чаще всего применяются для проектирования и отладки реляционных баз данных в сфере образования, исследования и разработки программного обеспечения и информационных систем для бизнеса. ER-диаграммы (или ER-модели) полагаются на стандартный набор символов, включая прямоугольники, ромбы, овалы и соединительные линии, для отображения сущностей, их атрибутов и связей. Эти диаграммы устроены по тому же принципу, что и грамматические структуры: сущности выполняют роль существительных, а связи — глаголов.
ER-диаграммы — «родственники» схем структуры данных (DSD), где вместо связей между самими сущностями отображаются отношения между элементами внутри них. ER-диаграммы часто используются в сочетании с диаграммами DFD, которые схематично показывают движение потоков информации в рамках процесса или системы.
В ER-моделях и моделях данных обычно выделяют до трех уровней детализации:
- Концептуальная модель данных — схема наивысшего уровня с минимальным количеством подробностей. Достоинство этого подхода заключается в возможности отобразить общую структуру модели и всю архитектуру системы. Менее масштабные системы могут обойтись и без этой модели. В этом случае можно сразу переходить к лог