Модель "сущность – отношения" - Entity–relationship model

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

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

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

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

Вступление

Модель 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 , представив нотацию более широкой аудитории.

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

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

  • кольцо представляет «нулевой»
  • прочерк представляет собой «один»
  • в лапке вороньей представляет «много» или «бесконечные»

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

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

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

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

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

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

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

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

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

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

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

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

Истоки сущности и отношения

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

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

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

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

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

Философское выравнивание

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

Ограничения

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

Смотрите также

использованная литература

дальнейшее чтение

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