Хабрахабр

[Из песочницы] Учимся стандарту проектирования — Entity Relationship

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

image

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

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

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

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

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

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

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

image

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

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

$$display$$1:1$$display$$

К видам связи мы ещё вернёмся, но чуть позже!

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

Атрибуты

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

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

image

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

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

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

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

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

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

image

Типы связи

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

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

$$display$$1:N $$display$$

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

image

Неплохо. Теперь наш программист изучает ещё и Perl.

Кстати, ответвлений может быть гораздо больше.

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

$$display$$M:N$$display$$

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

image

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

Первое:
— Почему связь больше смахивает на сущность?

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

— Почему здесь нет ответвлений?

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

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

image

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

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

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

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

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

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

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

В этом примере сущность «Ребенок» — слабая сущность.

Слабые сущности — это те сущности, которые не могут существовать без другой сущности.

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

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

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

image

Заключение

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

Источники

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть