Я только что понял, что моя база данных не соответствует 1NF. Нужно ли перестраивать таблицы?

Question

Я только что получил работу, и они попросили меня построить все запросы для их базы данных.Так я и сделал, сотни из них.Сейчас база данных заполняется отдельным отделом, но при рассмотрении работы моих коллег за столами я понимаю, что моя база данных не соответствует 1NF.Например, одна из наших таблиц имеет следующие поля:

Адрес 1, Адрес 2, Адрес 3 и т. Д. Вплоть до адреса 6

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

Каково ваше мнение?о чем ты думаешь?Как у тебя дела сегодня?

Answer 1

Прежде чем вы опередите себя и перепишите все это, спросите своего коллегу, почему они выбрали этот дизайн. Иногда выбор дизайна кажется странным, но это делается по определенной причине. Возможно, это то, как адреса поступают из источника, или то, как они передаются в другой системе. Не прыгайте с пистолета, просто начните все менять, если вы не уверены, почему они так сконструированы, потому что это не 1NF.

Answer 2

Есть «правильный» ответ и правильный ответ.

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

Правильный ответ: вы уже на 2 месяца отстали от срока.Если вы можете исправить это за кулисами, чтобы люди по-прежнему использовали одни и те же запросы и хранимые процедуры (т. Е. Вызывали их одинаково), то я подождал бы, пока вы не перейдете в производство, а затем вернусь, чтобы очиститьпозже это станет «улучшением».

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

Answer 3

1NF обычно неправильно понимают.

Если вы прочитаете о повторяющихся группах в статье в Википедии о 1NF , я пойму, как вы могли прийти к выводу, что ваша таблица с атрибутами Address_1, Address_2,..., Address_6 нарушает 1NF.

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

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

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

Прежде чем что-то менять, я согласен с @Fink, что было бы полезно узнать намерение оригинального дизайнера.Одной из возможных причин выбранной конструкции является упрощение написания ограничений в кодере SQL DDL.Например, бизнес-правило состояло в том, что каждый объект должен иметь ровно шесть значений адресов, что практически невозможно реализовать любым другим способом, кроме шести столбцов NOT NULL в одной строке (например, ограничение на уровне таблицы CHECK заманчиво, но естьпроблема в Access в том, что она проверяет ограничения на уровне строк, а не на уровне операторов и не имеет механизма для отсрочки ограничения).