Вопрос:
Хотя эта тема, должно быть, была задана многими людьми, поэтому необходимо сообщить, что я не прошу запроса!
Вопрос теоретический: как можно различать в базе данных, какая таблица является родительской, а какая является дочерней?
Из того, что я узнал, является то, что таблица с первичным ключом обычно является родительской таблицей (также называемой Look up Table), а таблица с внешним ключом – дочерней таблицей. Я прав?
Лучший ответ:
В большинстве случаев, если в таблицах имеется ссылочная целостность, вы можете изучить внешние ключи для определения отношений родитель-потомок. В дочерней таблице есть внешний ключ, который ссылается на родителя. Таким образом, все дочерние элементы одного родителя будут иметь одинаковое значение для внешнего ключа.
Например, в следующем соотношении:
CREATE TABLE Table1 ( — Key for Parent Table1ID INT CONSTRAINT PK_Table1 PRIMARY KEY, ); CREATE TABLE Table2 ( — Key for Child Table2ID INT CONSTRAINT PK_Table2 PRIMARY KEY, — Foreign Key to Parent Table1ID INT CONSTRAINT FK_Table2_Table1 REFERENCES Table1(Table1ID) );
И в диаграммах:
Table2 является дочерним элементом Table1, потому что Table2 имеет внешний ключ для своего родителя. (Извинения за имена, но вызов таблиц ” Parent и Child победил бы анализ).
Если внешних ключей нет
Это может быть сложнее. Ищите доказательства, такие как:
- Соглашения об именах столбцов – часто столбцы внешнего ключа имеют форму <TableName>Id – это может помочь.
- Использование – искать другие сущности базы данных, как представления, процедуры хранения, правила или функции, и в частности, для того, как таблицы JOIN – й изд вместе – это может быть полезно при определении отношения между таблицами.
Ложные положительные
В терминах “OO” отношения родительские и дочерние элементы базы данных обычно эквивалентны OO Composition, т.е. ребенок не может существовать без родителя.
Однако обратите внимание, что внешние ключи базы данных также обычно используются для:
- Отношения между родителями и детьми, такие как классификация
например
CREATE TABLE Person ( … LocationId INT FOREIGN KEY REFERENCES Country(CountryId) )
Здесь, как человек, так и страна могут логически существовать друг без друга, поэтому эти отношения скорее напоминают связь с ОО или Ассоциацией, а не отношения родитель-ребенок.
- Таблицы наследования и расширения
Оба шаблона “Наследование” и “таблица расширений базы данных” моделируются несколько иначе, чем родительский, поскольку второй первичный ключ таблицы также является внешним ключом для первичного ключа родительских таблиц, то есть строка в Table2 должна иметь одну соответствующую строку в Table1, поэтому мощность между Table1 и Table2 равна от 1 to 0..1, тогда как parent-child будет от 1 to 0..n
CREATE TABLE Table1 ( — Key for Parent Table1ID INT CONSTRAINT PK_Table1 PRIMARY KEY, ); CREATE TABLE Table2 ( — Table2 primary key is ALSO a FOREIGN key to Table 1 SomeId INT CONSTRAINT PK_Table2 PRIMARY KEY, CONSTRAINT FK_Table2_Table1 FOREIGN KEY (SomeId) REFERENCES Table1(Table1ID) );
Мертвая распродажа для определения связей OO в моделях баз данных – это существование нескольких таблиц “подкласса”, которые повторно используют И-ссылочный базовый первичный ключ таблицы.
В расширителя стола ( как правило, дизайн запах), вероятно, будет необычно большое количество столбцов в Table1, которые затем переполнения в Table2 (таблицы клиентов Siebel приходят на ум).
Ответ №1
Родительско-дочерняя связь определяется наличием ограничения внешнего ключа. Ограничение обычно создается на дочерней таблице, но это просто синтаксическое – ограничение действительно существует как его собственный объект и связано с обеими таблицами.
В дочерней таблице будет один или несколько столбцов, которые относятся к одному или нескольким столбцам в родительской таблице. Столбец родительских таблиц должен иметь основное или уникальное место ограничения на них.
