Привет. Данная статья посвящена одной из самых популярных, а также знакомых многим конструктивных моделей – ER( Отношения с сущностями ), который был предложен ученым-компьютерщиком Питером Ченом в 1976 году.
По ходу статьи простым языком на простых примерах из жизни мы будем разрабатывать разные варианты схем, которые будут зависеть от типа их подключения.
Давай начнем!
Объектно-ориентированный дизайн
Прежде всего хотелось бы сказать несколько слов об ООП (Объектно-ориентированном программировании/проектировании), чтобы не возникло проблем с пониманием парадигмы самой диаграммы.Мне удобнее абстрагировать эту модель принципом ООП, где сущность — это объект, атрибуты — его характеристики, а связи — это что-то вроде посредника (в некоторых случаях — типа метода).
Быстрый старт
Основным преимуществом модели проектирования Entity Relationship является ее универсальность.Вы можете спроектировать базу данных (Database), работу программы, принципы взаимодействия и т.д. Что нужно знать, начиная учиться? — Вам нужно знать на старте, что основная работа ведется над соотношением сущности и связи.
Для более легкого восприятия стоит помнить, что суть существительное , который находится в прямоугольнике, и соединение глагол , который находится в ромбе.
Приведем пример: 
Я думаю, вы понимаете, что к чему.
Наш программист преподает Python. Кажется, все логично.
Но что это за единицы в примере?
- это показатель тип связи! В этом примере используется тип соединения «Один к одному»: 
К видам связи мы вернемся, но чуть позже, а сейчас нужно посмотреть еще на одно НО:
— Диаграмму следует читать в обе стороны.
Если читать слева направо, то все логично, как было сказано ранее, а если наоборот. то еще несколько раз подумаем, что такое логика.
Действительно, так написано и это правильно! Это лишь одна из некоторых особенностей этой модели, которая иногда может сбить с толку.
Однако ничто не мешает вам, как и многим со стороны юнитов, добавить стрелку, как в примере ниже: 
P.S. Надеюсь, вам интересно.
Создать такие диаграммы можно в редакторе диаграмм Dia.
Атрибуты
Итак, у нас есть программист, но мы ничего о нем не знаем.
Без чего программист не программист?
- Без всяких атрибутов!
Добавим к нашему примеру: 
Да, атрибуты не особо отличают нашего программиста от обычного человека.
но в будущем мы исправим это новыми атрибутами! На мой взгляд, атрибут — это COLUMN (столбец) в таблице базы данных.
Атрибуты также могут быть пустыми Если в таблице вашей базы не обязательно указывать фамилию (тогда атрибут будет необязательным), то атрибут должен состоять из двух овалов: внешнего и внутреннего (внутри которого находится имя атрибута).
Идентификация атрибутов На схеме имя атрибута может быть подчеркнуто — это нормально.
Этого не нужно бояться, так как это просто идентифицирующий признак.
То есть это атрибут, который необходимо всегда заполнять, который является обязательным (первичный ключ).
В качестве примера известный id. Окей, теперь нужно дать программисту знания (какие языки, технологии он знает).
- А не будем ли мы сразу перечислять составляющие его знаний с каждым отдельным признаком? Правильно, мы будем использовать составной атрибут( атрибут, состоящий из атрибутов компонента )! Хотелось бы отметить, что атрибуты компонента также могут быть составными.
Вопрос только в том, как вы это будете реализовывать.
Виды связи
Большой.Мы смогли это выяснить.
Теперь давайте посмотрим на остальные виды общения!
Продолжим тип подключения — Один ко многим: 
Я покажу вам на примере: 
Теперь наш программист еще и изучает Perl. Неплохо.
Однако хотелось бы отметить, что приведенный выше пример является лишь исключением, чтобы наглядно показать, куда идет связь, ведь ответвлений может быть тысяча, рисовать которые было бы глупо.
В дальнейшем мы вернемся к сокращенным и правильным обозначениям, но эту хилую закономерность просто стоит запомнить, чтобы иметь общее представление о том, что к чему.
Надеюсь, мне удалось объяснить вам, что представляет собой тип отношений «Один ко многим».
*Связь одного объекта с несколькими и наоборот* Прежде чем продолжить изучение типов общения, следует знать, что соединения также имеют атрибуты .
На примере показывать не буду — потому что это без проблем можно понять, на словах.
Представьте себе, что у вас есть подключение «Транзакции».
Допустим, в вашем проекте вам необходимо сохранить всю информацию о сохраненных транзакциях, сохраняется ли она в файле или в базе данных, не имеет значения.
Вам нужно экономить время, исключения (возникшие ошибки) и что-то еще.
В нашем случае все вышеперечисленное — атрибуты, которые будут принадлежать соединению.
Такие атрибуты также могут быть составными, идентифицирующими или необязательными.
Вопрос только в реализации.
Давай продолжим.
Остается последний тип связи — Многие ко многим: 
Как обычно покажу пример, но не с Программистом, а на примере связи Зрителя и Фильма, на каком-то сервисе для просмотра Фильмов: 
Здесь есть два спорных момента.
Давайте начнём разбираться.
Первый: - Почему связь больше похожа на суть?
Чтобы упростить отношения «многие ко многим», мы используем промежуточные сущности .- Почему здесь нет филиалов?
— Зритель может подписаться на многие фильмы.Теперь давайте рассмотрим другой способ реализации связи «Многие ко многим», который будет немного сложнее написать, но, возможно, более понятен для тех, кто не знает о промежуточных сущностях:— У фильмов может быть много зрителей, которые на них подписываются.
Как вы могли заметить, в данном примере присутствует связь типа «Один ко многим», а то и несколько.
Это правда и это легко объяснить.
Дело в том, что тип отношений «Многие ко многим» равен двум «Один ко многим».
Вам, вероятно, интересно, почему между соединением и сущностью есть два ребра.
Это немного сложнее объяснить.
Внимательно прочитайте.
Дело в том, что существуют необязательный И обязательные соединения .
Запомните личность:
Необязательные подключения создают частичное участие, а обязательные подключения создают полное участие.— Что такое частичное и полное участие? Частичное участие также является одним из исключений, чем-то похожее на необязательный атрибут, но зависит от сущности.
Представьте себе картину.
Есть две сущности: Покупатель и продукция.
Тип отношений – Один ко многим.
У них общая связь – Покупки.
Но нам нужно понять кое-что еще.
Без чего покупатель не покупатель? - Без хотя бы одной покупки! Данный случай является представителем частичного подключения, так как мы даем выбор «Купить и стать покупателем или отказаться».
В этом случае у нас будет одно ребро между отношением «Покупки» и сущностью «Продукты».
Теперь рассмотрим полное участие.
Полное участие – это тот случай, когда выбора нет. Наш программист останется программистом, даже если он ничему не научится, благодаря тому, что мы записываем на схеме, что он должен чему-то научиться, и исключений быть не может. Фиксируем это дело двумя ребрами.
Тип участия зависит от того, как вы планируете, нужна ли выборка на этапе коммуникации.
Мы закончили с этим.
Давай продолжим.
Вспомните пример «Один ко многим», где после подключения «Обучает» шли названия языков программирования, что приводило к большому количеству ветвей, потому что это было не корректно с точки зрения записи.
Подумайте только, нам не обязательно делать ветки для каждого языка.
Мы можем просто создать сущность «Язык программирования», в которую поместим атрибуты, которые будут отвечать за ее имя, возраст, мощность и многое другое.
Я думаю, ты понимаешь.
Советую использовать аббревиатуру «Многие ко многим».
Слабые сущности
Давайте посмотрим на окончательную концепцию.Представьте, что у вас есть таблица «Родитель» и «Дочерний» соответственно, одни и те же сущности на диаграмме.
Может ли одно существовать без другого? Я думаю нет. И биологически, и вообще логически.
Слабая сущность: не может быть яблока без яблони.
В этом примере сущность «Ребенок» является слабой сущностью.
Слабые сущности — это те сущности, которые не могут существовать без другой сущности.Создаем сущность «Дочерняя» в надежде, что у Родителя/Родителей нет дочерних элементов с такими же именами, иначе нашу сущность, которая может быть таблицей в базе данных, будет сложно назвать Нормализованный (таблица, в которой соблюдены правила Автономии Данных и есть Идентификатор Первичного Ключа), потому что мы просто не можем отличить детей.
Однако такие случаи случаются, но это можно исправить, добавив дополнительный атрибут. В данном случае именно атрибут «Имя» создает такую ситуацию, и он называется ключевой компонент слабой организации .
Названия таких атрибутов в овалах подчеркнуты пунктиром, а сущность и связь помещены в дополнительных рисунках, в которых они состоят.
Позволь мне привести пример: 
Заключение
В заключение хотелось бы сказать, что одна из основ грамотной совместной работы – это хорошее объяснение поставленных задач, хорошая презентация продукта, который необходимо разработать, в этом и помогают проектные модели.Entity Relationship — это модель проектирования, популярная на протяжении десятилетий.
Он позволяет строить изящные диаграммы, которые при правильном подходе можно дополнять и модифицировать в будущем.
Не ленитесь учиться.
Спасибо за внимание!
Источники
— Книга «Руководство по MySQL» Авторы: Сейед М.М.
«Саид» Тахагоги, Хью ?.
Уильямс — ru.wikipedia.org/wiki/Entity –relationship_model Теги: #ИТ-стандарты #отношения между организациями
-
Мобильные Устройства – Друзья Или Враги?
19 Oct, 24 -
Надежность Go В Инфраструктуре Dropbox
19 Oct, 24 -
Планирование Рабочего Времени
19 Oct, 24 -
Запасы Нефти Самовосполняются
19 Oct, 24 -
Скрипт Для Сообщества?
19 Oct, 24
