Является ли этот подход правильным, или мне пришлось создать более двух таблиц?
Для конкретного вопроса, который вы задаете, этот подход является правильным, но он не является реляционным (отмечая тег), и поэтому в нем отсутствуют надлежащие или ожидаемые ограничения.
Я хочу преобразовать диаграмму ER в схему RM
Короткий ответ: вы можете 'т. Конечно, будут проблемы.
При моделировании на уровне отношений сущностей, который находится на ранних стадиях, существует предел того, что можно сделать. В конце концов вы должны перейти к моделированию на уровне Table-Key-Attribute, где можно определить и определить гораздо больше свойств для каждого элемента. Хотя этот первый шаг можно назвать «преобразованием», он ни в коем случае не является достаточно полным для реализации (подразумевается под «схемой»).
ER-моделирование действительно примитивно, оно не используетсядля реляционного моделирования в реальном мире.
Правильный метод для Реляционное моделирование - IDEF1X , доступный с 1984 года, и как стандарт с 1993 года. этапы таблицы;Таблица-Key;Таблица-Key-атрибутов. Реляционное моделирование имеет полный набор реляционных статей, таких как независимые и зависимые таблицы;правильная обработка составных ключей;Идентификация против неидентифицирующих отношений;и т.д., о котором ER-моделирование полностью не знает.
Довольно печально, что Реляционное моделирование не преподается, что вместо этого преподается примитивный до-реляционный метод ER-моделирования.
Нельзя перейти с уровня ER на разрешенный уровень реляционного моделирования (подразумеваемый «схемой RM»), поскольку он не обладает свойствами, которые имеют реляционные таблицы, которые можно определить в реляционном моделировании.
Чтобы достичь уровня реляционной схемы, нужно перейти от конечного уровня ER к раннему уровню реляционного моделирования, а затем перейти к полному разрешению.
Если с самого начала используется реляционное моделирование, этап «преобразования» из одного метода моделирования в другой исключается, и ограничения моделирования ER не встречаются. Конечным результатом этой полностью разрешенной модели является реляционная схема.
сущностное отношение • Неограниченный
Сначала позвольте мне сказать, этоотлично, что вы используете значимые ключи, которые являются логическими и, следовательно, реляционными.
- Это выше и вне систем регистрации записей 1960-х годов, которые продвигаются и продаются как «реляционные» «теоретиками». Такие примитивные системы типизируются
Record ID в каждом Файле, объявленном как «ключ», который вводит в заблуждение любого, потому что он не имеет ни одного из свойств Ключа, не говоря уже о Реляционном Ключе.
Однако у вас еще нет полного реляционного контекста, вы не используете составные ключи, и, следовательно, в вашей модели отсутствует реляционная целостность;Относительная сила;и реляционная скорость, которую имеют модели, соответствующие реляционной модели доктора Э. Ф. Кодда . Иначе говоря, вы можете не знать, что возможно в реляционной базе данных или каковы основные требования к ней.
У вас есть это:
Этоимеет различные проблемы, которые типичны для примитивного RFS, которому вас учат. Например:
Капитан, назначенный Команде, не ограничен этой Командой (это позволяет любому Игроку быть Капитаном любая команда)
Игрок определенно зависит, игрок не существует, за исключением его участия в команде (он допускает независимых игроков).
Все отношения Неидентифицируемые (пунктирная линия), типичные для фрагментированных систем, в которых каждая таблица ошибочно объявляется как «независимая».
Реле сущностей • Реляционные
Если мы повысим это значение до Relational:
Команда Независимая
Игрок Зависимый в Команде
- Игрок ПК является (Команда, Игрок)
- отношение
Команда состоит из 0-к-игроков
is Идентификация (сплошная линия)
Теперь FK в Команде для Капитана - это указанный PK в Игроке (Команда, Игрок)
- , в котором Команда является Командой PK
Отношение
Капитан игрока 0-или-1 Команда (в отличие от неограниченного 0-к-n)
теперь затронуто, потому что Плательщик принадлежит только одномуКоманда
DDL
Снова, слишком рано для создания таблиц, но так как вы рассматриваете это:
CREATE TABLE team (
team CHAR(30) NOT NULL,
captain CHAR(50) NOT NULL,
CONSTRAINT pk
PRIMARY KEY ( name ),
CONSTRAINT captains
FOREIGN KEY ( team, captain )
REFERENCES team ( team, player )
)
CREATE TABLE player (
team CHAR(30) NOT NULL,
player CHAR(50) NOT NULL,
CONSTRAINT pk
PRIMARY KEY ( team, player ),
CONSTRAINT consists_of
FOREIGN KEY ( team )
REFERENCES team ( team )
) - Хотяимя столбца, например
name, является правильным для атрибута, оно не является правильным для Identifier , который должен быть назван для идентифицируемой вещи, такой как team, player и т. д. - , если таблица
team имеет атрибут name, отдельный от короткого идентификатораteam, конечно, с именем name.
Обозначения
Все мои модели данных отображаются в IDEF1X , Стандарт моделирования реляционных баз данных с 1993 года
My IDEF1X Введение является необходимым чтением для начинающих
Комментарии
Основная идея заключается в том, что ... каждый бриллиант получает стол.
Ерунда.
На этой стадии моделирования ER каждый ромб представляет собой неразрешенное отношение , а не таблицу. Здесь нет «конверсии», это не определенный шаг (это просто точка, когда человек, продвигающий моделирование ER, должен переключиться на реальный метод моделирования, именно потому, что моделирование ER строго ограничено). Цель моделирования независимо от того, используется ли ERD;или IDEF1X;или цветные шарики, это прогрессивное понимание статей, т.е. переходить от неразрешенного к разрешенному.
Это интеллектуальный, а не клерикальный процесс.
Следовательно, на этом этапе моделирования ER (ваша диаграмма), чтобы перейти к следующемуна стадии, каждый бриллиант должен быть разрешен . То есть диаграмма ER даже не завершена в контексте моделирования ER (опять же, далеко не готова к реализации или «преобразованию» в метод реляционного моделирования).
Первоекаждый алмаз должен быть определен и назван (неназванный алмаз доказывает, что он не разрешен). Это было бы хорошим началом, какого черта это на самом деле.
- неразрешенные отношения могут быть подтверждены как отношения, решенные. Имя будет VerbPhrase , прочитанное от родителя (1) к потомку (n).
- , неразрешенные отношения могут стать таблицей. Имя будет существительное , потому что оно стало чем-то, а вещи названы существительными.
- Вот как выглядит ваш ERD, когда он остается на этой стадии и прогрессирует (только названные алмазы, еще не решенные), проверьте это для себя Прогрессивная ERD .
Каждый многие ко многим отношение, например:
a Fan следует от 0 до n Players, а
a Player сопровождается от 0 до n Fans
остается от n доn отношение
- оно реализовано (имеется в виду позже, в точке, где модель надежна и готова к реализации) в качестве ассоциативной таблицы
PlayerFan. - В момент, когда вы находитесь в моделировании, он остается отношением n-n-n, и ромб удаляется, что означает разрешение.
Каждый отношение 1-ко-многим , например:
Каждая команда состоит из 0-к-игроков
всегда остаются отношения, а не стол. Алмаз удален.
Конечно, отношение 1-ко-многим может перейти к таблице ... но это результат дальнейшего моделирования, несколькоитерации позже, принимая во внимание другие элементы в модели, а не автоматическое «преобразование» в этой точке.
Именно поэтому мы не используем моделирование ER в реальномВ мире мы используем нечто, предназначенное для реляционного моделирования, которое с легкостью обрабатывает реляционные функции, такие как ключи, устраняет «преобразование» и сопутствующую ерунду.