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

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

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

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

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

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

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

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

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

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

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

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

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

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

Связанный с этим вопрос: Не заходит ли нормализация имени человека слишком далеко ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вы используете Oracle 9i, вы могли бы хранить адресные объекты в ваших таблицах. Это устранило бы (обоснованные) опасения по поводу форматов адресов.

Я согласен с С.Лоттом и хотел бы добавить:

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

2. В зависимости от того, что вы хотите смоделировать с помощью ваших трех сущностей, и от того, как вы их идентифицируете, вы можете придумать очень разные концептуальные модели данных, все из которых могут быть представлены в смеси нормальных форм - или вообще ненормализованы. (например, 1 таблица для всех данных с дескрипторами и пустыми пустотами повсюду ...). Представьте, что вы нормализуете свои три объекта до окончательной нормальной формы. Теперь я могу представить новое требование, или вариант использования, или расширение, которое придает описательному атрибуту, который был до сих пор, так или иначе упорядоченный, или ссылающийся, или структурированный характер, если вы посмотрите на его содержимое. Затем модель должна представлять это поведение, и то, что раньше было атрибутом, возможно, лучше будет отдельной сущностью, на которую ссылаются другие сущности.

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

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

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