Кириллов В.В., Громов Г.Ю. - Введение в реляционные базы данных. Литература для вузов isbn 9785941577705 в книге рассматриваются основные понятия баз данных и систем управления ими
 Скачать 11.62 Mb.
|
|
Глава 11 Нормализация 11.1. О нормализации, функциональных и многозначных зависимостях Нормализация — это разбиение таблицы на две или более, обладающих луч- шими свойствами при включении, изменении и удалении данных. Оконча- тельная цель нормализации сводится к получению такого проекта базы дан- ных, в котором каждый факт появляется лишь в одном месте, т. е. исключена избыточность информации. Это делается не столько с целью эко- номии памяти, сколько для исключения возможной противоречивости хра- нимых данных. Как указывалось в разд. 3.1, каждая таблица в реляционной базе данных удовлетворяет условию, в соответствии с которым в позиции на пересечении каждой строки и столбца таблицы всегда находится единственное атомарное значение, и никогда не может быть множества таких значений. Любая табли- ца, удовлетворяющая этому условию, называется нормализованной (см. таб- лицы с рис. 10.1 и 10.2). Фактически, ненормализованные таблицы, т. е. таб- лицы, содержащие повторяющиеся группы (см. табл. 10.1), даже не допускаются в реляционной БД. Всякая нормализованная таблица автоматически считается таблицей в первой нормальной форме, сокращенно 1НФ. Таким образом, строго говоря, "норма- лизованная" и "находящаяся в 1НФ" означают одно и то же. Однако на прак- тике термин "нормализованная" часто используется в более узком смысле — "полностью нормализованная", который означает, что в проекте не наруша- ются никакие принципы нормализации. Теперь в дополнение к 1НФ можно определить дальнейшие уровни нормали- зации — вторую нормальную форму (2НФ), третью нормальную форму (3НФ) и т. д. По существу, таблица находится в 2НФ, если она находится Часть IV. Основы проектирования баз данных 212 в 1НФ и удовлетворяет, кроме того, некоторому дополнительному условию, суть которого будет рассмотрена далее. Таблица находится в 3НФ, если она находится во 2НФ и, помимо этого, удовлетворяет еще другому дополни- тельному условию и т. д. Таким образом, каждая нормальная форма является в некотором смысле бо- лее ограниченной, но и более желательной, чем предшествующая. Это свя- зано с тем, что "(N+1)-я нормальная форма" не обладает некоторыми непри- влекательными особенностями, свойственными "N-й нормальной форме". Общий смысл дополнительного условия, налагаемого на (N+1)-ю нормаль- ную форму по отношению к N-й нормальной форме, состоит в исключении этих непривлекательных особенностей. В разд. 10.3 мы выявляли непривле- кательные особенности табл. 10.2 и для их исключения выполняли "интуи- тивную нормализацию". Теория нормализации основывается на наличии той или иной зависимости между полями таблицы. Определены два вида таких зависимостей: функцио- нальные и многозначные. Функциональная зависимость. Поле Б таблицы функционально зависит от поля А той же таблицы в том и только в том случае, когда в любой заданный момент времени для каждого из различных значений поля А обязательно су- ществует только одно из различных значений поля Б. Отметим, что здесь до- пускается, что поля А и Б могут быть составными. Например, в таблице Блюда (см. рис. 10.2) поля Блюдо и Вид функционально зависят от ключа БЛ , а в таблице Поставщики поле Страна функционально за- висит от составного ключа ( Поставщик, Город ). Однако последняя зависи- мость не является функционально полной, так как Страна функционально зависит и от части ключа — поля Город Полная функциональная зависимость. Поле Б находится в полной функцио- нальной зависимости от составного поля А, если оно функционально зависит от А и не зависит функционально от любого подмножества поля А. Многозначная зависимость. Поле А многозначно определяет поле Б той же таблицы, если для каждого значения поля А существует хорошо определен- ное множество соответствующих значений Б. Для примера рассмотрим табл. 11.1. В ней есть многозначная зависимость " Дисциплина-Преподаватель ": дисциплина (в примере Информатика) может читаться несколькими преподавателями (в примере Шипиловым и Голова- невским). Есть и другая многозначная зависимость " Дисциплина-Учебник ": при изучении Информатики используются учебники "Паскаль для всех" и "Язык Си". При этом Преподаватель и Учебник не связны функциональной Глава 11. Нормализация 213 зависимостью, что приводит к появлению избыточности (для добавления еще одного учебника придется ввести в таблицу две новых строки). Дело улуч- шается при замене этой таблицы на две: (" Дисциплина-Преподаватель" и " Дисциплина-Учебник" ). Таблица 11.1. Обучение Дисциплина Преподаватель Учебник Информатика Шипилов П. А. Форсайт Р. Паскаль для всех Информатика Шипилов П. А. Уэйт М. и др. Язык Си Информатика Голованевский Г. Л. Форсайт Р. Паскаль для всех Информатика Голованевский Г. Л. Уэйт М. и др. Язык Си 11.2. Нормальные формы В разд. 11.1 было дано определение первой нормальной формы (1НФ). При- ведем здесь более строгое ее определение, а также определения других нор- мальных форм. Таблица находится в первой нормальной форме (1НФ) тогда и только тогда, когда ни одна из ее строк не содержит в любом своем поле более одного зна- чения и ни одно из ее ключевых полей не пусто. Из таблиц, рассмотренных в главе 10, не удовлетворяет этим требованиям (т. е. не находится в 1НФ) только табл. 10.1. Таблица находится во второй нормальной форме (2НФ), если она удовлетво- ряет определению 1НФ и все ее поля, не входящие в первичный ключ, связа- ны полной функциональной зависимостью с первичным ключом. Кроме табл. 10.1 не удовлетворяет этим требованиям только табл. 10.2. Как обосновано далее (пример 11.1), она имеет составной первичный ключ (Блюдо, Продукт, Поставщик, Город, Цена) и содержит множество неключевых полей ( Вид , Основа , Выход и т. д.), зави- сящих лишь от той или иной части первичного ключа. Так поля Вид и Основа зависят только от поля Блюдо , Статус — от поля Поставщик и т. п. Следова- Часть IV. Основы проектирования баз данных 214 тельно, эти поля не связаны с первичным ключом полной функциональной зависимостью. Ко второй нормальной форме приведены почти все таблицы с рис. 10.1 кроме таблицы Поставщики , в которой Страна зависит только от поля Город , кото- рый является частью первичного ключа (Поставщик, Город) . Последнее об- стоятельство приводит к проблемам при: включении данных (пока не появится поставщик из Вильнюса, нельзя за- фиксировать, что это город Литвы); удалении данных (исключение поставщика может привести к потере ин- формации о местонахождении города); обновлении данных (при изменении названия страны приходится про- сматривать множество строк, чтобы исключить получение противоречи- вого результата). Разбивая эту таблицу на две таблицы Поставщики и Города , можно исключить указанные аномалии. Что же касается таблиц с рис. 10.2, то ввод в них отсутствующих в предмет- ной области цифровых первичных и внешних ключей формально затрудняет процедуру выявления функциональных связей между этими ключами и ос- тальными полями. Действительно, легко установить связь между атрибутом Блюдо и Вид (блюда): Харчо — Суп, Лобио — Закуска и т. п., но нет прямой зависимости между полями БЛ и Вид (блюда), если не помнить, что значение БЛ соответствует номеру блюда. Для упрощения нормализации подобных таблиц целесообразно использовать следующую рекомендацию. При проведении нормализации таблиц, в кото- рые введены цифровые (или другие) заменители составных и (или) текстовых первичных и внешних ключей, следует хотя бы мысленно подменять их на исходные ключи, а после окончания нормализации снова восстанавливать. При использовании этой рекомендации таблицы с рис. 10.2 временно пре- вращаются в таблицы с рис. 10.1, а после выполнения нормализации и вос- становления полей БЛ , ПР и ПС — в нормализованные таблицы. Таблица находится в третьей нормальной форме (3НФ), если она удовле- творяет определению 2НФ и ни одно из ее неключевых полей не зависит функционально от любого другого неключевого поля. После разделения таблицы Поставщики с рис. 10.1 на две части все таблицы этого проекта удовлетворяют определению 2НФ, а так как в них нет не- ключевых полей, функционально зависящих друг от друга, то все они на- ходятся в 3НФ. Глава 11. Нормализация 215 Как ни странно, этого нельзя сказать об аналогичных таблицах с рис. 10.2. Если забыть рекомендацию о подмене на время нормализации ключей БЛ , ПР и ПС на Блюдо , Продукт и (Поставщик, Город) , то среди этих таблиц появятся две, не удовлетворяющие определению 3НФ. Действительно, так как после ввода первичных ключей БЛ и ПР поля Блюдо и Продукт стали неключевы- ми — появились не существовавшие ранее функциональные зависимости между неключевыми полями: Блюдо → Вид и Поставщик → Страна Следовательно, для приведения таблиц Блюда и Продукты с рис. 10.2 к 3НФ их надо разбить на: Блюда(БЛ, Блюдо) Вид_блюда(БЛ, Вид) Продукты(ПР, Продукт) хотя интуиция подсказывает, что это лишнее разбиение, совсем не улуч- шающее проект базы данных. Столкнувшись с подобными несуразностями, которые могут возникать не только из-за введения кодированных первичных ключей, теоретики реляци- онных систем Кодд и Бойс обосновали и предложили более строгое опреде- ление для 3НФ, которое учитывает, что в таблице может быть несколько возможных ключей. Таблица находится в нормальной форме Бойса—Кодда (НФБК), если и толь- ко если любая функциональная зависимость между его полями сводится к полной функциональной зависимости от возможного ключа. В соответствие с этой формулировкой таблицы Блюда и Продукты с рис. 10.2, имеющие по паре возможных ключей ( БЛ и Блюдо ) и ( ПР и Продукт ) находятся в НФБК или в 3НФ. В следующих нормальных формах (4НФ и 5НФ) учитываются не только функциональные, но и многозначные зависимости между полями таблицы. Для их описания познакомимся с понятием полной декомпозиции таблицы. Полной декомпозицией таблицы называют такую совокупность произвольно- го числа ее проекций, соединение которых полностью совпадает с содержи- мым таблицы. Например, естественным соединением (см. разд. 3.3) таблиц с рис. 10.1 мож- но образовать исходную таблицу, приведенную на рис. 10.2. Следовательно, таблицы с рис. 10.1 и 10.2 являются полными декомпозициями табл. 10.2 (универсального отношения COOK ). Теперь можно дать определения высших нормальных форм. И сначала будет дано определение для последней из предложенных — 5НФ. Часть IV. Основы проектирования баз данных 216 Таблица находится в пятой нормальной форме (5НФ) тогда и только тогда, когда в каждой ее полной декомпозиции все проекции содержат возможный ключ. Таблица, не имеющая ни одной полной декомпозиции, также находится в 5НФ. Четвертая нормальная форма (4НФ) является частным случаем 5НФ, когда полная декомпозиция должна быть соединением ровно двух проекций. Весь- ма не просто подобрать реальную таблицу, которая находилась бы в 4НФ, но не была бы в 5НФ. 11.3. Процедура нормализации Как уже говорилось, нормализация — это разбиение таблицы на несколько, обладающих лучшими свойствами при обновлении, включении и удалении данных. Теперь можно дать и другое определение: нормализация — это про- цесс последовательной замены таблицы ее полными декомпозициями до тех пор, пока все они не будут находиться в 5НФ. На практике же достаточно привести таблицы к НФБК и с большой гарантией считать, что они находятся в 5НФ. Разумеется, этот факт нуждается в проверке, однако пока не сущест- вует эффективного алгоритма такой проверки. Поэтому остановимся лишь на процедуре приведения таблиц к НФБК. Эта процедура основывается на том, что единственными функциональными зависимостями в любой таблице должны быть зависимости вида K → F, где K — первичный ключ, а F — некоторое другое поле. Заметим, что это следу- ет из определения первичного ключа таблицы, в соответствии с которым K → F всегда имеет место для всех полей данной таблицы. "Один факт в одном месте" говорит о том, что не имеют силы никакие другие функциональные зависимости. Цель нормализации состоит именно в том, чтобы избавиться от всех этих "других" функциональных зависимостей, т. е. таких, которые име- ют иной вид, чем K → F. Если воспользоваться рекомендацией из разд. 11.2 и подменить на время нормализации коды первичных (внешних) ключей на исходные ключи, то, по существу, следует рассмотреть лишь два случая: 1. Таблица имеет составной первичный ключ вида, скажем, (К1, К2), и включает также поле F, которое функционально зависит от части этого ключа, например, от К2, но не от полного ключа. В этом случае рекомен- дуется сформировать другую таблицу, содержащую К2 и F (первичный ключ — К2), и удалить F из первоначальной таблицы: Заменить T(K1, K2, F), первичный ключ (К1, К2), ФЗ К2 → F на T1(K1, K2), первичный ключ (К1, К2), и T2(K2, F), первичный ключ К2. Глава 11. Нормализация 217 2. Таблица имеет первичный (возможный) ключ К, не являющееся возмож- ным ключом поле F1, которое, конечно, функционально зависит от К, и другое неключевое поле F2, которое функционально зависит от F1. Реше- ние здесь, по существу, то же самое, что и прежде — формируется другая таблица, содержащая F1 и F2, с первичным ключом F1, и F2 удаляется из первоначальной таблицы: Заменить T(K, F1, F2), первичный ключ К, ФЗ F1 → F2 на T1(K, F1), первичный ключ К, и T2(F1, F2), первичный ключ F1. Для любой заданной таблицы, повторяя применение двух рассмотренных правил, почти во всех практических ситуациях можно получить, в конечном счете, множество таблиц, которые находятся в "окончательной" нормальной форме и, таким образом, не содержат каких-либо функциональных зависимо- стей вида, отличного от K → F. Для выполнения этих операций необходимо первоначально иметь в качестве входных данных какие-либо "большие" таблицы (например, универсальные отношения). Но нормализация ничего не говорит о том, как получить эти большие таблицы. Далее будет рассмотрена процедура получения таких ис- ходных таблиц, а здесь приведем примеры нормализации. Пример 11.1. Применим рассмотренные правила для полной нормализации универсального отношения COOK (табл. 10.2). 1. Определение первичного ключа таблицы. Предположим, что каждое блюдо имеет уникальное название, относится к единственному виду и приготавливается по единственному рецепту, т. е. название блюда однозначно определяет его вид и рецепт. Предположим также, что название организации поставщика уникально для того города, в котором он расположен, и названия городов уникальны для каждой из стран, т. е. название поставщика и город однозначно определяют этого по- ставщика, а город — страну его нахождения. Наконец, предположим, что поставщик может осуществлять в один и тот же день только одну постав- ку каждого продукта, т. е. название продукта, название организации по- ставщика, город и дата поставки однозначно определяют вес и цену по- ставленного продукта. Тогда в качестве первичного ключа отношения COOK можно использовать следующий набор атрибутов: Блюдо , Продукт , Поставщик , Город , Цена 2. Выявление полей, функционально зависящих от части составного ключа. Поля Вид и Основа функционально зависят только от поля Блюдо , т. е. Блюдо K → Вид Блюдо K → Основа Часть IV. Основы проектирования баз данных 218 Аналогичным образом можно получить зависимости: (Блюдо, Продукт) K → Вес Город K → Страна (Поставщик, Город) K → Цена 3. Формирование новых таблиц. Полученные функциональные зависимости определяют состав таблиц, ко- торые можно сформировать из данных универсального отношения: Блюда (Блюдо, Вид) Состав (Блюдо, Продукт, Вес (г)) Города (Город, Страна) Поставки (Поставщик, Город, К_во, Цена) 4. Корректировка исходной таблицы. После выделения из состава универсального отношения указанных ранее таблиц, там остались лишь сведения о поставщиках, для хранения кото- рых целесообразно создать таблицу Поставщики (Поставщик, Город) т. е. использовать часть исходного первичного ключа, так как остальные его части уже ничего не определяют. Таким образом, процедура последовательной нормализации позволила полу- чить проект, лучший, чем приведен на рис. 10.1. Пример 11.2. Для улучшения проекта, приведенного на рис. 10.2, нужно оп- ределить первичные ключи таблиц и выявить, нет ли в таблицах полей, зави- сящих лишь от части этих ключей. Такое поле есть только в одной таблице. Это поле Страна в таблице Поставщики . Выделяя его вместе с ключом Город в таблицу Страны , получим нормализованный проект. 11.4. Построение даталогической (табличной) модели Рассмотренный в разд. 10.4 процесс построения концептуальной модели ба- зы данных должен быть продолжен построением ее табличной модели. Для этого необходимо: 1. Представить каждый стержень (независимую сущность) таблицей базы данных (базовой таблицей) и специфицировать первичный ключ этой ба- зовой таблицы. Глава 11. Нормализация 219 2. Представить каждую ассоциацию (связь вида "многие-ко-многим" или "многие-ко-многим-ко-многим" и т. д. между сущностями) как базовую таблицу. Использовать в этой таблице внешние ключи для идентификации участников ассоциации и специфицировать ограничения, связанные с ка- ждым из этих внешних ключей. 3. Представить каждую характеристику как базовую таблицу с внешним ключом, идентифицирующим сущность, описываемую этой характери- стикой. Специфицировать ограничения на внешний ключ этой таблицы и ее первичный ключ — по всей вероятности, комбинации этого внешнего ключа и свойства, которое гарантирует "уникальность в рамках описы- ваемой сущности". 4. Представить каждое свойство (атрибут) как поле в базовой таблице, пред- ставляющей сущность, которая непосредственно описывается этим свой- ством. 5. Для того чтобы исключить в проекте непреднамеренные нарушения каких-либо принципов нормализации, необходимо выполнить процедуру нормализации (см. разд. 11.3). 6. Если в процессе нормализации было произведено разделение каких-либо таблиц, то следует модифицировать инфологическую модель базы данных и повторить перечисленные шаги. 7. Указать ограничения целостности проектируемой базы данных и дать (если это необходимо) краткое описание полученных таблиц и их полей. Для примера приведем описания таблиц Блюда и Состав (листинги 11.1 и 11.2). Листинг 11.1. Блюда ("русифицированный" листинг) СОЗДАТЬ ТАБЛИЦУ Блюда ( БЛ Число(2), Блюдо Текст(60), Вид Текст(7), Основа Текст(6), Выход Число(4,1) ); КОММЕНТАРИЙ К ТАБЛИЦЕ Блюда - 'Перечень блюд, известных шеф-повару'; КОММЕНТАРИЙ К СТОЛБЦУ Блюда.БЛ - 'Код блюда'; КОММЕНТАРИЙ К СТОЛБЦУ Блюда.Блюдо - 'Название блюда'; КОММЕНТАРИЙ К СТОЛБЦУ Блюда.Вид - 'Вид блюда'; КОММЕНТАРИЙ К СТОЛБЦУ Блюда.Основа - 'Основной продукт в блюде'; КОММЕНТАРИЙ К СТОЛБЦУ Блюда.Выход - 'Масса порции готового блюда'; Часть IV. Основы проектирования баз данных 220 ИЗМЕНИТЬ ТАБЛИЦУ Блюда - ДОБАВИТЬ ОГРАНИЧЕНИЕ "Повтор кода блюда !" ПЕРВИЧНЫЙ КЛЮЧ (БЛ); ИЗМЕНИТЬ ТАБЛИЦУ Блюда - ДОБАВИТЬ ОГРАНИЧЕНИЕ "Такое блюдо уже есть !" УНИКАЛЬНЫЙ КЛЮЧ (БЛ, Блюдо); ИЗМЕНИТЬ ТАБЛИЦУ Блюда - ДОБАВИТЬ ОГРАНИЧЕНИЕ "Только Закуска,Суп,Горячее,Десерт,Напиток" ПРОВЕРЯТЬ (Вид ИЗ ('Закуска', 'Суп', 'Горячее', 'Десерт', 'Напиток')); ИЗМЕНИТЬ ТАБЛИЦУ Блюда - ДОБАВИТЬ ОГРАНИЧЕНИЕ "Только Кофе,Крупа,Молоко,Мясо,Овощи,Рыба,Фрукты,Яйца !" ПРОВЕРЯТЬ (Основа ИЗ ('Кофе', 'Крупа', 'Молоко', 'Мясо', 'Овощи', 'Рыба', 'Фрукты', 'Яйца')); Листинг 11.2. Состав ("русифицированный" листинг) СОЗДАТЬ ТАБЛИЦУ Состав ( БЛ Число(2), ПР Число(2), Вес Число(3) ); КОММЕНТАРИЙ К ТАБЛИЦЕ Состав - 'Состав блюд'; КОММЕНТАРИЙ К СТОЛБЦУ БЛ - 'Код блюда'; КОММЕНТАРИЙ К СТОЛБЦУ ПР - 'Код продукта'; КОММЕНТАРИЙ К СТОЛБЦУ Вес - 'Масса продукта в блюде'; ИЗМЕНИТЬ ТАБЛИЦУ Состав - ДОБАВИТЬ ОГРАНИЧЕНИЕ "Состав не уникален !" ПЕРВИЧНЫЙ КЛЮЧ (БЛ, ПР); ИЗМЕНИТЬ ТАБЛИЦУ Состав - ДОБАВИТЬ ОГРАНИЧЕНИЕ "Такого блюда нет !" ВНЕШНИЙ КЛЮЧ (БЛ) СВЯЗЬ Блюда (БЛ); ИЗМЕНИТЬ ТАБЛИЦУ Состав - ДОБАВИТЬ ОГРАНИЧЕНИЕ "Такого продукта нет !" ВНЕШНИЙ КЛЮЧ (ПР) СВЯЗЬ Продукты (ПР); ИЗМЕНИТЬ ТАБЛИЦУ Состав - ДОБАВИТЬ ОГРАНИЧЕНИЕ "Вес должен быть между 1 и 500 !" ПРОВЕРЯТЬ (Вес МЕЖДУ 1 И 500); Естественно, что приведенные нестандартные листинги 11.1 и 11.2 сможет "понять" только гипотетическая СУБД. Понятным любой существующей СУБД может быть листинг, написанный с помощью предложений определения Глава 11. Нормализация 221 данных (Data Definition Language, DDL) языка SQL (см. часть V). Поэтому перепишем приведенные ранее листинги на язык SQL — листинги 11.3 и 11.4. Листинг 11.3. Блюда (листинг на языке SQL) CREATE TABLE Блюда ( БЛ NUMBER(2), Блюдо VARCHAR2(60), Вид VARCHAR2(7), Основа VARCHAR2(6), Выход NUMBER(4,1), ); COMMENT ON TABLE Блюда IS 'Перечень блюд, известных шеф-повару'; COMMENT ON COLUMN Блюда.БЛ IS 'Код блюда'; COMMENT ON COLUMN Блюда.Блюдо IS 'Название блюда'; COMMENT ON COLUMN Блюда.Вид IS 'Вид блюда'; COMMENT ON COLUMN Блюда.Основа IS 'Основной продукт в блюде'; COMMENT ON COLUMN Блюда.Выход IS 'Масса порции готового блюда'; ALTER TABLE Блюда ADD CONSTRAINT "Повтор кода блюда !" PRIMARY KEY (БЛ); ALTER TABLE Блюда ADD CONSTRAINT "Такое блюдо уже есть !" UNIQUE (БЛ, Блюдо); ALTER TABLE Блюда ADD CONSTRAINT "Только Закуска,Суп,Горячее,Десерт,Напиток" CHECK (Вид IN ('Закуска', 'Суп', 'Горячее', 'Десерт', 'Напиток')); ALTER TABLE Блюда ADD CONSTRAINT "Только Кофе,Крупа,Молоко,Мясо,Овощи,Рыба,Фрукты,Яйца !" CHECK (Основа IN ('Кофе', 'Крупа', 'Молоко', 'Мясо', 'Овощи', 'Рыба', 'Фрукты', 'Яйца')); Листинг 11.4. Состав (листинг на языке SQ L) CREATE TABLE СОСТАВ ( БЛ NUMBER(2), ПР NUMBER(2), Вес NUMBER(3) ); Часть IV. Основы проектирования баз данных 222 COMMENT ON TABLE Состав IS 'Состав блюд'; COMMENT ON COLUMN Состав.БЛ IS 'Код блюда'; COMMENT ON COLUMN Состав.ПР IS 'Код продукта'; COMMENT ON COLUMN Состав.Вес IS 'Масса продукта в блюде'; ALTER TABLE Состав ADD CONSTRAINT "Состав не уникален !" PRIMARY KEY (БЛ, ПР); ALTER TABLE Состав ADD CONSTRAINT "Такого блюда нет !" FOREIGN KEY (БЛ) REFERENCES Блюда (БЛ); ALTER TABLE Состав ADD CONSTRAINT "Такого продукта нет !" FOREIGN KEY (ПР) REFERENCES Продукты (ПР); ALTER TABLE Состав ADD CONSTRAINT "Вес должен быть между 1 и 500 !" CHECK (Вес BETWEEN 1 AND 500); 11.5. Различные советы и рекомендации Векторы. Представляйте векторы по столбцам, а не по строкам. Например, диаграмму продаж товаров x, y, ... за последние годы лучше представить в виде: ТОВАР МЕСЯЦ КОЛ-ВО -–––– ––––––– –––––– x ЯНВАРЬ 100 x ФЕВРАЛЬ 50 x ДЕКАБРЬ 360 y ЯНВАРЬ 75 y ФЕВРАЛЬ 144 y ДЕКАБРЬ 35 а не так, как показано далее: ТОВАР КОЛ-ВО КОЛ-ВО КОЛ-ВО ЯНВАРЬ ФЕВРАЛЬ ... ДЕКАБРЬ ––––– ––––––– ––––––– ––––––– x 100 50 ... 360 y 75 144 ... 35 Глава 11. Нормализация 223 Одна из причин такой рекомендации заключается в том, что при этом значи- тельно проще записываются обобщенные (параметризованные) запросы. Рас- смотрите, например, как выглядит сравнение сведений из диаграммы продаж товара i в месяце с номером m со сведениями для товара j в месяце с номером n, где i, j, m и n — параметры. Неопределенные значения. Будьте очень внимательны с неопределенными ( NULL ) значениями. В поведении неопределенных значений проявляется мно- го произвола и противоречивости. В разных СУБД при выполнении различ- ных операций (сравнение, объединение, сортировка, группирование и др.) два неопределенных значения могут быть или не быть равными друг другу. Они могут по-разному влиять на результат выполнения операций по опреде- лению средних значений и нахождения количества значений. Для исключе- ния ошибок в ряде СУБД существует возможность замены NULL -значения ну- лем при выполнении расчетов, объявление всех NULL -значений равными друг другу и т. п. |