[Из песочницы] Учимся стандарту проектирования — Entity Relationship
Здравствуйте. Данная статья посвящена одной из самых популярных, а также и многим знакомой, модели проектирования — ER (Entity Relationship), которая была предложена учёным, в области информатики — Питером Ченом, в 1976 году.
По ходу статьи простым языком на простых примерах из жизни — мы с Вами разработаем разные варианты диаграммы, которые будут зависеть от их типа связи. Начнём!
Объектно Ориентированное Проектирование
В первую очередь, хотелось бы сказать пару слов об ООП (Объектно Ориентированном Программировании/Проектировании), чтобы не было проблем с пониманием парадигмы самой диаграммы. Мне удобнее абстрагировать эту модель с принципом ООП, где сущность — объект, атрибуты — его характеристики, а связи — что-то вроде посредника (в некоторых случаях — как метод).
Быстрый старт
Главный плюс модели проектирования Entity Relationship — это то, что она универсальна. Вы можете проектировать БД (Базы данных), работу какой-либо программы, принципы взаимодействия и др.
Что нужно знать на старте изучения?
— Нужно знать на старте то, что основная работа проводится над взаимоотношением сущности и связи. Для более легкого восприятия, стоит запомнить, что сущность — существительное, которое находится в прямоугольнике, а связь — глагол, который находится в ромбе. Приведём пример:
Думаю, Вы поняли, что к чему. Наш Программист учит Python. Вроде, всё логично. Но вот, только, что это за единички в примере?
— Это показатель типа связи! В данном примере используется вид связи — Один к одному:
$$display$$1:1$$display$$
К видам связи мы ещё вернёмся, но чуть позже!
P.S. Надеюсь, Вы заинтересованы. Такие диаграммы Вы можете создавать в редакторе диаграмм — Dia.
Атрибуты
Так, у нас есть программист, но мы ничего о нём не знаем… Без чего программист не программист?
— Без каких-то атрибутов!
Дополним наш пример:
Да, атрибуты не особо отличают нашего программиста от обычного человека…, но в будущем мы это исправим новыми атрибутами! В моём представлении, атрибут — это COLUMN (столбец) в таблице Базы Данных.
Атрибуты бывают и пустыми
Если в таблице Вашей БД необязательно указывать фамилию (то атрибут будет необязательным), тогда атрибут должен состоять из двух овалов: внешнего и внутреннего (внутри которого название атрибута).
Индентифицирующие атрибуты
Вы можете встретить подчеркивание названия атрибута в диаграмме — это нормально. Пугаться этого не стоит, тк это просто индентифицирующий атрибут. То-есть, это атрибут, который должен быть заполнен всегда, который является обязательным (первичным ключом). Как пример — всем известный id.
Хорошо, а теперь нам нужно дать программисту знания (то, какие языки, технологии он знает).
— Но мы же не будем сразу перечислять каждым отдельным атрибутом составляющие его знаний?
Верно, мы воспользуемся составным атрибутом (атрибут, который состоит из атрибутов-составляющих)! Хочу отметить то, что атрибуты-составляющие — тоже могут быть составными. Вопрос лишь в том, как Вы будете это реализовывать.
Типы связи
Отлично. С этим мы смогли разобраться. Теперь рассмотрим оставшиеся типы связи!
Продолжим с типа связи — Один ко многому:
$$display$$1: N $$display$$
Покажу на примере:
Теперь наш программист изучает ещё и Perl. Неплохо.
Кстати, ответвлений может быть гораздо больше.
Остался последний тип связи — Многое ко многому:
$$display$$M: N$$display$$
Как обычно, покажу Вам на примере, но уже не с Программистом, а на примере взаимосвязи Зрителя с Фильмом, на каком-либо сервисе по просмотру Фильмов:
Тут два спорных момента. Начнём разбираться.
Первое:
— Почему связь больше смахивает на сущность?
Для упрощения связи типа «Многое ко многому» используются промежуточные сущности.
— Почему здесь нет ответвлений?
— Зритель может подписаться на много Фильмов.
— У Фильмов может быть много зрителей, которые подписаны на них.
А теперь рассмотрим другой способ реализации связи «Многое ко многому», который будет чуть сложнее в записи, но возможно понятнее тем, кто не знает о промежуточных сущностях:
Как Вы могли заметить, в данном примере есть тип связи «Один ко многому», и даже несколько.
Это правда и такое легко объяснить. Дело в том, тип связи «Многое ко многому» равняется двум «Один ко многому».
$$display$$M: N = 1: N + N:1$$display$$
Наверное, Вы заинтересованы в том, почему у нас, между связью и сущностью, два ребра.
Это тоже легко объяснить, но нужно немного пояснения и
внимательного чтения с Вашей стороны.
Вспомните пример «Один ко многому», где после связи «Учит» были названия ЯП (Языков программирования), что приводило к большому количеству разветвлений. То, что я показал в последнем примере, по своей сути — мощный способ сокращения записи отношения сущностей к связи, который называется полным участием. Только подумайте, ведь нам не обязательно делать ответвления к каждому ЯП. Мы можем просто создать сущность «Язык программирования», в которой мы разместим атрибуты, которые будут отвечать за его название, возраст, мощность и многое другое. Думаю, Вы поняли. Советую использовать сокращенную запись «Многое ко многому».
Слабые сущности
Рассмотрим заключительное понятие.
Представьте, что у вас в существует таблица «Родитель» и «Ребенок», соответственно такие-же сущности в диаграмме. Может ли одно существовать без другого? Я думаю — нет. Как в биологическом, так и в целом логическом, яблока без яблони быть не может.
В этом примере сущность «Ребенок» — слабая сущность.
Слабые сущности — это те сущности, которые не могут существовать без другой сущности.
Мы создаём сущность «Ребёнок», в надежде на то, что у Родителя/Родителей нет детей с одинаковыми именами, тк иначе — нашу сущность, которая может являться таблицей в БД, будет сложно назвать Нормализованной(таблица, в которой соблюдаются правила Автомарности данных и существует Первичный ключ-идентификатор), ведь мы банально не сможем отличить детей.
Однако, такие случае имеют место быть, но исправить это можно добавлением дополнительного атрибута. В таком случае, атрибут «Имя» — то, что и создает подобную ситуацию, а называется он компонентом ключа слабой сущности. Название подобных атрибутов, в овалах, подчеркиваются пунктиром, а сущность и связь помещаются в дополнительные фигуры, в которых они состоят.
Представлю Вам это на примере:
Заключение
В заключение хочется сказать, что одна из основополагающих грамотной кооперативной работы — хорошее объяснение поставленных задач, хорошее представление продукта, который нужно разработать, в чём и помогают модели проектирования. Entity Relatioship — целый стандарт, который пользуется популярностью не один десяток лет. Он позволяет строить изящные диаграммы, которые, при правильном подходе, можно в будущем дополнять и видоизменять. Не поленитесь изучить. Спасибо за внимание!
Источники
— Книга «Руководство по MySQL» Авторства:
Сейед М.М. «Saied» Тахагхогхи, Хью Е.Вильямс
— ru.wikipedia.org/wiki/Заглавная_страница
