Нормализация базы данных; повторяющиеся поля

У меня есть вопрос о нормализации относительно уровня нормальной формы моего сценария. У меня есть несколько таблиц с одинаковыми полями: имя address1, address2, почтовый индекс и номер телефона;

Client [id, instructor id, name, address, postcode, phone, practical, theory]
Staff [id, office id, name, job, address, postcode, phone]
Registration id, name, address, postcode, phone]
Office [id, manager id, address, postcode,    phone]

Будет ли существовать какая-либо нормальная форма, чтобы разделить их поля на что-то вроде этого...

Client [id, instructor id, details_id, practical, theory]
Staff [id, office id, details_id, phone]
Registration [id, details_id]
Office [id, manager id, details_id]

Details [id, full_name, address1, address2, postcode, phone_no]

Не уверен, что нормализация будет работать так, но это была просто мысль...


database database-normalization
person Callum    schedule 10.01.2013    source источник
comment
Адресная таблица? Да, конечно. Однако я бы оставил имя в сущности. Кто-то, кто столкнулся с подобной проблемой: stackoverflow.com/questions/5530681/normalize-an-address   -  person mcalex    schedule 10.01.2013
comment
Спасибо, но мне было интересно, под какой тип нормализации это подпадает. НФ3? не понимаю на 100%..   -  person Callum    schedule 10.01.2013
comment
Изоляция похожих полей из нескольких таблиц не является вопросом обычных форм. Каждая из ваших исходных таблиц уже является 3NF. Сбор всех похожих данных из нескольких таблиц в одну не является методом нормализации. Причина для того, чтобы сделать что-то подобное, скорее всего, заключается в рационализации вашего кода обслуживания для этой информации. Единственное возможное исключение может быть, если все ваши таблицы являются подтипами некоторого супертипа, который имеет общие свойства адреса. Если это так, то вы немного перевернули отношения. Details на самом деле будет Supertype.   -  person Joel Brown    schedule 10.01.2013
comment
Ой. Теория. Насколько я понимаю, вы находитесь в 3NF и имеете дело с функциональными зависимостями, которые, насколько мне известно, не являются строго частью нормализации. Внесение отдельных адресов в таблицу адресов помогает поддерживать их правильность/проверку и полезно, например, если клиенты также являются сотрудниками. Немного полезной информации о 1/3 пути к этому документу: courses.washington. edu/info200/win12/Чтения/   -  person mcalex    schedule 10.01.2013
comment
Спасибо, это дало мне много информации   -  person Callum    schedule 10.01.2013

Ответы (2)


arrow_upward
2
arrow_downward

Размещение столбцов с одинаковым значением в нескольких таблицах не связано с нормализацией. Это связано с другим формальным принципом построения базы данных. Крис Дейт называет это принципом ортогонального проектирования или POOD.

Насколько я знаю, формальная логика, лежащая в основе POOD, еще не так глубоко исследована или так широко принята, как нормальные формы. Это наблюдение, а не критика.

person Mike Sherrill 'Cat Recall'    schedule 10.01.2013

arrow_upward
-1
arrow_downward

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

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

Это, конечно, не обязательно плохо, это зависит от того, нужен ли вам адрес, если у вас нет клиента.

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

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

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

Требуется немного практики, чтобы перемещать вещи по правильным причинам, но это того стоит.

person M H    schedule 21.03.2020