Учимся проектированию Entity Relationship — диаграмм +21



Здравствуйте. Данная статья посвящена одной из самых популярных, а также и многим знакомой, модели проектирования — ER(Entity Relationship), которая была предложена учёным, в области информатики — Питером Ченом, в 1976 году.

image

По ходу статьи простым языком на простых примерах из жизни — мы с Вами разработаем разные варианты диаграммы, которые будут зависеть от их типа связи. Начнём!

Объектно Ориентированное Проектирование


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

Быстрый старт


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

Что нужно знать на старте изучения?

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

image

Думаю, Вы поняли, что к чему. Наш Программист учит Python. Вроде, всё логично. Но вот, только, что это за единички в примере?

— Это показатель типа связи! В данном примере используется вид связи — Один к одному:

$1:1$


К видам связи мы ещё вернёмся, но чуть позже, а сейчас нужно разобрать ещё одно НО:
— Диаграмма должна читаться в обе стороны. Если прочесть слева на право, то всё логично, как было сказано ранее, но если наоборот… то мы ещё несколько раз задумаемся о том, что такое логика. Действительно, так записано и это правильно! Это лишь одна из некоторых особенностей данной модели, что иногда может запутать. Однако, ничто не мешает Вам, как и многим, со стороны единицы, добавить стрелочку, как на примере ниже:

image

P.S. Надеюсь, Вы заинтересованы. Такие диаграммы Вы можете создавать в редакторе диаграмм — Dia.

Атрибуты


Так, у нас есть программист, но мы ничего о нём не знаем… Без чего программист не программист?
— Без каких-то атрибутов!

Дополним наш пример:

image

Да, атрибуты не особо отличают нашего программиста от обычного человека… но в будущем мы это исправим новыми атрибутами! В моём представлении, атрибут — это COLUMN(столбец) в таблице Базы Данных.

Атрибуты бывают и пустыми

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

Индентифицирующие атрибуты

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

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

image

Типы связи


Отлично. С этим мы смогли разобраться. Теперь рассмотрим оставшиеся типы связи!

Продолжим с типа связи — Один ко многому:

$1:N $


Покажу на примере:

image

Теперь наш программист изучает ещё и Perl. Неплохо.
Однако, хочу отметить, что пример, указанный выше — лишь исключение, для того, чтобы показать наглядно, к чему идёт отношение, потому что ответвлений может быть тысяча, что глупо будет чертить. В будущем, мы вернёмся к сокращенной и правильной записи, а этот хиленький паттерн стоит просто запомнить, чтобы было общее представление, что к чему. Надеюсь, что у меня получилось объяснить Вам, что представляет тип связи «Один ко многому».
*Отношение одной сущности к нескольким и наоборот*

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

Остался последний тип связи — Многое ко многому:

$M:N$


Как обычно, покажу Вам на примере, но уже не с Программистом, а на примере взаимосвязи Зрителя с Фильмом, на каком-либо сервисе по просмотру Фильмов:

image

Тут два спорных момента. Начнём разбираться.

Первое:
— Почему связь больше смахивает на сущность?
Для упрощения связи типа «Многое ко многому» используются промежуточные сущности.

— Почему здесь нет ответвлений?
— Зритель может подписаться на много Фильмов.
— У Фильмов может быть много зрителей, которые подписаны на них.


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

image

Как Вы могли заметить, в данном примере есть тип связи «Один ко многому», и даже несколько.
Это правда и такое легко объяснить. Дело в том, тип связи «Многое ко многому» равняется двум «Один ко многому».

$M:N = 1:N + N:1$


Наверное, Вы заинтересованы в том, почему у нас, между связью и сущностью, два ребра.
Это уже чуть сложнее объяснить. Читайте внимательно.
Дело в том, что бывают опциональные и обязательные связи. Запомните тождество:
Опциональные связи создают частичное участие, в то время как обязательные — полное.

— Что такое частичное и полное участия?

Частичное участие — тоже одно из исключений, похожее чем-то на необязательный атрибут, вот только зависит от сущности. Представьте картину. Есть две сущности:
Покупатель и Продукты. Тип связи — Один ко многому.
У них общая связь — Покупает. Но нам нужно понять другое. Без чего покупатель — не покупатель?
— Без хотя бы одной покупки!
Данный случай — представитель частичной связи, тк мы даём выбор «Покупать и стать покупателем или отказаться». В таком случае, у нас, будет одно ребро между связью «Покупает» и сущностью «Продукты». Теперь рассмотрим полное участие.

Полное участие представляет из себя тот случай, когда выбора нет. Наш программист останется программистом, даже если ничего не выучит, благодаря тому, что мы фиксируем на диаграмме то, что он должен что-то учить, а исключений быть не может. Фиксируем мы это дело двумя рёбрами. Тип участия зависит от того, как вы проектируете, нужна ли выборка на этапе связи.
С этим закончили. Продолжаем.

Вспомните пример «Один ко многому», где после связи «Учит» были названия ЯП(Языков программирования), что приводило к большому количеству разветвлений, потому как было не правильно в плане записи. Только подумайте, ведь нам не обязательно делать ответвления к каждому ЯП. Мы можем просто создать сущность «Язык программирования», в которой мы разместим атрибуты, которые будут отвечать за его название, возраст, мощность и многое другое. Думаю, Вы поняли. Советую использовать сокращенную запись «Многое ко многому».

Слабые сущности


Рассмотрим заключительное понятие.

Представьте, что у Вас в существует таблица «Родитель» и «Ребенок», соответственно такие-же сущности в диаграмме. Может ли одно существовать без другого? Я думаю — нет. Как в биологическом, так и в целом логическом.
Слабая сущность: яблока без яблони быть не может
.

В этом примере сущность «Ребенок» — слабая сущность.
Слабые сущности — это те сущности, которые не могут существовать без другой сущности.
Мы создаём сущность «Ребёнок», в надежде на то, что у Родителя/Родителей нет детей с одинаковыми именами, тк иначе — нашу сущность, которая может являться таблицей в БД, будет сложно назвать Нормализованной(таблица, в которой соблюдаются правила Автомарности данных и существует Первичный ключ-идентификатор), ведь мы банально не сможем отличить детей.

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

Представлю вам это на примере:

image

Заключение


В заключение хочется сказать, что одна из основополагающих грамотной кооперативной работы — хорошее объяснение поставленных задач, хорошее представление продукта, который нужно разработать, в чём и помогают модели проектирования. Entity Relatioship — модель проектирования, которая пользуется популярностью не один десяток лет. Она позволяет строить изящные диаграммы, которые, при правильном подходе, можно в будущем дополнять и видоизменять. Не поленитесь изучить. Спасибо за внимание!

Источники


— Книга «Руководство по MySQL» Авторства:
Сейед М.М. «Saied» Тахагхогхи, Хью Е.Вильямс
en.wikipedia.org/wiki/Entity–relationship_model

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (18):

  1. lair
    /#19765404 / +1

    Приведём пример: [...] Думаю, Вы поняли, что к чему. Наш Программист учит Python

    Да, я понял. Питон учит программиста.


    А знаете, почему? Потому что стрелочки надо рисовать.


    Entity Relatioship — целый стандарт,

    Вот прямо вот стандарт? А какой организацией он принят, в каком документе описан?

    • Doctor_IT
      /#19765438

      1) Про ошибку в примере — соглашусь. Сделаю правку с «Учит» на «Обучение», но вот "стрелочки" в данной модели не используются.


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

      • lair
        /#19765444

        Про ошибку в примере — соглашусь. Сделаю правку с «Учит» на «Обучение»

        … и эта правка сделает еще хуже, потому что понять, кто кого учит, будет окончательно невозможно.


        вот "стрелочки" в данной модели не используются.

        Вы, наверное, хотели сказать, вы не используете, и не встречали, чтобы использовали?


        Стандарт не обязательно должен быть прописан

        Ну то есть нет никакого "стандарта", а есть какая-то модель, которая вам понравилась, и которую вы понимаете каким-то удобным вам образом.


        Сколько людей, столько и мнений

        … так почему же надо учить именно эту модель, и именно в том виде, который вы предлагаете, если у него прямо вот очевидно есть недостатки?

        • Doctor_IT
          /#19765470

          Хорошо, про стандарт уберу.
          Ну, про «надо» я не говорил, прямо. Я советовал. В первую очередь читателю решать, использовать ли эту модель в будущем. Я лишь написал статью про привычную мне модель, про которую в Рунете, а особенно на Хабр(Российский Сигмент), информации либо почти нет, либо нет вообще

          • lair
            /#19765506

            Ну так может потому и нет (хотя на самом деле — есть, и легко находится поиском), что она не так удобна, как вам кажется?

          • sshikov
            /#19766960

            >информации либо почти нет, либо нет вообще

            Угу, угу. Я вот просто ткнул в поиск по хабру, набрал «ER-диаграммы», и получил десяток ответов минимум.

            Так что вопрос скорее стоит так: зачем было это писать, если информации на первый взгляд как раз навалом? Чем ваша статья лучше чем те 10 или больше, которые уже были прямо тут опубликованы? Не говоря уже про другие ресурсы (собственно, первая книга, где я видел описание этой модели, была издательства Мир, и примерно 1980 года издания). Вы считаете, что никто про ER модели не знает, и поэтому не использует?

            • Doctor_IT
              /#19767110

              Я не говорю, что лучше. Читать или нет — выбор пользователей.

              • sshikov
                /#19767190

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

  2. megaentwickler
    /#19765420

    Вот бы ещё во всех конторах документировали схемы данных в такие диаграммы…
    Ни одной ещё не встретил, которая могла бы похвастать этим.

    • akryukov
      /#19766248

      Зачем во всех и почему именно в такие?
      Большинство инструментов для работы с СУБД могут вам сделать диаграмму базы данных автоматически по уже существующим таблицам.

      • Doctor_IT
        /#19766290

        Как я и говорил ранее:
        Данная модель проектирования очень гибкая и используется не только при проектировании Баз Данных. Однако, тот же MySQL Workbench унаследовал типы связи, которые чуть иным образом обозначены, но сохраняют смысл

  3. akryukov
    /#19766274

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

    Что именно понимается под "работой какой-либо программы"? Если подразумевается последовательность действий и изменение состояния какой-то сущности, то в ER будет затруднительно это нарисовать.
    Попробуйте, например, выразить ER-диаграммой "Человек забронировал билет на сайте и указал свою почту. Ему пришло письмо с подтверждением брони. После перехода по ссылке из письма, место стало забронировано человеком. Если перехода по ссылке не было, то место остается свободным. За час до начала сеанса человек выкупил билет в кассе. Забронированное место было помечено как выкупленное. Если за 40 минут до начала сеанса бронь не была выкуплена, то место считается свободным."


    Было бы неплохо подробнее описать применимость ER-диаграммы к реальной работе, уточнить для чего она больше подходит и дать ссылки на смежные темы.


    Источники
    — ru.wikipedia.org/wiki/Заглавная_страница

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

    • Doctor_IT
      /#19766302

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

      Насчет источников — исправил. Впервые написал статью, пока что набираюсь опыта. Спасибо за указания.

  4. nickavery
    /#19766310

    В курсовой по проектированию БД активно использовали ER-диаграммы. Подробное руководство приводилось, например, в книге Т.Коннолли «Базы данных. Проектирование, реализация и сопровождение. Теория и практика». В других областях использование ER пока не встречал.

    • Doctor_IT
      /#19766316

      так или иначе, в описании некоторых «блоков», написанной программы, помочь может.

    • VolCh
      /#19766416

      На практике встречал использование при применении DDD.

  5. keydet
    /#19769080

    Подскажите, а зачем выделять relationship в ромб? Почему нельзя написать над линией?

    Какие преимущества перед UML composite structure diagram?