Является ли эта форма нормализации базы данных Mysql правильной?

Question

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

Оттуда я собирался составить таблицу с различной информацией. Тогда у меня будет промежуточная таблица, чтобы объединить всю информацию и сделать запись. Насколько я могу судить, почти каждый столбец будет многозначным, кроме номера единицы. Таким образом, я вижу необходимость полной нормализации:

Table building_number 
--------------------- 
building_number_id int primary key auto index not null 
buildind_namber tinyint 

Table city 
-------------------- 
city_id building_number_id int primary key auto index not null 
city_name varchar(30) 

Table state 
-------------------- 
state_id building_number_id int primary key auto index not null 
state_name varchar(30) 

Table zip 
--------------------- 
zip_id building_number_id int primary key auto index not null 
zip_name varchar(30) 

Table building_name 
--------------------- 
building_name_id int primary key auto index not null 
building_name varchar(50) 

Table owner 
--------------------- 
owner_id int primary key auto index not null 
owner_name varchar(30) 


Table info 
---------------------- 
info_id int primary key auto index not null 
rent tinyint 
condition varchar(10) 
comment varchar(1000) 

Intermediate table 
-------------------------- 
building_number_id int 
street_id int 
city_id int 
state_id int 
building_name_id 
owner_id 
info_id 
(all these keys are foreign keys referencing their respected tables/primary keys) 

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

Я буду использовать индексирование двигателя и b-дерева. Я буду индексировать каждый столбец, кроме комментария, поскольку я буду выполнять эти динамические поиски ввода (например, google).

Я делаю это для себя как любителя. Из-за этого я предпочитаю делать это вручную с нуля, а не использовать некоторые фреймворки или плагины.

Для чего я делаю, правильно ли эта конструкция базы данных и нормализация?

Answer 1

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

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

С другой стороны, есть вещи, которые не являются сущностями, а вместо них дескрипторами сущностей.

Примеры дескрипторов: высота, вес, номер двери и цена.

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

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

В вашем случае вам нужен объект «address» с рядом полей, которые его описывают. Такие вещи, как «номер здания», должны быть полем ввода свободной формы. Все строчные номера - «Building A», «82 1/2», «107B», «3.7», «4/9» и «44-290». Вы должны просто принять строку.

Аналогичным образом, названия улиц вряд ли могут быть квалифицированы. Является ли «улица зеленого пути» такой же, как «Green Way St.», или "Greenway St."? Это имеет значение? Наверное, нет, поскольку это всего лишь дескриптор. У вас нет способа проверить их, а их объединение практически невозможно, слишком много массирования требуется, чтобы заставить его работать в больших масштабах.

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

То, что вы, вероятно, следует сделать, это создать таблицу, как "адреса" с полями: address1, address2, address3, address4, address5, city, region, country, postal_code. С этим вы можете покрыть все, что они бросят на вас. Посмотрите на данные, которые Google Maps возвращает для примера.

Вы, кажется, намекаете на какую-то структуру one-to-many в своем вопросе, где адрес может иметь несколько имен или номеров зданий. Без какого-либо индикатора последовательности вы не сможете узнать, какая из этих связанных записей является первой. Это значительно усложняет ситуацию.

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