Модель отношения сущность

редактировать
Модель или диаграмма, описывающая взаимосвязанные вещи

модель сущности-отношения (или ER-модель ) описывает взаимосвязанные вещи, представляющие интерес в определенной области знаний. Базовая модель ER состоит из типов сущностей (которые классифицируют интересующие вещи) и определяет отношения, которые могут существовать между сущностями (экземплярами этих типов сущностей).

Диаграмма отношения сущность-атрибут-связь для MMORPG с использованием нотации Чена.

В разработке программного обеспечения модель ER обычно формируется для представления вещей, которые бизнесу необходимо запомнить для выполнения бизнес-процессов. Следовательно, модель ER становится абстрактной моделью данных, которая определяет структуру данных или информации, которая может быть реализована в базе данных, обычно в реляционной базе данных.

Entity– Моделирование отношений было разработано для базы данных и дизайна Питером Ченом и опубликовано в статье 1976 года с вариантами идеи, существовавшей ранее. Некоторые модели ER показывают сущности супер- и подтипов, связанные отношениями обобщение-специализация, и модель ER может также использоваться в спецификации предметных онтологий.

Содержание

  • 1 Введение
  • 2 Сущность – связь модель
    • 2.1 Отображение естественного языка
    • 2.2 Взаимосвязи, роли и мощности
    • 2.3 Именование ролей
    • 2.4 мощности
    • 2.5 Нотация вороньей лапки
    • 2.6 Проблемы удобства использования модели
  • 3 Сущность - отношения и семантическое моделирование
    • 3.1 Семантическая модель
    • 3.2 Модель расширения
    • 3.3 Истоки сущности и отношения
      • 3.3.1 Философское соответствие
  • 4 Ограничения
  • 5 См. также
  • 6 Ссылки
  • 7 Дополнительная литература
  • 8 Внешние ссылки

Введение

Модель ER обычно является результатом систематического анализа для определения и описания того, что важно для процессов в той или иной области бизнеса. Он не определяет бизнес-процессы; он представляет только схему бизнес-данных в графической форме. Обычно он изображается в графической форме в виде блоков (сущностей), соединенных линиями (отношениями), которые выражают ассоциации и зависимости между сущностями. ER-модель также может быть выражена в словесной форме, например: одно здание может быть разделено на ноль или более квартир, но одна квартира может быть расположена только в одном здании.

Сущности могут характеризоваться не только отношениями, но также дополнительными свойствами (атрибутами), которые включают идентификаторы, называемые «первичными ключами». Диаграммы, созданные для представления атрибутов, а также сущностей и отношений, могут называться диаграммами сущность-атрибут-взаимосвязь, а не моделями сущность-взаимосвязь.

Модель ER обычно реализуется как база данных. В простой реализации реляционной базы данных каждая строка таблицы представляет один экземпляр типа сущности, а каждое поле в таблице представляет тип атрибута. В реляционной базе данных связь между объектами реализуется путем сохранения первичного ключа одного объекта в виде указателя или «внешнего ключа» в таблице другого объекта.

Традиционно модели ER / данных строятся на двух или трех уровнях абстракции. Обратите внимание, что представленная ниже концептуально-логико-физическая иерархия используется в других типах спецификаций и отличается от подхода с тремя схемами до разработки программного обеспечения.

Концептуальная модель данных
Это Модель ER самого высокого уровня в том смысле, что она содержит наименее детализированные детали, но устанавливает общий объем того, что должно быть включено в набор моделей. Концептуальная модель ER обычно определяет сущности основных справочных данных, которые обычно используются организацией. Разработка концептуальной модели ER в масштабе предприятия полезна для поддержки документирования архитектуры данных для организации.
Концептуальная модель ER может использоваться в качестве основы для одной или нескольких логических моделей данных ( увидеть ниже). Цель концептуальной модели ER состоит в том, чтобы установить структурную общность метаданных для объектов основных данных между набором логических моделей ER. Концептуальная модель данных может использоваться для формирования отношений общности между моделями ER в качестве основы для интеграции модели данных.
Логическая модель данных
Логическая модель ER не требует концептуальной модели ER, особенно если объем логической модели Модель ER включает только разработку отдельной информационной системы. Логическая модель ER содержит больше деталей, чем концептуальная модель ER. В дополнение к объектам основных данных теперь определены объекты операционных и транзакционных данных. Подробная информация о каждом объекте данных разрабатывается, и устанавливаются отношения между этими объектами данных. Однако логическая модель ER разрабатывается независимо от конкретной системы управления базами данных, в которой она может быть реализована.
Физическая модель данных
Одна или несколько физических моделей ER могут быть разработаны на основе каждой логической модели ER. Физическая модель ER обычно разрабатывается для создания экземпляра базы данных. Следовательно, каждая физическая модель ER должна содержать достаточно деталей для создания базы данных, и каждая физическая модель ER зависит от технологии, поскольку каждая система управления базой данных несколько отличается.
Физическая модель обычно создается в структурных метаданных базы данных система управления в виде объектов реляционной базы данных, таких как таблицы базы данных, индексы базы данных, такие как индексы уникального ключа, и ограничения базы данных, такие как ограничение внешнего ключа или ограничение общности. ER-модель также обычно используется для разработки модификаций объектов реляционной базы данных и для поддержки структурных метаданных базы данных.

На первом этапе проектирования информационной системы эти модели используются при выполнении требований анализ для описания информационных потребностей или типа информации, которая должна храниться в базе данных. Метод моделирования данных может использоваться для описания любой онтологии (т. Е. Обзора и классификации используемых терминов и их взаимосвязей) для определенной области интересов. В случае проектирования информационной системы, основанной на базе данных, концептуальная модель данных на более позднем этапе (обычно называемом логическим проектированием) отображается в логическую модель данных, например, реляционная модель ; это, в свою очередь, отображается в физической модели во время физического проектирования. Обратите внимание, что иногда обе эти фазы называют «физическим проектированием».

Модель отношения сущность

Две связанные сущности Сущность с атрибутом Отношение с атрибутом Первичный ключ

Объект может быть определяется как вещь, способная к независимому существованию, которую можно однозначно идентифицировать. Сущность - это абстракция от сложности предметной области. Когда мы говорим о сущности, мы обычно говорим о каком-то аспекте реального мира, который можно отличить от других аспектов реального мира.

Сущность - это вещь, которая существует либо физически, либо логически. Сущность может быть физическим объектом, таким как дом или автомобиль (они существуют физически), событием, таким как продажа дома или автосервис, или концепцией, такой как транзакция или заказ клиента (они существуют логически - как концепция). Хотя термин «сущность» является наиболее часто используемым, вслед за Ченом мы действительно должны различать сущность и тип сущности. Тип сущности - это категория. Строго говоря, сущность - это экземпляр данного типа сущности. Обычно существует много экземпляров типа сущности. Поскольку термин тип сущности несколько громоздок, большинство людей склонны использовать термин сущность в качестве синонима этого термина

Сущности можно рассматривать как существительные. Примеры: компьютер, сотрудник, песня, математическая теорема и т. Д.

Отношение фиксирует, как сущности связаны друг с другом. Отношения можно рассматривать как глаголы, связывающие два или более существительных. Примеры: отношения «владелец» между компанией и компьютером, отношения «контролирует» между сотрудником и отделом, отношения «перформанс» между исполнителем и песней, взаимосвязь между математиком и гипотезой и т. Д.

Лингвистический аспект модели, описанный выше, используется в декларативной базе данных языке запросов ERROL, который имитирует конструкции естественного языка. Семантика и реализация ERROL основаны на преобразованной реляционной алгебре (RRA), реляционной алгебре, которая адаптирована к модели сущность-отношения и отражает ее лингвистический аспект.

И сущности, и отношения могут иметь атрибуты. Примеры: организация-сотрудник может иметь атрибут номера социального страхования (SSN), а доказанная связь может иметь атрибут даты.

Все объекты, кроме слабых объектов, должны иметь минимальный набор однозначно идентифицирующих атрибутов, которые могут использоваться как уникальный / первичный ключ.

На диаграммах сущность – отношения не отображаются отдельные сущности или отдельные экземпляры отношений. Скорее, они показывают наборы сущностей (все сущности одного типа сущности) и наборы отношений (все отношения одного типа). Примеры: конкретная песня - это сущность; коллекция всех песен в базе данных представляет собой набор сущностей; отношения съеденного между ребенком и его обедом - это отношения одиночества; набор всех таких отношений ребенок-обед в базе данных является набором отношений. Другими словами, набор отношений соответствует отношению в математике, в то время как отношение соответствует члену отношения.

Также могут быть указаны некоторые ограничения мощности для наборов взаимосвязей.

Отображение естественного языка

Чен предложил следующие «практические правила» для отображения описаний естественного языка в ER-диаграммы: «Английский, китайский и ER-диаграммы» Питера Чена.

Структура грамматики английского языкаСтруктура ER
Нарицательное существительное Тип сущности
Имя собственное Сущность
Переходный глагол Тип отношения
Непереходный глагол Тип атрибута
Прилагательное Атрибут для объекта
Наречие Атрибут для отношения

Физическое представление показывает, как на самом деле хранятся данные.

Взаимосвязи, роли и мощности

В оригинальной статье Чена он приводит пример отношений и их ролей. Он описывает отношения «брак» и две его роли - «мужа» и «жены».

Человек играет роль мужа в браке (отношениях), а другой человек играет роль жены в (одном) браке. Эти слова - существительные. Это не удивительно; для называния вещей требуется существительное.

Терминология Чена также применялась к более ранним идеям. Линии, стрелки и "гусиные лапки" на некоторых диаграммах больше обязаны более ранним диаграммам Бахмана, чем диаграммам отношений Чена.

Другое распространенное расширение модели Чена - это «называть» отношения и роли глаголами или фразами.

Именование ролей

Также стало распространено называть роли с помощью таких фраз, как «владелец» или «принадлежит». Правильные существительные в этом случае - владелец и владение. Таким образом, человек играет роль владельца, а автомобиль играет роль владения, а не личность играет роль, является владельцем и т. Д.

Использование существительных дает прямую выгоду при создании физических реализаций из семантических моделей. Когда у человека есть два отношения с автомобилем, можно сгенерировать имена, такие как owner_person и driver_person, которые сразу же имеют смысл.

мощности

Модификации исходной спецификации могут быть полезными. Чен описал. Кроме того, нотация Баркера – Эллиса, используемая в Oracle Designer, использует одну и ту же сторону для минимальной мощности (аналогично факультативности) и роли, но просматривает максимальную мощность (воронья нога).

В Merise, Elmasri Navathe и других предпочтение отдается ролям одной стороны, а также минимальной и максимальной мощности. Недавние исследователи (Feinerer, Dullea et al.) Показали, что это более логично, когда применяется к n-арным отношениям порядка выше 2.

В Dullea et al. можно прочитать: «Нотация« взгляд сквозь », такая как используемая в UML, не эффективно представляет семантику ограничений участия, налагаемых на отношения, где степень выше двоичной».

В Feinerer говорится: «Проблемы возникают, если мы работаем в рамках семантики просмотра, используемой для UML-ассоциаций. Хартманн исследует эту ситуацию и показывает, как и почему различные преобразования терпят неудачу». (Хотя упомянутая «редукция» является ложной, поскольку две диаграммы 3.4 и 3.5 на самом деле одинаковы), а также «Как мы увидим на следующих нескольких страницах, сквозная интерпретация представляет несколько трудностей, которые препятствуют расширению простых механизмов. от двоичных ассоциаций к n-мерным ".

Различные методы представления одного и того же отношения "один ко многим". В каждом случае диаграмма показывает взаимосвязь между человеком и местом рождения: каждый человек должен был родиться в одном и только в одном месте, но в каждом месте могло быть ноль или более людей, родившихся в нем. Два связанных объекта показаны с использованием обозначения "Гусиная лапа". В этом примере показана необязательная связь между исполнителем и песней; символы, наиболее близкие к сущности песни, представляют «ноль, один или несколько», тогда как в песне есть «один и только один» исполнитель. Таким образом, первое читается как «Артист (может) исполнять (и)" ноль, одну или несколько "песен).

Нотация Чена для моделирования сущностей-отношений использует прямоугольники для представления наборов сущностей и ромбы для представления отношения, подходящие для первоклассных объектов : они могут иметь собственные атрибуты и отношения. Если набор сущностей участвует в наборе отношений, они связаны линией.

Атрибуты нарисованы в виде овалов и соединены линией ровно с одним объектом или набором отношений.

Ограничения мощности выражаются следующим образом:

  • двойная линия указывает ограничение участия, совокупность или сюръективность : все сущности в наборе сущностей должны участвовать в по крайней мере одно отношение в наборе отношений;
  • стрелка от набора сущностей к набору отношений указывает ключевое ограничение, то есть приемистость : каждый объект набора сущностей может участвовать не более чем в одной взаимосвязи в наборе взаимосвязей;
  • жирная линия обозначает обе, то есть биективность : каждый объект в наборе объектов участвует ровно в одной взаимосвязи.
  • подчеркнутое имя атрибута указывает, что это ключ : два разных объекта или отношения с этим атрибутом всегда имеют разные значения для этого атрибута.

Атрибуты часто опускаются, поскольку они могут загромождать диаграмму; другие методы диаграмм часто перечисляют атрибуты сущностей в прямоугольниках, нарисованных для наборов сущностей.

Связанные методы условного обозначения диаграмм:

Нотация вороньей стопы

Нотация вороньей стопы, начало из которых восходит к статье Гордона Эвереста (1976), используется в нотации Баркера, Структурный системный анализ и метод проектирования (SSADM) и разработка информационных технологий. Диаграммы "гусиные лапки" представляют объекты в виде блоков, а отношения - в виде линий между блоками. Различные формы на концах этих линий представляют относительную мощность отношения.

В консультационной практике использовалось обозначение «гусиная лапка» CACI. Многие консультанты CACI (включая Ричарда Баркера) впоследствии переехали в Oracle UK, где они разработали ранние версии инструментов Oracle CASE, представив нотацию более широкой аудитории.

В этом обозначении отношения не могут иметь атрибутов. При необходимости отношения продвигаются до самостоятельных сущностей: например, если необходимо зафиксировать, где и когда исполнитель исполнил песню, вводится новая сущность «перформанс» (с атрибутами, отражающими время и место), и отношение исполнителя к песне становится косвенным отношением через перформанс (исполнитель-исполняет-перформанс, перформанс-особенности-песня).

Три символа используются для представления количества элементов:

  • кольцо представляет «ноль»
  • тире представляет «один»
  • гусиная лапка представляет «много» или « infinite "

Эти символы используются парами для представления четырех типов мощности, которые объект может иметь во взаимосвязи. Внутренний компонент записи представляет минимум, а внешний компонент - максимум.

  • кольцо и тире → минимум ноль, максимум один (необязательно)
  • тире → минимум один, максимум один (обязательно)
  • кольцо и гусиная лапка → минимум ноль, максимальное количество (необязательно)
  • рывок и гусиная лапка → минимальное количество, максимальное количество (обязательно)

Проблемы удобства использования модели

При использовании смоделированной базы данных пользователи могут столкнуться с двумя хорошо известными проблемами: возвращенные результаты означают нечто иное, чем результаты, предполагаемые автором запроса.

Первая - это «ловушка вентилятора». Это происходит с (главной) таблицей, которая связана с несколькими таблицами в отношении «один ко многим». Проблема получила свое название от того, как модель выглядит, когда она нарисована на диаграмме сущность – связь: связанные таблицы «расходятся» из главной таблицы. Этот тип модели похож на схему «звезда» , тип модели, используемый в хранилищах данных. При попытке вычислить суммы по агрегатам с использованием стандартного SQL по главной таблице могут возникнуть неожиданные (и неверные) результаты. Решение состоит в том, чтобы скорректировать модель или SQL. Эта проблема возникает в основном в базах данных для систем поддержки принятия решений, и программное обеспечение, которое запрашивает такие системы, иногда включает специальные методы для решения этой проблемы.

Вторая проблема - это «ловушка пропасти». Ловушка пропасти возникает, когда модель предполагает наличие связи между типами сущностей, но пути между определенными экземплярами сущностей не существует. Например, в здании есть одна или несколько комнат, в которых находится ноль или более компьютеров. Можно было бы ожидать, что можно будет запросить модель, чтобы увидеть все компьютеры в здании. Однако Компьютеры, которые в настоящее время не назначены Комнате (потому что они ремонтируются или где-то еще), не отображаются в списке. Другая связь между зданием и компьютерами необходима для захвата всех компьютеров в здании. Эта последняя проблема моделирования является результатом неспособности уловить все взаимосвязи, существующие в реальном мире в модели. Подробнее см. Моделирование отношений сущностей 2.

Сущность – отношения и семантическое моделирование

Семантическая модель

Семантическая модель - это модель концептов, ее иногда называют «платформо-независимой моделью». Это интенсиональная модель. Самое позднее, начиная с Карнапа, хорошо известно, что:

"... полное значение понятия состоит из двух аспектов: его интенсификации и его расширения. Первая часть включает в себя вложение концепт в мире концептов в целом, т.е. совокупность всех отношений к другим концептам. Вторая часть устанавливает референциальное значение концепта, то есть его аналог в реальном или возможном мире ».

Модель расширения

Экстенсиональная модель - это модель, которая сопоставляется с элементами конкретной методологии или технологии и, таким образом, является «моделью для конкретной платформы». Спецификация UML явно заявляет, что ассоциации в моделях классов являются экстенсиональными, и это фактически самоочевидно, если принять во внимание обширный набор дополнительных «украшений», предоставляемых спецификацией сверх тех, которые предоставляются любым из предшествующих кандидатов «языков семантического моделирования».. «UML как нотация моделирования данных, часть 2»

происхождение сущности-отношения

Питер Чен, отец ER-моделирования, сказал в своей основополагающей статье:

«Сущность-связь Модель принимает более естественное представление о том, что реальный мир состоит из сущностей и отношений. Она включает в себя некоторую важную семантическую информацию о реальном мире ».

В своей оригинальной статье 1976 года Чен явно противопоставляет диаграммы сущность-взаимосвязь методам моделирования записей:

«диаграмма структуры данных представляет собой представление организации записей, а не точное представление сущностей. и отношения ».

Несколько других авторов также поддерживают программу Чена:

Философское мировоззрение

Чен соответствует философским традициям времен древнегреческих философов: Платон и Аристотель. Сам Платон связывает знание с восприятием неизменных Форм (а именно, архетипов или абстрактных представлений многих типов вещей и свойств) и их отношений друг с другом.

Ограничения

  • Модель ER в первую очередь концептуальна, онтология, которая выражает предикаты в области знаний.
  • Модели ER легко используются для представления структур реляционных баз данных (после Кодда и Дейта) но не так часто, чтобы представлять другие виды структур данных (хранилища данных, хранилища документов и т. д.)
  • Некоторые нотации моделей ER включают символы для отображения суперподтипных отношений и взаимного исключения между отношениями; некоторые этого не делают.
  • Модель ER не показывает историю жизни объекта (как его атрибуты и / или отношения меняются с течением времени в ответ на события). Для многих систем такие изменения состояния нетривиальны и достаточно важны, чтобы гарантировать явную спецификацию.
  • Некоторые имеют расширенное моделирование ER с конструкциями для представления изменений состояния, подход, поддерживаемый первоначальным автором; пример: Моделирование привязки.
  • Другие состояния модели изменяются отдельно, с использованием диаграмм переходов состояний или какой-либо другой техники моделирования процессов.
  • Многие другие виды диаграмм рисуются для моделирования других аспекты систем, в том числе 14 типов диаграмм, предлагаемых UML.
  • Сегодня, даже там, где моделирование ER могло бы быть полезным, это необычно, потому что многие используют инструменты, которые поддерживают аналогичные типы моделей, особенно диаграммы классов для программирования и данных OO модели для реляционных систем управления базами данных. Некоторые из этих инструментов могут генерировать код из диаграмм и реконструировать диаграммы из кода.
  • В ходе опроса Броди и Лю не смогли найти ни одного примера моделирования отношений сущностей в выборке из десяти компаний из списка Fortune 100. Бадиа и Лемир винят в этом неэффективное использование руководства, но также и недостаток преимуществ, таких как отсутствие поддержки интеграции данных.
  • усовершенствованная модель отношения сущности (EER моделирование) вводит несколько концепций, не связанных с моделированием ER, но тесно связанных с объектно-ориентированным проектированием, например is-a Relationships.
  • Для моделирования временных базы данных были рассмотрены многочисленные расширения ER. Точно так же модель ER оказалась неподходящей для многомерных баз данных (используемых в OLAP приложениях); в этой области еще не появилось доминирующей концептуальной модели, хотя в основном они вращаются вокруг концепции куба OLAP (также известного как куб данных внутри области).

См. также

Ссылки

Дополнительная литература

Внешние ссылки

Викискладе есть средства массовой информации, связанные с моделями отношений сущностей.
Последняя правка сделана 2021-05-19 11:34:41
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте