Вопрос нормализации базы данных

Question

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

Таблица клиентов

ID |  Date_Entered   |  First_Name  |  Middle_Name |  Last_Name |    Maiden_Name 

...

Address__street_dmv | Address_city_dmv  | Address_state_dmv |   Address_zip_dmv

...

Address__street_source2  |  Address_state_source2  |  Address_city_source2  | etc

.

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

.

Адрес

ID  |   Number  |    Street    |  State  |   Zip  |    Source (drop down menu)

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

Источники

Source_ID  |    Source

И как поменять таблицу адресов?

ID  |   Number    |  Street    |  State  |   Zip    |  Source _ID (drop down)

Это не кажется правильным, потому что теперь Source_ID является избыточным ... Пожалуйста, помогите.

Бонусные баллы, если вы можете сказать мне, следует ли мне включать девичье и отчество в таблицу Customer, поскольку они тоже могут иметь значение Null (если нет, как будет структурирована новая таблица?)

Извините за то, что я нуб.

Answer 1

Я бы пошел с чем-то вроде

Клиент

ID |  Date_Entered  |  First_Name  |  Middle_Name | Last_Name | Maiden_Name

Адрес

ID  |   Number  |    Street    |  State_ID  |   Zip

Customers_Address

ID | Customer_ID | Address_ID | Source_ID

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

Table_Street (ID | State_ID | Name)

и затем в таблице Addresses у вас будет только Street_ID вместо Street и State_ID. Это также позволяет отображать список выбора улиц, когда пользователь выбрал штат.

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

Answer 2

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

Ваши адреса, по сути, являются повторяющейся группой, в одном смысле этого слова. Так что имеет смысл удалить их из клиентов. (Это связано с нормализацией; повторяющиеся группы нарушают 1NF.)

«Источник» не является избыточными данными, и решение о том, заменять ли идентификационный номер текстом, не имеет ничего общего с нормализацией.

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

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

Answer 3

Вы также можете попробовать следующий подход:

Клиент

CustomerID (PK) | Date_Entered | First_Name | Middle_Name | Last_Name | Maiden_Name

Адрес

CustomerId (PK) (FK) | SourceID (PK) | Номер | Улица | государство | Zip

Это предполагает отношение «один ко многим» между Клиентом и адресами. Он также полностью исключает таблицу Customer_Address в пользу использования двух таблиц (Customer и Addresses) и определения составного первичного ключа для таблицы адресов в качестве CustomerId и SourceID. В этой модели CustomerId и SourceId однозначно определяют номер, улицу, штат и почтовый индекс. Он также обеспечивает целостность данных, гарантируя, что каждый клиент может иметь только один адрес из каждого источника. Дайте мне знать, если это поможет или я далеко от базы. Я все еще учусь!

Answer 4

Я не эксперт по SQL, но вот то, что, я думаю, вы пытаетесь описать.

Клиент, который является уникальным объектом, имеет текущий адрес и может иметь много других адресов, если это правильнода, вы должны разделить дополнительные адреса в их собственной таблице.

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

По отношению к деве и серединеимена - это те, которые требуются в соответствии с вашими бизнес-правилами, если они сохраняются, когда это необходимо.

Опять же, моя разработка SQL на самом деле только на уровне ученика, но, насколько я понимаю, именно так я и поступлю.

Надеюсь, что это поможет, и если кто-то может дать больше экспертной информациис этим.