Какая таблица должна быть главной и дочерней в дизайне базы данных

Я быстро изучаю тонкости проектирования баз данных (то, что еще неделю назад было для меня новым), но я сталкиваюсь с некоторыми вопросами, которые не кажутся сразу очевидными, поэтому я надеялся получить некоторые разъяснения. .

Вопрос, который у меня есть, касается внешних ключей. Как часть моего дизайна, у меня есть таблица Company. Первоначально я включил информацию об адресе непосредственно в таблицу, но, поскольку я надеялся достичь 3NF, я вынес информацию об адресе в отдельную таблицу, Address. Чтобы сохранить целостность данных, я создал строку в Company с именем "addressId" в качестве INT, а таблица Address имеет соответствующий addressId в качестве первичного ключа.

Что меня немного смущает (или то, что я хочу убедиться, что делаю правильно), так это определение того, какая таблица должна быть главной (ссылочной) таблицей, а какая дочерней (ссылающейся) таблицей. При первоначальной настройке я сделал таблицу Address главной, а Company — дочерней. Однако теперь я считаю, что это неправильно из-за того, что должен быть только один адрес для каждой компании, и, если строка компании удалена, я бы хотел, чтобы соответствующий адрес также был удален (удаление КАСКАД).

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


database foreign-keys database-design foreign-key-relationship
person JasCav    schedule 11.05.2010    source источник

Ответы (4)


arrow_upward
2
arrow_downward

Думайте об этом как об отношении имеет или имеет много. Компания определенно имеет адрес (в вашем примере), поэтому это должна быть родительская таблица, а таблица адресов должна ссылаться на таблицу компаний. С другой стороны, если бы один и тот же адрес использовали несколько разных компаний, все могло бы быть наоборот. Так что это также зависит от ваших потребностей (логики, которую вы пытаетесь смоделировать).

person Klaus Byskov Pedersen    schedule 11.05.2010

arrow_upward
2
arrow_downward

Если у компании должен быть один и только один адрес, я бы либо оставил информацию о компании в таблице Company, либо имел столбец CompanyId в таблице Address, но, несмотря на это, похоже, что в этом нет особой пользы. Если данные действительно связаны с Компанией и не используются где-либо еще, хранение данных там все еще является нарушением 3NF.

Если вы хотите указать «Адрес для выставления счетов» и «Адрес доставки», было бы гораздо разумнее иметь таблицу адресов, которая отделена от AddressId, который является столбцом идентификатора, и столбцом CompanyId, который ссылается на компанию. Таблица.

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

person Mitchel Sellers    schedule 11.05.2010

arrow_upward
1
arrow_downward

Если вы хотите удалять адрес каждый раз, когда удаляете компанию, это означает, что адрес напрямую зависит от компании и сохранение адреса в таблице компаний не нарушает 3NF.

Если бы атрибуты адреса зависели от чего-то другого, кроме компании, вы могли бы поместить их в таблицу адресов, чтобы сделать управление адресами более логически последовательным.

Скажем, вы могли бы разбить адрес на country / region / town / street частей, и если бы часть страны компании получила независимость или что-то в этом роде, вы могли бы изменить адрес, просто изменив поле country отколовшихся регионов.

Однако это означает, что вас интересуют адреса как сущности, а не атрибуты, и вам больше не следует их каскадно удалять.

Обновление:

В определениях нормальных форм слово "зависимый" означает "зависимый в моей модели".

Скажем, адрес компании Wall Street, New York, NY, USA.

Если в вашей модели Wall Street зависит от New York, которое зависит от NY, которое зависит от USA, то сохранение его в одной таблице нарушит 3NF.

Однако, если в вашей модели:

  • Wall Street, New York, CA, USA — правильный адрес (значит, вы не собираетесь выдавать ошибку по этому адресу)

  • Никогда не бывает допустимой ситуации, когда вы обновляете адрес компании только, потому что вы делаете то же самое с некоторыми другими компаниями (это означает, что что-то вроде обработки переименования улиц или объединения регионов или выполнения других географические обновления не являются частью ваших обычных бизнес-правил)

, то таблица с адресами находится в 3NF.

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

person Quassnoi    schedule 11.05.2010
comment
Спасибо за ваш ответ. Может быть, я смущен о 3NF. По этой ссылке (office.microsoft.com/en-us/access/HA012242471033 .aspx — прокрутите вниз), 3NF говорит, что третья нормальная форма требует, чтобы не только каждый неключевой столбец зависел от всего первичного ключа, но и чтобы неключевые столбцы были независимы друг от друга. Кажется, что адресная информация не является независимой от другой адресной информации, поэтому я подумал, что она должна быть в отдельной таблице. Я неправильно думаю об этом? - person JasCav; 11.05.2010
comment
Нет, вы правильно понимаете, но ваша таблица адресов также не является 3NF, например, изменение страны потребует от вас также изменения города. 3NF означает сохранение CityID в таблице Address. Это FK для таблицы City, в которой есть Name и StateID. StateID является FK для таблицы State, в которой есть Name и CountryID и т. д. В моем примере вы найдете недостатки, но он должен продемонстрировать, как будет выполняться истинная 3NF. Однако это не всегда прагматичный подход, и преимущества необходимо сопоставлять с увеличением хлопот :) - person D'Arcy Rittich; 11.05.2010
comment
@OrbMan - Хотел бы я поставить вам точку. Такого объяснения я раньше не слышал. Думаю, я только что прочитал, что более высокая нормальная форма лучше, но я не осознавал многих компромиссов, связанных с ней. Спасибо за это объяснение. Действительно ценю это! - person JasCav; 12.05.2010

arrow_upward
0
arrow_downward

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

person HLGEM    schedule 11.05.2010