Модель «сущность–связь» (или ER-модель ) описывает взаимосвязанные вещи, представляющие интерес в определенной области знаний. Базовая ER-модель состоит из типов сущностей (которые классифицируют вещи, представляющие интерес) и определяет отношения, которые могут существовать между сущностями (экземплярами этих типов сущностей).
В программной инженерии ER-модель обычно формируется для представления вещей, которые бизнес должен помнить для выполнения бизнес-процессов . Следовательно, ER-модель становится абстрактной моделью данных , [1] которая определяет структуру данных или информации, которая может быть реализована в базе данных , как правило, реляционной базе данных .
Моделирование сущности-связи было разработано для баз данных и проектирования Питером Ченом и опубликовано в статье 1976 года [2] с вариантами идеи, существовавшими ранее. [3] Сегодня оно обычно используется для обучения студентов основам структуры баз данных. Некоторые модели ER показывают сущности супер- и подтипов, связанные отношениями обобщения-специализации [4] , и модель ER также может использоваться для указания онтологий , специфичных для предметной области .
Модель ER обычно является результатом систематического анализа для определения и описания данных, созданных и необходимых для процессов в бизнес-области. Как правило, она представляет записи сущностей и событий, отслеживаемых и направляемых бизнес-процессами, а не сами процессы. Обычно она рисуется в графической форме в виде блоков ( сущностей ), соединенных линиями ( отношениями ), которые выражают ассоциации и зависимости между сущностями. Она также может быть выражена в словесной форме, например: одно здание может быть разделено на ноль или более квартир, но одна квартира может быть расположена только в одном здании.
Сущности могут быть определены не только отношениями, но и дополнительными свойствами ( атрибутами ), которые включают идентификаторы, называемые «первичными ключами». Диаграммы, созданные для представления атрибутов, а также сущностей и отношений, могут называться диаграммами сущность-атрибут-связь, а не моделями сущность–связь.
Модель ER обычно реализуется как база данных . В простой реализации реляционной базы данных каждая строка таблицы представляет один экземпляр типа сущности, а каждое поле в таблице представляет тип атрибута. В реляционной базе данных связь между сущностями реализуется путем хранения первичного ключа одной сущности в качестве указателя или «внешнего ключа» в таблице другой сущности.
Существует традиция строить модели ER/данных на двух или трех уровнях абстракции. Концептуально-логическо-физическая иерархия, представленная ниже, используется в других типах спецификаций и отличается от подхода с тремя схемами к программной инженерии .
На первом этапе проектирования информационной системы эти модели используются во время анализа требований для описания информационных потребностей или типа информации , которая должна храниться в базе данных . Метод моделирования данных может использоваться для описания любой онтологии (т. е. обзора и классификации используемых терминов и их взаимосвязей) для определенной области интересов . В случае проектирования информационной системы, основанной на базе данных, концептуальная модель данных на более позднем этапе (обычно называемом логическим проектированием) сопоставляется с логической моделью данных , такой как реляционная модель . Она, в свою очередь, сопоставляется с физической моделью во время физического проектирования. Иногда обе эти фазы называют «физическим проектированием».
Сущность может быть определена как вещь, способная к независимому существованию, которая может быть однозначно идентифицирована и способна хранить данные. [5] Сущность — это абстракция от сложностей домена. Когда мы говорим о сущности, мы обычно говорим о некотором аспекте реального мира, который можно отличить от других аспектов реального мира. [6]
Сущность — это вещь, которая существует либо физически, либо логически. Сущность может быть физическим объектом, таким как дом или автомобиль (они существуют физически), событием, таким как продажа дома или автосервис, или концепцией, такой как клиентская транзакция или заказ (они существуют логически — как концепция). Хотя термин сущность является наиболее часто используемым, следуя Чену, сущности и типы сущностей следует различать. Тип сущности — это категория. Сущность, строго говоря, является экземпляром данного типа сущности. Обычно существует много экземпляров типа сущности. Поскольку термин тип сущности несколько громоздкий, большинство людей склонны использовать термин сущность как синоним.
Сущности можно рассматривать как существительные . [7] Примерами могут служить компьютер, служащий, песня или математическая теорема.
Отношение фиксирует , как сущности связаны друг с другом. Отношение можно рассматривать как глаголы , связывающие два или более существительных. [7] Примерами могут служить отношение «владеет» между компанией и компьютером, отношение «контролирует» между сотрудником и отделом, отношение «исполняет» между артистом и песней и отношение «доказывает» между математиком и гипотезой.
Описанный выше лингвистический аспект модели используется в декларативном языке запросов к базе данных ERROL, который имитирует конструкции естественного языка . Семантика и реализация ERROL основаны на реляционной алгебре реформированного типа (RRA), реляционной алгебре , которая адаптирована к модели сущность-связь и охватывает ее лингвистический аспект.
Сущности и отношения могут иметь атрибуты. Например, сущность сотрудника может иметь атрибут номера социального страхования (SSN), в то время как доказанное отношение может иметь атрибут даты .
Все сущности, за исключением слабых сущностей, должны иметь минимальный набор уникально идентифицирующих атрибутов, которые могут использоваться в качестве уникального / первичного ключа.
Диаграммы сущностей-связей (ERD) не показывают отдельные сущности или отдельные экземпляры отношений. Вместо этого они показывают наборы сущностей (все сущности одного типа сущности) и наборы отношений (все отношения одного типа отношения). Например, конкретная песня является сущностью, коллекция всех песен в базе данных является набором сущностей, съеденное отношение между ребенком и его обедом является отдельным отношением, а набор всех таких отношений ребенок-обед в базе данных является набором отношений. Другими словами, набор отношений соответствует отношению в математике , в то время как отношение соответствует члену отношения.
Также могут быть указаны определенные ограничения по мощности для наборов связей.
Физические представления показывают, как на самом деле хранятся данные.
В оригинальной статье Чена приводится пример отношений и их ролей. Он описывает отношения «брак» и их две роли: «муж» и «жена».
Человек играет роль мужа в браке (отношениях), а другой человек играет роль жены в (том же) браке. Эти слова являются существительными.
Терминология Чена также применялась к более ранним идеям. Линии, стрелки и гусиные лапки некоторых диаграмм больше обязаны более ранним диаграммам Бахмана , чем диаграммам отношений Чена.
Другим распространенным расширением модели Чэня является «наименование» отношений и ролей в виде глаголов или фраз.
Также стало распространенным называть роли такими фразами, как is the owner of и is owned by . Правильные существительные в этом случае — owner и owned by . Таким образом, person playing role of owner , а car playing role of owned by, а не person playing the role of , is the owner of и т. д.
Использование существительных имеет прямую выгоду при создании физических реализаций из семантических моделей. Когда у человека есть два отношения с автомобилем, можно сгенерировать такие имена, как owner_person и driver_person , которые имеют непосредственный смысл. [9]
Изменения в исходной спецификации могут быть полезными. Чен описал кардинальности look-across. Кстати, нотация Баркера–Эллиса , используемая в Oracle Designer, использует same-side для минимальной кардинальности (аналогично необязательности) и роли, но look-across для максимальной кардинальности (вороньей лапки). [ требуется пояснение ]
Исследования Мериса , Элмасри и Навате и других показали, что существует предпочтение к односторонним ролям и минимальным и максимальным мощностям [10] [11] [12] , а исследователи (Фейнерер, Дуллеа и др.) показали, что это более последовательно, когда применяется к n-арным отношениям порядка больше 2. [13] [14]
Дуллеа и др. утверждают: «Нотация «сквозного просмотра», используемая в UML, не отражает эффективно семантику ограничений участия, налагаемых на отношения, где степень выше бинарной».
Файнерер говорит: «Проблемы возникают, если мы работаем в рамках семантики «перекрестного просмотра», используемой для ассоциаций UML. Хартманн [15] исследует эту ситуацию и показывает, как и почему различные преобразования терпят неудачу». (Хотя упомянутое «сведение» является ложным, поскольку две диаграммы 3.4 и 3.5 на самом деле одинаковы) , а также «Как мы увидим на следующих нескольких страницах, интерпретация «перекрестного просмотра» вносит несколько трудностей, которые мешают распространению простых механизмов с бинарных на n-арные ассоциации».
Нотация Чена для моделирования сущности-связи использует прямоугольники для представления наборов сущностей и ромбы для представления отношений, соответствующих объектам первого класса : они могут иметь собственные атрибуты и отношения. Если набор сущностей участвует в наборе отношений, они соединяются линией.
Атрибуты изображаются в виде овалов и соединяются линией только с одной сущностью или набором отношений.
Ограничения мощности выражаются следующим образом:
Атрибуты часто опускаются, поскольку они могут загромождать диаграмму. Другие методы построения диаграмм часто перечисляют атрибуты сущностей внутри прямоугольников, нарисованных для наборов сущностей.
Нотация «воронья лапка», начало которой восходит к статье Гордона Эвереста (1976), [16] используется в нотации Баркера , методе структурного системного анализа и проектирования (SSADM) и инжиниринге информационных технологий . Диаграммы «воронья лапка» представляют сущности в виде блоков, а отношения — в виде линий между блоками. Различные формы на концах этих линий представляют относительную мощность отношений.
Нотация «воронья лапка» использовалась в ICL в 1978 году [17] и применялась в консалтинговой практике CACI . Многие консультанты CACI (включая Ричарда Баркера) пришли из ICL и впоследствии перешли в Oracle UK, где они разработали ранние версии инструментов Oracle CASE , представив нотацию более широкой аудитории.
При такой нотации отношения не могут иметь атрибутов. При необходимости отношения продвигаются до сущностей в их собственных правах: например, если необходимо зафиксировать, где и когда артист исполнил песню, вводится новая сущность «исполнение» (с атрибутами, отражающими время и место), и отношение артиста к песне становится косвенным отношением через исполнение (исполнитель-исполняет-исполнение, исполнение-особенности-песня).
Для обозначения мощности используются три символа:
Эти символы используются парами для представления четырех типов мощности, которые может иметь сущность в отношениях. Внутренний компонент нотации представляет минимум, а внешний компонент представляет максимум.
Пользователи смоделированной базы данных могут столкнуться с двумя известными проблемами, когда возвращаемые результаты отличаются от того, что предполагал автор запроса. Они известны как ловушка веера и ловушка пропасти, и они могут привести к неточным результатам запроса, если их не обработать должным образом во время проектирования модели Entity-Relationship (ER Model).
Первая проблема — ловушка веера. Она возникает, когда (главная) таблица связана с несколькими таблицами в отношении «один ко многим». Проблема получила свое название от визуального вида модели, когда она отображается на диаграмме «сущность–связь», поскольку связанные таблицы «разветвляются» от главной таблицы. Этот тип модели напоминает схему «звезда» , которая является распространенной конструкцией в хранилищах данных. При попытке вычисления сумм по агрегатам с использованием стандартных SQL-запросов на основе главной таблицы результаты могут быть неожиданными и часто неверными из-за способа структурирования связей. Ошибочный расчет происходит из-за того, что SQL обрабатывает каждую связь индивидуально, что может привести к двойному счету или другим неточностям. Эта проблема особенно распространена в системах поддержки принятия решений. Чтобы смягчить ее, необходимо скорректировать либо модель данных, либо сам SQL-запрос . Некоторое программное обеспечение для запросов к базам данных, разработанное для поддержки принятия решений, включает встроенные методы для обнаружения и устранения ловушек веера.
Вторая проблема — ловушка пропасти. Ловушка пропасти возникает, когда модель предполагает существование связи между типами сущностей, но путь между этими сущностями неполный или отсутствует в некоторых случаях.
Например, представьте себе базу данных, в которой Здание имеет одну или несколько Комнат, и эти Комнаты содержат ноль или более Компьютеров. Можно было бы ожидать, что запрос модели выведет список всех Компьютеров в Здании. Однако, если Компьютер временно не назначен в Комнату (возможно, находится в ремонте или хранится в другом месте), он не будет включен в результаты запроса. Запрос вернет только Компьютеры, в настоящее время назначенные в Комнаты, а не все Компьютеры в Здании. Это отражает недостаток модели, поскольку она не учитывает Компьютеры, которые находятся в Здании, но не в Комнате. Чтобы решить эту проблему, потребуется дополнительная связь, напрямую связывающая Здание и Компьютеры. Ловушка пропасти, как и ловушка веера, часто является результатом неспособности полностью представить реальные отношения в модели базы данных.
И ловушка веера, и ловушка пропасти подчеркивают важность того, чтобы модели ER были не только технически правильными, но и точно отражали реальные отношения, которые они призваны представлять. Выявление и устранение этих ловушек на ранних этапах процесса проектирования помогает избежать существенных проблем в дальнейшем, особенно в сложных базах данных, предназначенных для бизнес-аналитики или поддержки принятия решений.
Семантическая модель — это модель концептов, иногда ее называют «платформенно-независимой моделью». Это интенсиональная модель. По крайней мере со времен Карнапа хорошо известно, что: [18]
Экстенсиональная модель — это модель, которая отображается на элементы конкретной методологии или технологии и, таким образом, является «платформенно-специфической моделью». Спецификация UML явно утверждает, что ассоциации в моделях классов являются экстенсиональными, и это на самом деле самоочевидно, если учесть обширный набор дополнительных «украшений», предоставляемых спецификацией сверх тех, которые предоставляются любым из предыдущих кандидатов «языков семантического моделирования». «UML как нотация моделирования данных, часть 2»
Питер Чен, отец моделирования ЭР, сказал в своей основополагающей статье:
В своей оригинальной статье 1976 года Чэнь явно противопоставляет диаграммы «сущность-связь» методам моделирования записей:
Несколько других авторов также поддерживают программу Чэня: [19] [20] [21] [22] [23]
Чэнь находится в согласии с философскими традициями времен древнегреческих философов: Платона и Аристотеля . [24] Сам Платон связывает знание с пониманием неизменных Форм (а именно, архетипов или абстрактных представлений многих типов вещей и свойств) и их отношений друг с другом.
