✖


Jump to content

Модель сущность-связь

(Перенаправлено из модели «сущность-связь» )
Диаграмма отношений сущность-атрибут для MMORPG с использованием обозначений Чена.

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

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

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

Введение

[ редактировать ]

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

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

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

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

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

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

Компоненты

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

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

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

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

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

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

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

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

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

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

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

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

Отношения, роли и мощности

[ редактировать ]

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

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

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

Еще одно распространенное расширение модели Чена — «называть» отношения и роли глаголами или фразами.

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

[ редактировать ]

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

Использование существительных имеет прямую выгоду при создании физических реализаций семантических моделей. Когда у человека есть две связи с автомобилем, можно генерировать такие имена, как 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-моделирования, сказал в своей основополагающей статье:

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

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

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

Несколько других авторов также поддерживают программу Чена: [19] [20] [21] [22] [23]

Философский расклад

[ редактировать ]

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

Ограничения

[ редактировать ]
  • Модель ER в первую очередь концептуальна и представляет собой онтологию, выражающую предикаты в области знаний.
  • Модели ER легко используются для представления структур реляционных баз данных (после Кодда и Дейта), но не так часто для представления других типов структур данных (таких как хранилища данных и хранилища документов).
  • Некоторые обозначения модели ER включают символы, показывающие отношения суперподтипа и взаимное исключение между отношениями; некоторые нет.
  • Модель ER не показывает историю жизни объекта (как его атрибуты и/или отношения изменяются со временем в ответ на события). Для многих систем такие изменения состояния нетривиальны и достаточно важны, чтобы гарантировать явную спецификацию.
  • Некоторый [ ВОЗ? ] расширили ER-моделирование с помощью конструкций для представления изменений состояния - подход, поддерживаемый первоначальным автором; [25] примером является Anchor Modeling .
  • Другие моделируют изменения состояний отдельно, используя диаграммы переходов состояний или какой-либо другой моделирования процессов . метод
  • Многие другие виды диаграмм рисуются для моделирования других аспектов систем, включая 14 типов диаграмм, предлагаемых UML . [26]
  • Сегодня даже там, где ER-моделирование может быть полезным, оно встречается редко, поскольку многие используют инструменты, поддерживающие аналогичные типы моделей, в частности диаграммы классов для объектно-ориентированного программирования и модели данных для систем управления реляционными базами данных . Некоторые из этих инструментов могут генерировать код из диаграмм и реконструировать диаграммы из кода.
  • В опросе Броди и Лю [27] не смог найти ни одного примера моделирования сущностей и связей в выборке из десяти компаний из списка Fortune 100. Бадия и Лемир [28] в этом неиспользовании виноваты не только отсутствие рекомендаций, но и отсутствие преимуществ, таких как отсутствие поддержки интеграции данных.
  • Расширенная модель «сущность-связь » (моделирование EER) вводит несколько концепций, не связанных с ER-моделированием, но тесно связанных с объектно-ориентированным проектированием, например, отношения is-a .
  • Для моделирования темпоральных баз данных были рассмотрены многочисленные расширения ER. [29] Точно так же модель ER оказалась непригодной для многомерных баз данных (используемых в приложениях OLAP ); в этой области еще не появилось доминирующей концептуальной модели, хотя они обычно вращаются вокруг концепции куба OLAP (также известного как куб данных в этой области). [30]

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ Багио и Эрп 2022 , с. 72, §4.2.1.
  2. ^ Jump up to: а б Чен, Питер (март 1976 г.). «Модель сущность-связь – к единому представлению данных». Транзакции ACM в системах баз данных . 1 (1): 9–36. CiteSeerX   10.1.1.523.6679 . дои : 10.1145/320434.320440 . S2CID   52801746 .
  3. ^ APG Браун, «Моделирование реальной системы и разработка схемы для ее представления», в Дуке и Нейссене (ред.), Описание базы данных , Северная Голландия, 1975, ISBN   0-7204-2833-5 .
  4. ^ «Урок 5: Супертипы и подтипы» . docs.microsoft.com .
  5. ^ Багио и Эрп 2022 , с. 73-74, §4.3.
  6. ^ Бейнон-Дэвис, Пол (2004). Системы баз данных . Бейзингсток, Великобритания: Пэлгрейв: Хаундмиллс. ISBN  978-1403916013 .
  7. ^ Jump up to: а б Багио и Эрп 2022 , с. 112-116, §5.5.
  8. ^ «Английские, китайские и ER-диаграммы» Питера Чена
  9. ^ «Панграмматикон: эмоции и общество» . 3 января 2013 г.
  10. ^ Юбер Тардье, Арнольд Рохфельд и Рене Коллетти Метод MERISE: Принципы и инструменты (Мягкая обложка - 1983)
  11. ^ Эльмасри, Рамез, Б. Шамкант, Навате, Основы систем баз данных, третье изд., Аддисон-Уэсли, Менло-Парк, Калифорния, США, 2000.
  12. ^ Ацени, Паоло; Чу, Уэсли; Лу, Хунцзюнь; Линг, Ток Ван; Чжоу, Шуйген (27 октября 2004 г.). ER 2004: 23-я Международная конференция по концептуальному моделированию, Шанхай, Китай, 8-12 ноября 2004 г. ISBN  9783540237235 .
  13. ^ «Формальная трактовка диаграмм классов UML как эффективного метода управления конфигурацией 2007» (PDF) .
  14. ^ «Джеймс Дуллеа, Иль-Йёль Сонг, Иоанна Лампроу - Анализ структурной достоверности моделирования сущностей-связей, 2002» (PDF) . [ постоянная мертвая ссылка ]
  15. ^ Хартманн, Свен. « Рассуждения об ограничениях участия и ограничениях Чена. Архивировано 10 мая 2013 г. в Wayback Machine ». Материалы 14-й Австралазийской конференции по базам данных, том 17. Австралийское компьютерное общество, Inc., 2003.
  16. ^ Г. Эверест, «БАЗОВЫЕ МОДЕЛИ СТРУКТУРЫ ДАННЫХ, ОБЪЯСНЕННЫЕ НА ОБЩЕМ ПРИМЕРЕ», в Computing Systems 1976, Труды Пятой Техасской конференции по вычислительным системам, Остин, Техас, 1976 г., 18–19 октября, страницы 39–46. (Лонг-Бич, Калифорния: Отдел публикаций Компьютерного общества IEEE).
  17. ^ «Введение в анализ данных», учебная публикация ICL T2384, выпуск 2, ноябрь 1978 г.
  18. ^ «Роль интенсиональной и экстенсиональной интерпретации в семантических репрезентациях» .
  19. ^ Кент в «Данные и реальность» :
    «В начале работы по моделированию нам следует четко уяснить себе, намерены ли мы описать часть «реальности» (некое человеческое предприятие) или деятельность по обработке данных».
  20. ^ Абриал в «Семантике данных»: «... на так называемое «логическое» определение и манипулирование данными все еще влияют (иногда неосознанно) «физические» механизмы хранения и поиска, доступные в настоящее время в компьютерных системах».
  21. ^ Стампер: «Они претендуют на описание типов сущностей, но словарный запас взят из обработки данных: поля, элементы данных, значения. Правила именования не отражают соглашения, которые мы используем для именования людей и вещей; вместо этого они отражают методы поиска записей в файлы».
  22. ^ По словам Джексона : «Разработчик начинает с создания модели реальности, с которой работает система, реальности, которая составляет ее [систему] предмет…»
  23. ^ Эльмасри, Навате: «Концепции модели ER разработаны так, чтобы быть ближе к восприятию данных пользователем и не предназначены для описания способа хранения данных на компьютере».
  24. ^ Паоло Рокки, Вероятность с лицом Януса , Springer, 2014, стр. 62.
  25. ^ П. Чен. Предлагаемые направления исследований для нового рубежа: Активное концептуальное моделирование . ER 2006, том 4215 конспектов лекций по информатике, страницы 1–4. Шпрингер Берлин / Гейдельберг, 2006.
  26. ^ Карт, Трейси А.; Джасперсон, Джон (Шон); и Корнелиус, Марк Э. (2020) «Интеграция концепций ERD и UML при обучении моделированию данных», Journal of Information Systems Education: Vol. 17: Вып. 1, статья 9.
  27. ^ Мощь и ограничения реляционных технологий в эпоху информационных экосистем. Архивировано 17 сентября 2016 г. в Wayback Machine . Федеративные конференции в движении, 2010 г.
  28. ^ А. Бадиа и Д. Лемир. Призыв к оружию: новый взгляд на проектирование баз данных . Citeseerx,
  29. ^ Грегерсен, Хайди; Дженсен, Кристиан С. (1999). «Временные модели сущностей-отношений - опрос». Транзакции IEEE по знаниям и инженерии данных . 11 (3): 464–497. CiteSeerX   10.1.1.1.2497 . дои : 10.1109/69.774104 .
  30. ^ РИККАРДО ТОРЛОНЕ (2003). «Концептуальные многомерные модели» (PDF) . В Маурицио Рафанелли (ред.). Многомерные базы данных: проблемы и решения . Идея Групп Инк (IGI). ISBN  978-1-59140-053-0 .

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

[ редактировать ]
[ редактировать ]
В Wikimedia Commons есть медиафайлы, связанные с моделями Entity-Relationship .
Retrieved from "https://en.wikipedia.org/w/index.php?title=Entity–relationship_model&oldid=1222061879"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 78f2cd2c6c7b5c1925fd47058516b295__1714745340
URL1:https://arc.ask3.ru/arc/aa/78/95/78f2cd2c6c7b5c1925fd47058516b295.html
Заголовок, (Title) документа по адресу, URL1:
Entity–relationship model - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)