Оглавление:
Видео: Базы данных. Таблицы в SQL и отношения в реляционных БД: атрибуты, строки, столбцы, записи и кортежи 2025
После того, как база данных SQL находится в третьей нормальной форме, вы устранили большинство, но не все, возможности аномалий модификации. Нормальные формы, выходящие за третье, определяются для сквоша этих немногих оставшихся ошибок.
Нормальная форма доменного ключа (DK / NF)
Нормальные формы Boyce-Codd (BCNF), четвертая нормальная форма (4NF) и пятая нормальная форма (5NF) являются примерами таких форм. Каждая форма исключает возможную аномалию модификации, но не гарантирует предотвращение всех возможных аномалий модификации. Тем не менее, нормальная форма доменного ключа обеспечивает такую гарантию.
Отношение находится в нормальной форме домена-домена (DK / NF) , если каждое ограничение на отношение является логическим следствием определения ключей и доменов. Ограничение в этом определении - это любое правило, достаточно точное, чтобы вы могли оценить, действительно ли оно истинно. A ключ является уникальным идентификатором строки в таблице. A домен - это набор допустимых значений атрибута.
Посмотрите на эту базу данных, которая находится в 1NF, чтобы узнать, что вы должны сделать, чтобы поместить эту базу данных в DK / NF.
Таблица: ПРОДАЖИ (Customer_ID, Product, Price)
Ключ: Customer_ID
Ограничения:
-
Customer_ID определяет Продукт
-
Продукт определяет цену
-
Клиент_ID должен быть целым числом > 1000
Чтобы принудительно использовать Constraint 3 (что Customer_ID должен быть целым числом более 1000), вы можете просто определить домен для Customer_ID для включения этого ограничения. Это делает ограничение логическим следствием домена столбца CustomerID. Продукт зависит от Customer_ID, а Customer_ID - это ключ, поэтому у вас нет проблем с Constraint 1, что является логическим следствием определения ключа.
Ограничение 2 - это проблема . Цена зависит от (является логическим следствием) продукта, а Продукт не является ключом. Решение состоит в том, чтобы разделить таблицу SALES на две таблицы. Одна таблица использует Client_ID как ключ, а другая использует Продукт как ключ. База данных, помимо того, что она находится в 3NF, также находится в DK / NF.
Создайте свои базы данных, чтобы они были в DK / NF, если это возможно. Если вы можете это сделать, принудительное ограничение ключей и доменов приведет к тому, что все ограничения будут выполнены, а аномалии модификации невозможны. Если структура базы данных предназначена для того, чтобы вы не помещали ее в DK / NF, вам необходимо создать ограничения в прикладной программе, использующей базу данных. Сама база данных не гарантирует, что ограничения будут выполнены.
Аномальная форма
Как и в жизни, поэтому в базах данных: иногда бывает ненормально окупается.Вы можете увлечься нормализацией и зайти слишком далеко. Вы можете разбить базу данных на столько таблиц, что все это становится громоздким и неэффективным. Производительность может резко упасть. Часто оптимальная структура для вашей базы данных несколько денормализуется.
Фактически, практические базы данных (действительно большие, во всяком случае) практически никогда не нормализуются вплоть до DK / NF. Однако вы хотите нормализовать базы данных, которые вы разрабатываете, насколько это возможно, чтобы устранить возможность повреждения данных, что является результатом аномалий модификации.
После того, как вы нормализируете базу данных, насколько это возможно, сделайте несколько попыток поиска в качестве сухого хода. Если производительность не является удовлетворительной, проверьте свой дизайн, чтобы убедиться, что выборочная денормализация повысит производительность, не жертвуя целостностью. Тщательно добавляя избыточность в стратегических местах и денормализуя достаточно , , вы можете прийти к базе данных, которая эффективна и безопасна от аномалий.
