Используете ли вы зависимости и нормальные формы для разработки схемы реляционной базы данных?

Учебники и курсы часто объясняют нормализацию примерами прогрессивной декомпозиции — начиная со схем, где зависимости не обеспечиваются должным образом с помощью ключей, а затем переходят к более совершенным проектам, которые удовлетворяют BCNF, 5NF и т. д. Это учебное упражнение используется для объяснения некоторых концепций и методов; это не план того, как должен быть выполнен реальный дизайн базы данных. Это похоже на практику длинного деления на уроках математики не потому, что этот метод широко используется, а потому, что важно знание фундаментальной арифметики.

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

Когда я создавал базы данных, я обычно начинал с хорошей модели ER. Мне нужно было это, чтобы проверить мое понимание предмета. После преобразования модели ER в реляционную модель результат обычно был в 3NF, часто в BCNF. Обычно достаточно хорош для работы OLTP. Для работы с OLAP я использовал звездообразную схему. Это было полно аномалий обновления, с которыми я справился, осторожно используя ETL. Просто мой взгляд.

Обычно сочетания глубокого понимания бизнеса (часто приобретаемого в результате тщательно разработанного концептуального моделирования) и не слишком большого опыта в практике проектирования будет достаточно, чтобы в большинстве случаев получить проекты 5NF «с самого начала». Таким образом, «процедура нормализации», обычно иллюстрируемая/предлагаемая в учебниках, на самом деле почти никогда не практикуется. Применение этой процедуры является своего рода подходом «снизу вверх», который кажется совершенно неестественным большинству практикующих дизайнеров, которые в значительной степени предпочитают «сверху вниз», начиная с концептуальных моделей, которые часто уже «разложены» точно так, как вы в конечном итоге получите. применение процедуры нормализации как метода.

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

Теория FD также является важным материалом, который должны знать разработчики СУБД. Например, реляционные СУБД должны иметь возможность делать то, что называется «ключевым выводом» для реляционных выражений (т. е. вычислять, каким ключам гарантируется результат, скажем, JOIN, учитывая, каковы ключи входных данных. Такой вывод был бы невозможен без теории ФД.)

Что касается «если вы понимаете, что такое ваши объекты и каковы их атрибуты, разве вы не начинаете с таблиц, уже находящихся в BCNF?» , это немного зависит от ваших сущностей концептуального уровня, которые были идентифицированы «правильно» (по некоторому значению этого последнего слова — то, что я имею в виду, так это то, что так же, как люди могут придумать плохой дизайн базы данных, они также могут прийти с плохими концептуальными моделями, и если вы используете такую ​​​​плохую модель в качестве основы для дизайна базы данных, вы можете догадаться, что получится).

reannb рассказывает о различных артефактах, которые могут предоставить информацию о FD: опыт предметной области, дизайн пользовательского интерфейса, ограничения FK, исходный код, запросы, общение с другими разработчиками. Другими словами, вы либо просто каким-то образом знаете FD (экспертов в предметной области, других разработчиков), либо вы смотрите на дистилляцию знаний от этих людей (пользовательский интерфейс, FK, код). Но откуда эксперты в предметной области получают FD? Если это не модель E/R — явная или внутренняя, интуитивная — тогда каков источник FD?

Эрвин Смаут говорит, в основном, GIGO, что, очевидно, верно. Но это все еще не говорит, откуда берутся FD, если не модель E/R.

Так что я до сих пор не понимаю: откуда берутся FD, если не модель E/R? Поясню: я не говорю, что теория нормализации бесполезна, я согласен с точкой зрения Эрвина Смаута по этому вопросу. Кроме того, я не спрашиваю, потому что я новичок (см. мой оригинальный пост). Мой вопрос связан с преподаванием дизайна схемы. Обсуждения теории нормализации кажутся весьма надуманными. Они начинают с очень плохо разработанной схемы и функциональных зависимостей, которые берутся... ну, они никогда не говорят, откуда берутся FD. Примените правила и вуаля, у нас есть схема BCNF. Мне кажется, что более правдоподобным, реалистичным и полезным подходом будет сказать:

• Разработка схемы начинается с модели E/R.

• Вот процедуры для создания набора таблиц и определений FK из модели E/R.

• Теперь обратите внимание, что ваша модель E/R фактически подразумевает эти функциональные зависимости.

• Затем перейдите к теории нормализации и покажите, как разложение BCNF (например) дает ту же схему из довольно плохих начальных точек.

• Если вы унаследовали плохую схему, разработка четкой модели E/R и функциональных зависимостей может помочь вам определить хорошую схему.

"Вы на самом деле используете теорию зависимостей и нормальные формы? Или просто флиртуете, как я?"

Я разрабатываю схемы баз данных более пятнадцати лет.

Тем не менее, я никогда не использовал теорию зависимостей (анализ функциональной зависимости - FDA). И при этом я не "крыл это".
И тем не менее, все мои проекты схем находятся в пятой нормальной форме. (5НФ)

Мой секрет в том, что я использую формальный метод, называемый «объектно-ролевое моделирование». Я использую бесплатный инструмент под названием NORMA для разработки формальной модели, из которой инструмент NORMA может автоматически генерировать логическую модель 5NF.

В процессе моделирования у меня открыто окно «реляционного представления», которое автоматически и мгновенно создает логическое представление 5NF моей модели объектной роли в ее «текущем состоянии».

Когда я доволен своим дизайном, я выбираю целевую СУБД (например, SQL Server), и через несколько щелчков мыши у меня есть SQL DDL, который я затем вырезаю и вставляю в панель «Новый запрос» в SQL Server Management Studio. Этот метод гораздо более эффективен, чем FDA или его использование.

Вы можете загрузить бесплатный инструмент NORMA отсюда. руководства находятся здесь.

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

Признание: я использовал FDA, будучи студентом, на нескольких университетских курсах, но этого было достаточно, чтобы отказаться от него на всю жизнь!