Нормализация базы данных

Question

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

Спасибо

Answer 1

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

Простое руководство по пяти нормальным формам в теории реляционных баз данных это классическая ссылка для нормальных форм. Эта статья в простых терминах определяет сущность каждой нормальной формы. и его значение в отношении дизайна таблицы базы данных. Это очень хороший справочник "touch-stone".

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

• Является ли Адрес простым фактом (например, сгустком текста) или составным фактом (например, состоит из нескольких атрибутов: адресная строка, название города, почтовый индекс и т. д.)
• Каковы другие "факты", относящиеся к "Проживанию", "Аэропорт" и "Железнодорожный вокзал"?
• Какие наборы «фактов» однозначно и минимально идентифицируют «Аэропорт», «Проживание» и «Железнодорожный вокзал» (эти факты обычно называют ключом или ключом-кандидатом)?
• Какие функциональные зависимости существуют среди фактов адреса и фактов составление каждого ключа отношений?

Все это говорит о том, что ответ на ваш вопрос не так прост, как можно надеяться!

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

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

Answer 2

Могу ли я иметь адресные столбцы в каждой таблице или таблицу адресов, на которую ссылаются другие таблицы?

Могут ли аэропорты, вокзалы и жилые помещения иметь разные адреса?

Одна таблица ADDRESS минимизирует работу, необходимую для работы с адресами - набор, RR, почтовый индекс, штат / провинция ...

Есть ли такая вещь, как чрезмерная нормализация?

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

Answer 3

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

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

Посмотрите все примеры / примеры баз данных, которые вы также можете. Они дадут вам хорошее представление о том, когда вы должны разбивать данные, а когда нет.

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

Answer 4

Лично я бы пошел за другим столом.

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

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

Answer 5

Будут ли в каждой таблице столбцы адресов или таблицы адресов, на которые ссылаются другие таблицы?

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

Есть ли такая вещь, как чрезмерная нормализация?

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

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

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

С опытом вы узнаете, где лучше всего провести черту для систем, которые вы пишете.

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

Answer 6

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

Answer 7

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

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

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

Смежный вопрос: Нормализует ли имя человека слишком далеко

Answer 8

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

Теперь стандартизация адресов не тривиальна.Есть услуги CASS, которые делают это для вас (для адресов США), которые были сертифицированы USPS.На самом деле я работаю на SmartyStreets , где это наш опыт, поэтому я бы посоветовал вам начать поиск там.Вы можете выполнить пакетную обработку или использовать API для стандартизации адресов по мере их получения.

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

Answer 9

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

Answer 10

Когда вы говорите «адрес», я предполагаю, что вы имеете в виду полный адрес, такой как улица, город, штат / провинция, может быть страна и почтовый индекс. Это 4 или 5 полей, может быть, больше, если вы укажете «адресная строка 1» и «адресная строка 2», опека и т. Д. Это должно быть определенно в отдельной таблице с «адресным» для связи со станцией и т. д. таблицы. В противном случае вы создаете 3 отдельные копии одного и того же набора определений полей. Это плохие новости, потому что они прилагают дополнительные усилия, чтобы поддерживать их согласованность. Например, если изначально вы имеете дело только с адресами США (я американец, поэтому я предполагаю, что США), но позже вы обнаружите, что вам также нужно разрешить канадцам. Вам нужно будет увеличить размер поля почтового индекса и добавить код страны. Если есть общая таблица, то вам нужно сделать это только один раз. Если нет, то вы должны сделать это три раза. И вполне вероятно, что «три раза» - это не просто изменение схемы базы данных, а изменение каждого места в ваших программах, обрабатывающих адрес.

Одним из преимуществ нормализации является минимизация влияния изменений.