Модель «сущность-связь» (или модель ER ) описывает взаимосвязанные вещи, представляющие интерес в конкретной области знаний. Базовая модель ER состоит из типов сущностей (которые классифицируют интересующие объекты) и определяет отношения, которые могут существовать между сущностями (экземплярами этих типов сущностей).
В разработке программного обеспечения модель ER обычно формируется для представления вещей, которые бизнесу необходимо запомнить для выполнения бизнес-процессов . Следовательно, модель ER становится абстрактной моделью данных [1] , которая определяет структуру данных или информации, которая может быть реализована в базе данных , обычно в реляционной базе данных .
Моделирование сущностей и связей было разработано для баз данных и проектирования Питером Ченом и опубликовано в статье 1976 года [2] с вариантами идеи, существовавшими ранее [3] , но сегодня оно обычно используется для обучения студентов основам структуры базы данных. Некоторые модели ER показывают сущности супер- и подтипа, связанные отношениями обобщения-специализации, [4] и модель ER может использоваться также в спецификации онтологий , специфичных для предметной области .
Модель ER обычно является результатом систематического анализа, позволяющего определить и описать, какие данные создаются и необходимы процессам в определенной области бизнеса. Обычно он представляет собой записи объектов и событий, которые отслеживаются и управляются бизнес-процессами, а не сами процессы. Обычно он изображается в графической форме в виде прямоугольников ( сущностей ), соединенных линиями ( отношениями ), выражающими ассоциации и зависимости между сущностями. Это может быть выражено и в словесной форме, например: одно здание может быть разделено на ноль и более квартир, но одна квартира может располагаться только в одном доме.
Сущности могут быть не только отношениями, но и дополнительными свойствами ( атрибутами ), которые включают в себя идентификаторы, называемые «первичными ключами». Диаграммы, созданные для представления атрибутов, а также сущностей и отношений, можно назвать диаграммами сущность-атрибут-связь, а не моделями сущность-связь.
Модель ER обычно реализуется в виде базы данных . В простой реализации реляционной базы данных каждая строка таблицы представляет один экземпляр типа сущности, а каждое поле в таблице представляет тип атрибута. В реляционной базе данных связь между сущностями реализуется путем хранения первичного ключа одной сущности в виде указателя или «внешнего ключа» в таблице другой сущности.
Существует традиция строить модели ER/данных на двух или трех уровнях абстракции. Приведенная ниже концептуально-логико-физическая иерархия используется в других видах спецификаций и отличается от трехсхемного подхода к разработке программного обеспечения .
На первом этапе проектирования информационной системы эти модели используются во время анализа требований для описания информационных потребностей или типа информации , которая должна храниться в базе данных . Технику моделирования данных можно использовать для описания любой онтологии (т. е. обзора и классификации используемых терминов и их взаимосвязей) для определенной области интересов . В случае проектирования информационной системы, основанной на базе данных, концептуальная модель данных на более позднем этапе (обычно называемом логическим проектированием) сопоставляется с логической моделью данных , такой как реляционная модель ; это, в свою очередь, отображается в физической модели во время физического проектирования. Иногда обе эти фазы называют «физическим проектированием».
Сущность можно определить как вещь, способную к независимому существованию, которая может быть однозначно идентифицирована и способна хранить данные. [5] Сущность представляет собой абстракцию сложностей предметной области. Когда мы говорим о сущности, мы обычно говорим о каком-то аспекте реального мира, который можно отличить от других аспектов реального мира. [6]
Сущность — это вещь, которая существует физически или логически. Сущностью может быть физический объект, такой как дом или машина (они существуют физически), событие, такое как продажа дома или автосервис, или такое понятие, как транзакция или заказ клиента (они существуют логически — как концепция). ). Хотя термин «сущность» используется чаще всего, вслед за Ченом нам следует различать сущность и тип сущности. Тип сущности — это категория. Сущность, строго говоря, является экземпляром данного типа сущности. Обычно существует много экземпляров типа сущности. Поскольку термин «тип объекта» несколько громоздкий, большинство людей склонны использовать его как синоним этого термина.
Сущности можно рассматривать как существительные . [7] Примеры: компьютер, сотрудник, песня, математическая теорема и т. д.
Отношения отражают то , как сущности связаны друг с другом. Отношения можно рассматривать как глаголы , связывающие два или более существительных. [7] Примеры: отношения владения между компанией и компьютером, отношения контроля между сотрудником и отделом, отношения исполнителя между артистом и песней, отношения доказательства между математиком и гипотезой и т. д.
Описанный выше лингвистический аспект модели используется в декларативном языке запросов к базе данных ERROL, который имитирует конструкции естественного языка . Семантика и реализация ERROL основаны на измененной реляционной алгебре (RRA), реляционной алгебре , адаптированной к модели сущность-связь и отражающей ее лингвистический аспект.
И сущности, и отношения могут иметь атрибуты. Примеры: сущность « Сотрудник» может иметь атрибут «Номер социального страхования» (SSN), а доказанные отношения могут иметь атрибут « Дата» .
Все объекты, за исключением слабых объектов, должны иметь минимальный набор уникально идентифицирующих атрибутов, которые могут использоваться в качестве уникального / первичного ключа.
Диаграммы сущность-связь (ERD) не отображают отдельные сущности или отдельные экземпляры отношений. Скорее, они показывают наборы сущностей (все сущности одного типа сущностей) и наборы отношений (все отношения одного типа отношений). Примеры: конкретная песня является сущностью; коллекция всех песен в базе данных представляет собой набор сущностей; съеденные отношения между ребенком и его обедом — это единые отношения ; набор всех таких отношений «ребенок-обед» в базе данных является набором отношений. Другими словами, набор отношений соответствует отношению в математике , а отношение соответствует члену отношения.
Также могут быть указаны определенные ограничения мощности наборов отношений.
Физический вид показывает, как на самом деле хранятся данные.
В оригинальной статье Чена он приводит пример отношений и их ролей. Он описывает отношения «брак» и его две роли «муж» и «жена».
Человек играет роль мужа в браке (отношениях), а другой человек играет роль жены в (том же) браке. Эти слова являются существительными. Это неудивительно; для обозначения вещей требуется существительное.
Терминология Чена также применялась к более ранним идеям. Линии, стрелки и «гусиные лапки» на некоторых диаграммах больше связаны с более ранними диаграммами Бахмана , чем с диаграммами отношений Чена.
Еще одно распространенное расширение модели Чена — «называть» отношения и роли глаголами или фразами.
Также стало распространенным называть роли такими фразами, как « является владельцем» и «принадлежит» . Правильные существительные в данном случае — владелец и владение . Таким образом, человек играет роль владельца , а автомобиль играет роль владения, а не человек играет роль , является владельцем и т. д.
Использование существительных имеет прямую выгоду при создании физических реализаций семантических моделей. Когда у человека есть две связи с автомобилем , можно генерировать такие имена, как Owner_person и driver_person , которые сразу имеют смысл. [9]
Модификации исходной спецификации могут быть полезными. Чен описал кардинальность просмотра. Кроме того, нотация Баркера-Эллиса , используемая в Oracle Designer, использует одну и ту же сторону для минимальной мощности (аналог необязательности) и роли, а для максимальной мощности используется перекрестный взгляд («гусиная лапка»). [ нужны разъяснения ]
Исследования Меризе , Эльмасри и Навате и других показали, что существует предпочтение односторонних ролей, а также минимальной и максимальной мощности [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 , познакомив с этой системой обозначений более широкую аудиторию.
При таком обозначении отношения не могут иметь атрибутов. При необходимости отношения повышаются до самостоятельных сущностей: например, если необходимо зафиксировать, где и когда артист исполнил песню, вводится новая сущность «исполнение» (с атрибутами, отражающими время и место), и отношение артиста к песне становится косвенным отношением через исполнение (исполнитель-исполняет-исполнение, исполнительские особенности-песня).
Для обозначения мощности используются три символа:
Эти символы используются парами для обозначения четырех типов кардинальности, которые сущность может иметь в отношениях. Внутренний компонент обозначения представляет минимум, а внешний компонент представляет максимум.
При использовании смоделированной базы данных пользователи могут столкнуться с двумя хорошо известными проблемами, когда возвращаемые результаты означают нечто иное, чем результаты, предполагаемые автором запроса.
Во-первых, это «ловушка для фанатов». Это происходит с (главной) таблицей, которая связана с несколькими таблицами отношением «один ко многим». Проблема получила свое название от того, как выглядит модель, когда она нарисована на диаграмме «сущность-связь»: связанные таблицы «разветвляются» от главной таблицы. Этот тип модели похож на звездообразную схему — тип модели, используемый в хранилищах данных . При попытке вычислить суммы по агрегатам с использованием стандартного SQL для главной таблицы могут возникнуть неожиданные (и неправильные) результаты. Решение состоит в том, чтобы скорректировать модель или SQL. Эта проблема возникает в основном в базах данных систем поддержки принятия решений, и программное обеспечение, которое запрашивает такие системы, иногда включает специальные методы для решения этой проблемы.
Вторая проблема – это «ловушка пропасти». Ловушка пропасти возникает, когда модель предполагает существование связи между типами сущностей, но между определенными экземплярами сущностей не существует пути. Например, в здании есть одна или несколько комнат, в которых находится ноль или более компьютеров. Можно было бы ожидать, что можно будет запросить модель, чтобы увидеть все компьютеры в здании. Однако компьютеры, которые в данный момент не закреплены за комнатой (поскольку они находятся в ремонте или где-то еще), не отображаются в списке. Другая связь между зданием и компьютерами необходима для захвата всех компьютеров в здании. Эта последняя проблема моделирования является результатом неспособности уловить в модели все отношения, существующие в реальном мире. Подробности см. в разделе «Моделирование сущностей и связей 2».
Семантическая модель — это модель концепций, ее иногда называют «платформенно-независимой моделью». Это интенсиональная модель. По крайней мере, со времен Карнапа хорошо известно, что: [18]
Экстенсиональная модель — это модель, которая сопоставляется с элементами конкретной методологии или технологии и, таким образом, является «моделью, специфичной для платформы». Спецификация UML прямо заявляет, что ассоциации в моделях классов являются экстенсиональными, и это фактически самоочевидно, если принять во внимание обширный набор дополнительных «украшений», предоставляемых спецификацией сверх тех, которые предоставляются любым из предыдущих кандидатов «языков семантического моделирования». «UML как нотация моделирования данных, часть 2»
Питер Чен, отец ER-моделирования, сказал в своей основополагающей статье:
В своей оригинальной статье 1976 года Чен явно противопоставляет диаграммы сущность-связь методам моделирования записей:
Несколько других авторов также поддерживают программу Чена: [19] [20] [21] [22] [23]
Чэнь соответствует философским традициям времен древнегреческих философов: Платона и Аристотеля . [24] Сам Платон связывает знание с пониманием неизменных Форм (а именно, архетипов или абстрактных представлений многих типов вещей и свойств) и их отношений друг к другу.
