Я из лагеря нормализации.
Вот несколько советов, с которых можно начать:
Начните с процесса назначения произвольного уникального идентификатора каждому «человеку».Назовите это PersonId или что-то в этом роде.Этот идентификатор называется суррогатным ключом.Единственная цель суррогатного ключа - гарантировать отношения 1: 1 между ним и реальным человеком в реальном мире.Используйте суррогатный ключ при сопоставлении значения какого-либо другого атрибута с «человеком» в вашей базе данных.
По мере разработки макета базы данных вы можете найти суррогатные ключи, необходимые (или, по крайней мере, полезные) для некоторых других атрибутов, например:ну.
Посмотрите на каждый атрибут, которым вы хотите управлять.Задайте следующий вопрос: есть ли у данного человека только одно значение для этого атрибута?
Например, у каждого человека есть ровно одна «Дата рождения».Но как они могут иметь «хобби»?Вероятно, ноль для многих.Однозначные атрибуты (например, дата рождения, рост, вес и т. Д.) Являются кандидатами для перехода в общую таблицу с ключом PersonId.На данный момент количество атрибутов в каждой таблице не должно вызывать беспокойства.
Многозначные атрибуты, такие как хобби, нуждаются в несколько ином подходе.Возможно, вы захотите создать отдельные таблицы для каждого многозначного атрибута.Используя хобби в качестве примера, вы можете создать следующую таблицу PersonHobby(PersonId, Hobby).Строка в этой таблице может выглядеть примерно так: (123, "Stamp Collecting").Таким образом, вы можете записать столько хобби, сколько требуется для каждого человека, по одному в строке.Сделайте то же самое для «Интереса», «Умения» и т. Д.
Если существует много многозначных атрибутов, в которых комбинация PersonId + Hobby больше ничего не определяет (т. Е. У вас нет ничего интересногочтобы записать, как этот человек делает это «Хобби», «Интерес» или «Умение»), вы можете объединить их в таблицу «Атрибут-Значение», имеющую структуру типа PersonAV(PersonId, AttributeName, Value).Здесь строка может выглядеть так: (123, "Hobby", "Stamp Collecting").
Если вы пойдете по этому пути, также будет хорошей идеей заменить AttributeName в таблице PersonAV суррогатным ключом и создать другую таблицу, чтобы связать этот ключ с его описанием.Что-то вроде: Attribute(AttributeId, AttributeName).Строка в этой таблице будет выглядеть примерно как (1, "Hobby"), а соответствующая строка PersonAV может быть (123, 1, "Stamp Collecting").Обычно это делается для того, чтобы, если вам когда-нибудь понадобится узнать, какие AttributeNames действительны в вашей базе данных / приложении, у вас есть место, чтобы найти их.Подумайте, как вы можете проверить, является ли «Интерес» действительным значением для AttributeName или нет - если вы не записали какое-либо лицо, имеющее этот AttributeName, то в вашей базе данных нет записи этого AttributeName - как это сделать?ты знаешь, должен ли он существовать или нет?Посмотрите в таблице Attribute
Некоторые атрибуты могут иметь несколько взаимосвязей, что также повлияет на нормализацию таблиц.Я не видел ни одной из этих зависимостей в вашем примере, поэтому рассмотрим следующее: Предположим, у нас есть склад, полный деталей, PartId определяет его WeightClass, StockCount и ShipCost.Это предполагает что-то вроде таблицы: Part(PartId, WeightClass, StockCount, ShipCost).Однако если существует связь между неключевыми атрибутами, то они должны быть учтены.Например, предположим, что WeightClass непосредственно определяет ShipCost.Это означает, что одного WeightClass достаточно для определения ShipCost, а ShipCost следует вычленить из таблицы Part.
Нормализация - довольно тонкое искусство.Вам нужно определить функциональные зависимости, которые существуют между всеми атрибутами в вашей модели данных, чтобы сделать это правильно.Простое определение функциональных зависимостей требует серьезных размышлений и размышлений, но крайне важно для правильного проектирования базы данных.
Я призываю вас уделить немного времени изучению нормализации, прежде чем приступать к созданиюбаза данных.Несколько дней, проведенных здесь, более чем окупят себя в будущем.Попробуйте выполнить поиск в Google / Википедии на предмет «Функциональная зависимость», «Нормализация» и «Дизайн базы данных».Читайте, учитесь, учитесь, а затем постройте это правильно.
Предложения, которые я сделал в отношении нормализации дизайна вашей базы данных, являются лишь указанием на то, в каком направлении вам, возможно, придется следовать.Не имея четкого понимания всех данных, которыми вы пытаетесь управлять в своем приложении, любой совет, данный здесь, следует воспринимать с «долей соли».