Разработка ИС торогового предприятия

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

Хотя  первичные ключи являются важной частью реляционной модели данных, в первых реляционных СУБД (System/R, DB2, Oracle и других) не была обеспечена явным образом их поддержка. Как правило, проектировщики базы данных сами следили за тем, чтобы у всех таблиц были первичные ключи, однако в самих СУБД не было возможности определить для таблицы первичный ключ. И только в СУБД DB2 Version 2, появившейся в апреле 1988 года, компания IBM реализовала поддержку первичных ключей. После этого подобная поддержка была добавлена в стандарт ANSI/ISO.[3, 7, 8, 12].

3. Индексы

Индексы – объекты базы данных, которые обеспечивают быстрый доступ к отдельным строкам в таблице. Индекс создается с целью повышения производительности операций запросов и сортировки данных таблицы. Индексы также используются для поддержания в таблицах некоторых типов ключевых ограничений; эти индексы часто создаются автоматически при определении ограничения.

Индекс  – независимый объект, логически отдельный от таблицы; создание или удаление индекса никак не воздействует на определение или данные индексированной таблицы. Он хранит высоко оптимизированные версии всех значений одного или больше столбцов таблицы. Когда значение запрашивается из индексированного столбца, процессор (ядро) базы данных использует индекс для быстрого нахождения требуемого значения. Индексы должны постоянно поддерживаться, чтобы отражать последние изменения индексированных столбцов таблицы. Процедуры обновления индекса при вставке, модификации или удалении значения в индексированный столбец автоматически выполняются процессором базы данных. Хотя эти операции не требуют никаких действий со стороны пользователя, они, однако, снижают эффективность некоторых операций манипулирования данными (кроме запросов на выборку). Однако уменьшение производительности, ассоциированное с поддержанием индекса, в большинстве случаев с лихвой компенсируется преимуществами повышения быстродействия доступа к данным, которое обеспечивает индекс. Индексы обеспечивают наибольшие выгоды для относительно статичных таблиц, по которым часто выполняются запросы.

Создать индексы, как и ключи, можно по одному или нескольким полям. Составные  индексы позволяют при отборе данных группировать записи, в которых первые поля могут иметь одинаковые значения. Индексировать поля требуется для выполнения частых поисков, сортировок или объединений с полями из других таблиц в запросах. Ключевые поля таблицы индексируются автоматически. Нельзя индексировать поля с типом данных поле МЕМО, гиперссылка или объект OLE. Для остальных полей индексирование используется, если поле имеет текстовый, числовой, денежный тип или тип даты/времени и требуется осуществлять поиск и сортировку значений в поле. Если предполагается, что будет часто выполняться сортировка или поиск одновременно по двум и более полям, можно создать составной индекс. Например, если для одного и того же запроса часто устанавливается критерий для полей Имя и Фамилия, то для этих двух полей имеет смысл создать составной индекс. При сортировке таблицы по составному индексу сначала осуществляется сортировка по первому полю, определенному для данного индекса. Если в первом поле содержатся записи с повторяющимися значениями, то сортировка осуществляется по второму полю и т. д.[3, 7, 8, 12].

4. Отношения предок/потомок

Одним из отличий реляционной модели от первых моделей представления данных было то, что в ней отсутствовали  явные указатели, используемые для  реализации отношений предок/потомок  в иерархической модели данных. Однако вполне очевидно, что отношения предок/потомок существуют и в реляционных базах данных. Например, в нашей базе данных каждой оценке на экзамене соответствует дисциплина, поэтому ясно, что между строками таблицы DISCIPLS и таблицы EXAMINE существует отношение.

Как следует  из рис.6, это никоим образом не приводит к потере информации. На рисунке  изображено несколько строк из таблиц DISCIPLS и EXAMINE. Обратим внимание на то, что в столбце NUMBER таблицы EXAMINE содержится идентификатор студента. Доменом этого столбца (множеством значений, которые могут в нем храниться) является множество идентификаторов студентов, содержащихся в столбце NUMBER таблицы EXAMINE.

Отношение предок/потомок, существующее между  дисциплинами и оценками за экзамен, в реляционной модели не потеряно; просто оно реализовано в виде одинаковых значений данных, хранящихся в двух таблицах, а не в виде явного указателя. Все отношения, существующие между таблицами реляционной базы данных, реализуются в таком виде.

5. Внешние ключи

Столбец одной таблицы, значения в котором совпадают со значениями столбца, являющегося первичным ключом другой таблицы, называется внешним ключом. На рис. 7 столбец NUM_DIS представляет собой внешний ключ для таблицы DISCIPLS. Значения, содержащиеся в этом столбце, представляют собой идентификаторы изучаемых дисциплин. Эти значения соответствуют значениям в столбце NDIS, который является первичным ключом таблицы DISCIPLS. Совокупно первичный и внешний ключи создают между таблицами, в которых они содержатся, такое же отношение предок/потомок, как и в иерархической базе данных.

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

Если  таблица связана с несколькими  другими таблицами, она может  иметь несколько внешних ключей. На рис. 7. показаны три внешних ключа таблицы ORDERS из учебной базы данных:

столбец REP является внешним ключом для таблицы SALESREPS и 
связывает каждый заказ со служащим, принявшим его;

столбец CUST является внешним ключом для таблицы CUSTOMES и 
связывает каждый заказ с клиентом, разместившим его;

столбцы MRF и PRODUCT совокупно представляют собой  составной внешний ключ для таблицы PRODUCTS, который связывает каждый заказ с заказанным товаром.  

Реляционная модель данных обладает всеми возможностями сетевой модели по части выражения сложных отношений.

Внешние ключи являются неотъемлемой частью реляционной модели, поскольку реализуют отношения между таблицами базы данных. К несчастью, как и в случае с первичными ключами, поддержка внешних ключей отсутствовала в первых реляционных СУБД. Она была введена в системе DB2 Version 2 и теперь имеется во всех коммерческих СУБД.

6. Реляционная алгебра

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

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

• объединения таблиц;
• пересечения таблиц;
• взятия разности таблиц;
• прямого произведения таблиц.

Специальные реляционные операции включают:

• ограничение таблицы;
• проекцию таблицы;
• соединение таблиц;
• деление таблиц.

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

Ограничения целостности.

Существуют  три подхода, каждый из которых поддерживает целостность по ссылкам. Первый подход заключается в том, что запрещается производить удаление записи, на которую существуют ссылки (т.е. сначала нужно либо удалить ссылающиеся записи, либо соответствующим образом изменить значения их внешнего ключа). При втором подходе при удалении записи, на которую имеются ссылки, во всех ссылающихся записях значение внешнего ключа автоматически становится неопределенным. Наконец, третий подход (каскадное удаление) состоит в том, что при удалении записи из таблицы, на которую ведет ссылка, из ссылающейся таблицы автоматически удаляются все ссылающиеся записи.[7, 12, 13].

7. Нормализация  базы данных

Процесс трансформации данных в реляционную  форму называется нормализацией[9]. Говоря проще, нормализация - это удаление избыточных данных из каждой таблицы в базе данных. У нормализации двойная цель - удалить лишние копии данных и обеспечить максимальную гибкость как в структурах таблиц, так и в интерфейсных приложениях на случай возможных будущих изменений в базах данных.

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

Нормализация  обычно подразделяется на пять форм или  стадий— от первой нормальной формы по пятую нормальную форму. То есть просто пять установок реляционного критерия, который либо обнаруживает таблицу, либо нет. Каждая последующая стадия строится на предыдущей. Формально существует пять форм, но на практике, как правило, используется только первые три. Последние две считаются слишком специальными, чтобы их применять к обычным проектам баз данных.[7, 8, 10].

1. Первая  нормальная форма

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

 Поле  считается неделимым, если оно  содержит только один элемент данных. Например, поле Address, которое содержит не только название улицы, но также и города,  почтовый код, не является неделимым. Чтобы соответствовать первой нормальной форме, такие столбцы должны быть разбиты на несколько полей.[7, 8, 10].

Повторяющаяся группа — это поле, которое повторяется внутри определения записи с целью хранения нескольких значений для атрибута.

2. Вторая  нормальная форма

Для того чтобы привести таблицу ко второй нормальной форме, нужно, чтобы все не ключевые поля полностью зависели от первичного ключа таблицы и от каждого поля в первичном ключе, если последний состоит из нескольких полей. Это значит, что каждое не ключевое поле должно уникально определяться первичным ключом и полями, его составляющими.[7, 8, 10].

3. Третья  нормальная форма

Для того чтобы таблица была приведена  к третьей нормальной форме, нужно, чтобы все не ключевые поля полностью  зависели от первичного ключа таблицы  и не зависели друг от друга. Таким  образом, к квалификации второй нормальной формы добавляется требование независимости каждого не ключевого поля таблицы от других не ключевых полей.[7, 8, 10].

4. Четвертая нормальная форма

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

Конечно же, поскольку два столбца находятся во взаимоотношении многие-ко-многим, то они уже не являются независимыми, и тем самым уже нарушают третью нормальную форму. По этой причине четвертая нормальная форма рассматривается больше теоретически, т.к. частично она перекрывается третьей нормальной формой.[7, 8, 10].