Дизайн DB: 1-я нормальная форма и повторяющиеся группы

Я думаю (и меня учили) 1NF как «все строки должны быть одинаковой длины», а не «без повторяющихся групп». С этой точки зрения вам будет немного легче принять решение из следующего:

В проекте 1 ВСЕГДА присутствуют оба теста? Если так, то это действительно не повторяющаяся группа. Всегда ли присутствуют все средние в схеме 2? Может ли быть больше (или меньше) в данной строке?

В схеме 4 всегда ли присутствуют оба этих значения? Если так, то ничего страшного. В противном случае следует использовать конструкцию 5.

Вот правило повторяющихся групп - что функционально зависит?

Если значение статистики функционально зависит от SN, теста и имени статистики, то у вас есть три ключевых элемента и одно значение элемент. (SN, Тест, Статистика -> Значение)

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

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

Для ваших примеров, проследите за дизайном хранилища данных, чтобы найти более прагматичный тест:

Можете ли вы нарезать кубиками по другому ключу?

Думайте о своем статистическом факте как о точке, окруженной тремя измерениями: (SN, тест, статистика). Это действительно так? (Что касается сводных данных, они часто нечеткие.)

Вместо этого давайте посмотрим на подробные данные, которые нам следовало хранить: SN, Test, Score. Ясно, что на пересечении этих двух измерений есть два измерения (SN, Test) и одна мера (оценка). Мы можем получить любое количество статистических данных из этих подробных данных, используя любое измерение (SN или Test)

. В примере с батареей вы, вероятно, действительно захотите создать ее как базу данных EAV вместо более типичного реляционного база данных. Ваши измерения (AvergaeCurrent и BatteryCapacity) дают вам веские причины использовать дизайн базы данных Entity-Attribute-Value .

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

Если вы уверены, что «тест» (всегда) будет иметь только максимальное, минимальное и среднее значение -> используйте вариант 2. Однако, если возможно, что в будущем появится новая «статистика», лучше использовать схему 3.

Ответ на:

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

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

Я предлагаю перемещать повторяющиеся группы только в отдельные таблицы, если они имеют переменную длину. Если у вас когда-либо будут только Phone1, Phone2 и Phone3, нет необходимости разделять их. В другом случае, если количество повторов варьируется, лучше оформить отдельную таблицу.

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

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

Вариант 1

SN     Test1_Max   Test1_Min    Test1_Mean  Test2_Max   Test2_Min    Test2_Mean
2093      23          2            15         54          -24           45  

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

Вариант 2

SN     Test      Max    Min    Mean     
2093    1        23     2      15       
2093    2        54     -24     45      

Это полезно, если SN 2093 может иметь N тестов в своем профиле. Точно так же, если количество тестов составляет, скажем, 10 метров, тогда этот дизайн также лучше, чем иметь 30 столбцов. Каждый запрос и сравнение будут довольно тяжелыми. Это также полезно, если вашему приложению требуются запросы, по которым он хочет получить наиболее эффективный тест для учащегося 2093 или, при желании, провести некоторую аналитику и составить отчет о результатах тестов. Он более гибкий, но немного медленнее, чем предыдущий. Я предпочитаю это, потому что у меня есть подозрение, что вы, вероятно, заинтересуетесь статистикой тестов, а студенты могут иметь более двух тестов каждый.

Вариант 3

SN     Test    Statistic    Value
2093    1        Max          23
2093    1        Min          2
2093    1        Mean         15       
2093    2        Max          54
2093    2        Min         -24
2093    2        Mean         45  

Это полезно, если ваши запросы больше всего интересуют значения. Например, если вас интересует, сколько значений больше 80, это будет быстро. В вашем сценарии это не имеет смысла. В конечном итоге вы будете делать слишком много самостоятельных JOIN. Чтение будет медленным! Однако запись, вероятно, будет быстрее, потому что вы можете быстро ОБНОВИТЬ максимальную оценку для SN 2093 и Тест 2 (при условии, что столбец статистики является перечислением, а не строкой, поскольку сравнение строк может быть

Вариант 4

SN      AverageCurrent (mA)    BatteryCapacity (mA)  
2093          200                    540  

Вариант 5

SN      mA_Measuremnt       Value
2093    AverageCurrent      200 
2093    BatteryCapacity     540 

Применяются те же аргументы. Это действительно зависит от того, собираетесь ли вы оптимизировать чтение или запись? Для веб-приложений, например, если вам это сойдет с рук, я предпочитаю Design 1. Например, я обычно знаю, что у пользователя будет не более трех телефонных номеров, поэтому я сделаю их полем в столбце пользователя и избегайте СОЕДИНЕНИЙ. Чтение происходит быстро, даже если для записи потребуется установить в некоторых полях значение NULL.

В конечном итоге вы будете делать слишком много самостоятельных JOIN. Чтение будет медленным! Однако запись, вероятно, будет быстрее, потому что вы можете быстро ОБНОВИТЬ максимальную оценку для SN 2093 и Тест 2 (при условии, что столбец статистики является перечислением, а не строкой, поскольку сравнение строк может быть

Вариант 4

SN      AverageCurrent (mA)    BatteryCapacity (mA)  
2093          200                    540  

Вариант 5

SN      mA_Measuremnt       Value
2093    AverageCurrent      200 
2093    BatteryCapacity     540 

Применяются те же аргументы. Это действительно зависит от того, собираетесь ли вы оптимизировать чтение или запись? Для веб-приложений, например, если вам это сойдет с рук, я предпочитаю Design 1. Например, я обычно знаю, что у пользователя будет не более трех телефонных номеров, поэтому я сделаю их полем в столбце пользователя и избегайте СОЕДИНЕНИЙ. Чтение происходит быстро, даже если для записи потребуется установить в некоторых полях значение NULL.

В конечном итоге вы будете делать слишком много самостоятельных JOIN. Чтение будет медленным! Однако запись, вероятно, будет быстрее, потому что вы можете быстро ОБНОВИТЬ максимальную оценку для SN 2093 и Тест 2 (при условии, что столбец статистики является перечислением, а не строкой, поскольку сравнение строк может быть

Вариант 4

SN      AverageCurrent (mA)    BatteryCapacity (mA)  
2093          200                    540  

Вариант 5

SN      mA_Measuremnt       Value
2093    AverageCurrent      200 
2093    BatteryCapacity     540 

Применяются те же аргументы. Это действительно зависит от того, собираетесь ли вы оптимизировать чтение или запись? Для веб-приложений, например, если вам это сойдет с рук, я предпочитаю Design 1. Например, я обычно знаю, что у пользователя будет не более трех телефонных номеров, поэтому я сделаю их полем в столбце пользователя и избегайте СОЕДИНЕНИЙ. Чтение происходит быстро, даже если для записи потребуется установить в некоторых полях значение NULL.

запись, вероятно, будет быстрее, потому что вы можете быстро ОБНОВИТЬ максимальную оценку для SN 2093 и Тест 2 (при условии, что столбец статистики является перечислением, а не строкой, поскольку сравнение строк может быть дорогостоящим) .

Вариант 4

SN      AverageCurrent (mA)    BatteryCapacity (mA)  
2093          200                    540  

Вариант 5

SN      mA_Measuremnt       Value
2093    AverageCurrent      200 
2093    BatteryCapacity     540 

Применяются те же аргументы. Это действительно зависит от того, собираетесь ли вы оптимизировать чтение или запись? Для веб-приложений, например, если вам это сойдет с рук, я предпочитаю Design 1. Например, я обычно знаю, что у пользователя будет не более трех телефонных номеров, поэтому я сделаю их полем в столбце пользователя и избегайте СОЕДИНЕНИЙ. Чтение происходит быстро, даже если для записи потребуется установить в некоторых полях значение NULL.

запись, вероятно, будет быстрее, потому что вы можете быстро ОБНОВИТЬ максимальную оценку для SN 2093 и Тест 2 (при условии, что столбец статистики является перечислением, а не строкой, поскольку сравнение строк может быть дорогостоящим) .

Вариант 4

SN      AverageCurrent (mA)    BatteryCapacity (mA)  
2093          200                    540  

Вариант 5

SN      mA_Measuremnt       Value
2093    AverageCurrent      200 
2093    BatteryCapacity     540 

Применяются те же аргументы. Это действительно зависит от того, собираетесь ли вы оптимизировать чтение или запись? Для веб-приложений, например, если вам это сойдет с рук, я предпочитаю Design 1. Например, я обычно знаю, что у пользователя будет не более трех телефонных номеров, поэтому я сделаю их полем в столбце пользователя и избегайте СОЕДИНЕНИЙ. Чтение происходит быстро, даже если для записи потребуется установить в некоторых полях значение NULL.

Это действительно зависит от того, собираетесь ли вы оптимизировать чтение или запись? Для веб-приложений, например, если вам это сойдет с рук, я предпочитаю Design 1. Например, я обычно знаю, что у пользователя будет не более трех телефонных номеров, поэтому я сделаю их полем в столбце пользователя и избегайте СОЕДИНЕНИЙ. Чтение происходит быстро, даже если для записи потребуется установить в некоторых полях значение NULL.

Это действительно зависит от того, собираетесь ли вы оптимизировать чтение или запись? Для веб-приложений, например, если вам это сойдет с рук, я предпочитаю Design 1. Например, я обычно знаю, что у пользователя будет не более трех телефонных номеров, поэтому я сделаю их полем в столбце пользователя и избегайте СОЕДИНЕНИЙ. Чтение происходит быстро, даже если для записи потребуется установить в некоторых полях значение NULL.

Дизайн 1 фактически находится в 1NF, если у вас есть PK на CustID. Это может быть в 3NF, если никакие данные не зависят от чего-либо, кроме PK, например Phone1 не повторяется для другого CustID.

Вы не можете выбрать модель без бизнес-кейсов, которые вы пытаетесь решить. Таким образом, Дизайн 1 может быть вполне допустимой логической моделью.