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

Question

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

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

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

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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