Чем отличается схема ER и схема базы данных?

Ответ 1

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

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

Диаграмма отношений сущностей. Показывает связи между сущностями и вид отношений между ними. Мы не говорим о таблицах или ключах! Обычно диаграмма отношений сущностей следует модели Merise. Менеджер баз данных и разработчик, как я обычно, строят модель отношения сущности, прежде чем задумывать реляционную модель/диаграмму.
Набор символов в Merise: (0-1, 0-n, 1-1, 1-n). Первое число 0 или 1 описывает, требуется ли другая часть ассоциации для существования объекта. Если он равен нулю, это означает, что он может существовать без привязки. Если это один, это означает, что объект существует только по отношению к другому объекту (например, яблоку нужно, чтобы дерево существовало → 1, дерево не должно существовать яблоком → 0) Второй персонаж сообщает нам, сколько объектов принято в другой части ассоциации. Если это 1, то в отношении может существовать только один объект, если он равен n, можно связать бесконечное число объектов (например: яблоко может иметь одно дерево → 1, дерево может иметь кратные яблоки → n)

С отношением Entity отношение будет описано как: Яблоко должно принадлежать хотя бы одному дереву к существованию и может принадлежать только одному дереву (1-1). Дереву не нужно существование яблока, но оно может иметь бесконечное количество яблок (0-n).

Фактически оба описания означают одно и то же, но одно - ориентированное на базу данных, а другое - ориентированное на моделирование. Некоторые программные средства моделирования, такие как DB-MAIN, автоматически преобразуют диаграмму ER в реляционную диаграмму.

Ответ 2

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

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

Ответ 3

ДИАГРАММЫ СВЯЗИ ДЕЙСТВИЙ (ERD) - это только то, что: ДИАГРАММЫ, которые описывают ОТНОШЕНИЯ между ENTITIES. Теперь давайте посмотрим поближе...

• ERD часто создаются бизнес-аналитиками (не администраторами баз данных);
• ERD часто описываются в терминах LAYMAN (NOT техно-говорящих о администраторах баз данных или других);
• ERD предназначены для обобщения и разъяснения понимания для конечных пользователей и бизнес-SME (опять же, не для администраторов баз данных или разработчиков).
• ERD работают лучше всего, когда каждый объект описан в SINGULAR, а строки, соединяющие различные объекты с другими объектами в ERD, используют глаголы (действия или владения или существования) для описания каждого отношения;
• ERD могут (и делать) включать строки, которые обозначают отношения n: n, но это не является обязательным требованием.
• Примеры объектов в ERD для блога: Участник, Сообщение, Комментарий, Категория
• Примеры отношений, описанных в ERD:
  • Member "posts" от 1 до n Сообщений; (обратите внимание, что мы НЕ описываем, как выглядит сообщение)
  • Опубликовать "релевантные к" от 1 до n Категории и др.

СХЕМЫ ДАННЫХ имеют некоторое сходство с ERD, но они НЕ должны рассматриваться как эквивалентные или взаимозаменяемые. Если вы создаете ERD, который может использоваться в качестве схемы данных... быть открытым для возможности, которую вы НЕ сделали ERD!;-)

Схемы DATA - это диаграммы, используемые для описания DBA, как данные будут храниться в базе данных (реляционной или нереляционной).

• Схемы данных почти неизменно описывают структуру и характеристики ТАБЛИЦ;
• Таблицы - это "контейнеры" (картонные коробки);
• Так как такие таблицы в схеме данных BEST называются в PLURAL
• Примеры таблиц в SCHEMA для одного и того же блога: MEMBERS, POSTS, CATEGORIES, COMMENTS (реляционная база данных) или POSTS (с ключом-Member-Date и всеми остальными столбцами в 1 таблице (нереляционная база данных, например, для проекта с большими данными);

• схема данных затем будет описывать данные, содержащиеся в каждой таблице:

  MEMBER 
  FirstName (char:25)
  LastName (char:25)
  

  и др.

• строки между таблицами в схеме данных НЕ пытались бы представить какое-либо "отношение", отличное от "КЛЮЧА" между двумя полями, которые можно было бы использовать для "объединения" таблиц, а также некоторые дополнительные характеристики этих строк для обозначения n: n отношений.

Оба диаграммы служат довольно РАЗЛИЧНЫМИ целями: ERD: сделать простых смертных конечных пользователей (и владельцев бизнеса) ПОНИМАТЬ модель данного бизнес-решения; а также СХЕМА ДАННЫХ: "план", используемый базами данных DBA для BUILD, и разработчиками, чтобы ПОТРЕБИТЬ данные в этой базе данных.