модель сущности-отношения (или ER-модель ) описывает взаимосвязанные вещи, представляющие интерес в определенной области знаний. Базовая модель ER состоит из типов сущностей (которые классифицируют интересующие вещи) и определяет отношения, которые могут существовать между сущностями (экземплярами этих типов сущностей).
Диаграмма отношения сущность-атрибут-связь для MMORPG с использованием нотации Чена.В разработке программного обеспечения модель ER обычно формируется для представления вещей, которые бизнесу необходимо запомнить для выполнения бизнес-процессов. Следовательно, модель ER становится абстрактной моделью данных, которая определяет структуру данных или информации, которая может быть реализована в базе данных, обычно в реляционной базе данных.
Entity– Моделирование отношений было разработано для базы данных и дизайна Питером Ченом и опубликовано в статье 1976 года с вариантами идеи, существовавшей ранее. Некоторые модели 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 года Чен явно противопоставляет диаграммы сущность-взаимосвязь методам моделирования записей:
Несколько других авторов также поддерживают программу Чена:
Чен соответствует философским традициям времен древнегреческих философов: Платон и Аристотель. Сам Платон связывает знание с восприятием неизменных Форм (а именно, архетипов или абстрактных представлений многих типов вещей и свойств) и их отношений друг с другом.
Викискладе есть средства массовой информации, связанные с моделями отношений сущностей. |