Один рисунок порой стоит тысячи слов.
Всем привет. Сегодня разберемся с такими понятиями: семантическое моделирование, ER-модель и ER-диаграмма. Обсудим теорию и перейдем к практике.
❯ Теория
Для начала следовало бы пояснить, что это все такое и с чем его едят.
Современные системы управления базами данных (СУБД) часто оперируют данными без понимания их смысловой нагрузки. СУБД воспринимают данные без контекста, в котором эти данные находятся.
Основная ответственность за корректную интерпретацию данных лежит на пользователе. Однако было бы полезно, если бы СУБД могли обладать более развитыми метаданными и могли бы анализировать запросы с учетом семантики хранимой информации.
Например, система могла бы распознавать, что оценка за экзамен и номер аудитории, хотя и представлены числами, но семантически разными величинами Это позволило бы ей предупреждать пользователя или даже блокировать запросы соединения данных, где оценка сравнивается с номером аудитории.
Даже если СУБД не поддерживают семантическое моделирование напрямую, его принципы остаются ценными при проектировании базы данных. Оно вносит осмысленность в структуру базы данных.
Хорошо, мы поняли что семантическое моделирование вносит немного осмысленности в наши данные. А с помощью чего достигается осмысленность? Какие терминами мы пользуемся для этого?
Концепции
Их совсем немного:
Сущность;
Свойства сущности;
Идентичность сущности;
Экземпляр сущности;
Связи.
Вообще строгого определения сущности не существует, она понимается на интуитивном уровне. Допустим, что мир состоит из сущностей. Ими, например, могут быть: человек, самолет, работник, фабрика, вызов электрика ,ведомость за экзамен, заказ, клиент и так далее.
Как видно, сущность может быть физическим объектом, событием, концепцией и вообще чем угодно, но с выполнением некоторых условий. Каждая сущность имеет уникальное свойство/свойства, позволяющее её идентифицировать, то есть обладает идентичностью. При определении типа сущности необходимо гарантировать, что каждый экземпляр сущности отличим от любого другого экземпляра той же сущности.
Когда мы говорим о конкретном представителе сущности, мы говорим о экземпляре. Например, Ту-134 это экземпляр сущности «Самолет». У всех экземпляров сущности «Самолет» есть общие свойства (иногда именуемые атрибутами): вес самолета, кол-во двигателей, общий налет, вместимость и т. д.
Наконец, допустимо предположить, что сущности могут быть связаны между собой посредством связей (уж простите за тавтологию). Связь в данном случае это то, как две сущности взаимодействуют между собой.
Можно продолжать развивать подобные рассуждения. Однако надо понимать, что используемые термины (сущность, экземпляр сущности, идентичность, свойство, связь и другие) не имеют строгих формальных определений. Они представляют собой концептуальные категории для описания реального мира, а не точные формальные понятия. Следовательно, данный этап моделирования носит принципиально неформальный характер.
На стадии семантического моделирования создается важная документация, которая может быть крайне полезной не только при разработке структуры реляционной базы данных, но и в процессе ее дальнейшего использования, обслуживания и модернизации после наполнения данными.
❯ ER-модель и ER-диаграмма
А как можно применить на практике подход семантического моделирования?
Для этого в 1976 году Питером Ченом (Peter Chen) была предложена ER-модель (Entity-Relationship) проектирования БД.
ER‑моделирование не эквивалентно термину семантическое моделирование, а является лишь его вариантом.
Визуальное представление ER-модели называется ER-диаграмма. Проектирование предметной области основывается на применении визуальных диаграмм, состоящих из ограниченного набора разнотипных элементов. Благодаря удобству и понятности отображения концептуальных структур баз данных, ER-модель получила широкое применение в CASE-средствах, используемых для автоматизированного создания баз данных.
В первоначальном варианта Питера Чена сущности представляются прямоугольниками. Свойства сущностей представлены в виде овалов, а связи между сущностями заключены в ромб. Сущности и их свойства соединены между собой.
Вернемся к примеру сущности «Самолет». Его примитивная ER-диаграмма выглядит так:
Имейте ввиду, что имя сущности — это имя типа сущности, а не некоторого конкретного экземпляра этой сущности. Диаграмма описывает структуру данных, а не сами данные.
Рисовать по одной сущности на диаграмму, конечно, имеет мало смысла. Вся суть ER-моделирования раскрывается, когда сущностей больше.
Немного усложним нашу модель:
На диаграмму добилась новая сущность «Аэропорт» со своими атрибутами. Между сущностями мы установили связь «На учёте». Обратите внимание на символы «1» и «M». Что они означают? Это связь между сущностями.
Связь – это графически изображаемая ассоциация, устанавливаемая между двумя типами сущностей. Через данный рисунок мы сообщаем, что экземпляры сущности «Самолет» могут находиться на учёте ТОЛЬКО В ОДНОМ аэропорту. В свою очередь каждый экземпляр сущности «Аэропорт» может вести учет МНОГИХ самолетов. Такой тип связи называется «Один ко многим» или «1:M».
В оригинальной концепции Питера Чена всего имеется 4 типа связи:
1:M — один ко многим — если сущности из первого набора участвуют в связи не более одного раза, а сущности из второго набора – многократно (как минимум дважды).
1:1 — один к одному — когда каждая сущность в обоих наборах сущностей участвует в связи не более одного раза.
M:1 — многие к одному — если сущности из первого набора участвуют в связи многократно (как минимум дважды), а сущности из второго набора не более одного раза.
M:M — многие ко многим — если сущности в обоих наборах участвуют в связи многократно (как минимум дважды).
Для понимания того, какую связь следует использовать:
Ещё одна характеристика связи — полнота. Связь может быть полной или частичной.
Пусть R — тип связи, а E — сущность:
Полная связь — все экземпляры E связаны хотя бы одним экземпляром R
Частичная связь — некоторые экземпляры E могут не иметь связей R
Обратите внимание: в ER-модели полная или частичная связь — это односторонняя характеристика, которая описывает обязательность связи для конкретной сущности, а не для связи в целом.
Например в нашей модели аэропорта мы можем договориться, что самолет всегда ДОЛЖЕН стоять на учёте в каком-нибудь аэропорту. Тогда такая связь будет полной. Аэропорт, напротив, может и не содержать самолетов вовсе. Тогда такая связь будет частичной.
В нотации Питера Чена полная связь обозначается двойной линией в то время как частичная связь обозначена одной линией. Внесем правки в нашу диаграмму:
Возможно вы заметили, что наша модель вообще-то содержит критическую ошибку. Посмотрите на атрибуты сущности «Самолет». Учли ли мы все условия для сущности?
Подсказка: с сущностью «Аэропорт» все хорошо. Увидели?
Дело в том, что наш «Самолет» не обладает идентичностью. Ни одно из его свойств не может гарантировать того, что мы не получим 2 разных экземпляра с абсолютно одинаковыми данными. Чтобы избежать таких конфликтов существует понятие ключевого атрибута.
Ключевыми атрибутами могут быть:
Отдельный атрибут;
Комбинация атрибутов.
Как я и сказал, с сущностью «Аэропорт» все хорошо потому что у него есть атрибут «Код аэропорта» который выступает в качестве уникального идентификатора для каждого экземпляра. Имена ключевых свойств обычно подчеркиваются. Исправим схему:
Подтипы и супертипы сущностей
Каждая сущности имеет как минимум один тип (это она сама). Однако сущность может обладать одновременно несколькими типами.
Сущность «Самолет» может включать подтипы:
«Военный самолет»;
«Пассажирский самолет».
Тогда можно сказать, что тип сущности «Военный самолет» представляет собой подтип типа сущности «Самолет». Или, что эквивалентно, тип сущности «Самолет» является супертипом типа сущности «Военный самолет».
Принцип наследования:
Свойства:
Подтипы наследуют все атрибуты супертипа (например, «Вес самолета», «Вместимость» от «Самолета»).
Обратное утверждение неверно: подтипы могут иметь уникальные свойства, отсутствующие у супертипа (например, атрибут «Калибр орудий» применим только к «Военному самолету»).
Связи:
Подтипы автоматически участвуют во всех связях супертипа (например, если «Самолет» связан с «Авиакомпанией» или «Атмосферой земли», то и его подтипы наследуют эту связь).
Супертип не наследует связи подтипов (например, связь «Входит в список трофейных» может существовать только для «Военного самолета»).
Совокупность супертипа, его прямых подтипов и подтипы этих подтипов образует иерархию типов сущности.
Особенности механизма наследования в ER-модели определяются следующими правилами:
Если у типа сущности A имеются подтипы:
То любой экземпляр типа сущности B является экземпляром типа сущности A. (включение).
Если a является экземпляром типа сущности A, то a является экземпляром некоторого подтипа B (отсутствие собственных экземпляров у супертипа).
Ни для каких подтипов B_i и B_j не существует экземпляра, типом которого одновременно являются типы сущности B_i и B_j (разъединённость подтипов).
Говоря проще:
Любой военный самолет это «Самолет».
Если у нас есть самолет, то он либо пассажирский либо военный. Просто «Самолетом» он быть не может.
Военный самолет не может быть одновременно пассажирским самолетом и наоборот.
Всегда понятнее на примере:
Как видно из рисунка: пассажирский и военный самолет наследует свойства супертипа «Самолет», но «Самолет» сам является подтипом «Созданное человеком», поэтому наследуемых свойств будет больше. Можно заметить — тип «Созданное человеком» не имеет ключевого атрибута. В теории мы можем сделать все его атрибуты ключевыми, но всё равно не застрахованы от возможного дубликата. Но нам и не нужны ключевые атрибуты в данном случае, ведь экземпляр не может принадлежать супертипу «Созданное человеком», а значит, вынужден становиться одним из подтипов. А вот уже в подтипах у нас имеется ключевой атрибут. Конфликта не будет.
В нашем случае подтип у «Созданное человеком» только один — это «Самолет». Но «Самолет» тоже является супертипом, поэтому цикл идет дальше, пока не закончатся супертипы.
Посмотрим теперь на нашу схему:
Мы добавили на схему наши наследованные типы и кое-что ещё.
Простое или составное свойство — свойство Вместимость может быть составным, если его значение составляется из значений простых свойств. Например вместимость на разных участках территории. Другой пример составного свойства ФИО, состоит из простых Фамилия, Имя, Отчество.
Базовое или производное свойство — например возраст можно вычислить если знать дату появления на свет. Другой пример это сумма чека, ее можно вычислить сложив цену всех позиций в заказе. Изображается как эллипс с пунктирным контуром.
Обычные и слабые сущности — слабой называется такая сущность, существование которой зависит от другой сущности. В нашем примере «Главный чел» существует только пока существует «Зона стоянки самолетов». Как только её не станет, не станет и «Главного чела». На диаграмме слабые сущности выделяются двойным контуром. Имейте ввиду, некоторые авторы вместо обычная сущность говорят сильная сущность.
Другие представления ER-модели
Все диаграммы выше выполнены в нотации Питера Чена. Но она не единственная. Существует и другие нотации с немного другими правилами оформления диаграмм.
Выбор нотации это по большей части вкусовщина. Ваша первостепенная задача — это донести смысл через визуальную диаграмму. Делать это можно с помощью любой нотации.
Но лично мне не нравится в нотации Чена подход к изображению связи. В университете мы использовали четвертый вариант на картинке. И поэтому мне привычнее работать немного с другим представлением ER-модели.
Вот например иной способ отобразить связи между сущностями:
Вместо рисования ромбиков связи Crow's Foot прокладываются напрямую от сущности к сущности. Если связь идет от А к Б, то Б это та сущность, возле которой находится «лапка».
Также используем нотации Мартина для удобного отображения сущностей. Выглядит это так:
«Аэропорт»:
ноль или один управляющих
ноль или много самолетов
«Самолет»:
один и только один закрепленный аэропорт
«Главный чел»:
один и только один аэропорт в подчинении
На замену ромбикам и стиля линий пришли (имхо) более понятные обозначения связи. Рисовать их уж точно проще.
Также вместо эллипсов все свойства теперь пишутся прямо в сущности, что экономит место и помогает ориентироваться.
Инфологическая и даталогическая модель
Инфологическую (концептуальную) модель мы уже построили выше. Это абстрактное описание предметной области, отражающее её сущности, атрибуты и связи без привязки к конкретной СУБД. Такая модель вообще не обязательно должна относится к базам данных. С её помощью можно проектировать, например, работу веб-сервисов.
Даталогическая модель — это представление данных с учётом правил конкретной СУБД (например, реляционной). На ней мы разбиваем сущности на таблицы, указываем домены атрибутов, нормализуем при необходимости.
Вот пример инфологической модели университета:
Для того, чтобы сделать из этого даталогическую модель, используются некоторые правила преобразования.
Каждый простой тип сущности(который не имеет подтипов) превращается в таблицу:
Имя сущности становится именем таблицы.
Каждый атрибут становится столбцом таблицы.
Экземпляр типа сущности становится строкой таблицы.
Уникальный идентификатор сущности становятся первичным ключом таблицы.
Первичный ключ (Primary Key) — уникальный идентификатор кортежа (например, student_id). Не допускает NULL или дубликатов.
Внешний ключ (Foreign Key) — связь между таблицами. Указывает на первичный ключ другой таблицы.
Преобразования связей:
Связь типа 1:М (один ко многим) между отношениями реализуется через внешний ключ. Ключ вводится для того отношения, к которому осуществляется множественная связь
Связь типа М:М (многие ко многим) Этот тип связи реализуется через вспомогательную таблицу, которое является соединением первичных ключей из связанных таблиц
Связь «один к одному» между двумя типами сущности A и B — соответствующий внешний ключ по желанию проектировщика может быть объявлен как в таблице A, так и в таблице B.
По итогу преобразований получим:
Обратите внимание, как преобразована связь М:М (многие ко многим) между Преподаватели и Все Дисциплины , для этого введена вспомогательная таблица Дисциплина , которая содержит первичные ключи из таблиц Преподаватели и Все Дисциплины , но в качестве внешних.
Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud — в нашем Telegram-канале ↩
