Разработка базы данных в среде Oracle

В идеально спроектированной реляционной базе данных отношение "один к одному" (1:1) не нужно. Если каждой строке одной таблицы соответствует одна строка другой таблицы, то это обычно свидетельствует о том, что обе таблицы нужно объединить в единое целое. Исключение из правила— необычный случай, когда число столбцов таблицы превышает предел, установленный в СУБД. Обычно в СУБД этот предел равен 3000, так что маловероятно, чтобы кому-то пришло в голову его превысить. Есть СУБД, где предельное число столбцов гораздо меньше, например 250, но даже этого числа вполне достаточно для большинства приложений.

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

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

Выход из положения заключается в декомпозиции, т.е. разбивке отношения M:N на два отношения 1:N. Это означает, что ссылки между двумя таблицами будут вынесены в третью таблицу, содержащую всего два столбца. В них будут сопоставляться первичные ключи основных таблиц.

Реляционная модель предъявляет к таблице определенные требования:

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

Помимо собственно таблиц и их свойств, реляционная модель имеет еще и собственные операции. Эти операции позволяют выполнять некоторые действия над подмножествами столбцов и/или строк, объединять (сливать) таблицы и выполнять другие операции над множествами. Чрезвычайно важно отметить, что все эти операции используют таблицы в качестве исходных данных; результатом операций также являются таблицы. В настоящее время стандартным языком для работы СУБД, является SQL, средства которого позволяют выполнять все эти операции.

1.3. Целостность данных в реляцеонной базе данных

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

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

Потенциальный ключ – суперключ, который не содержит подмножества, также являющегося суперключем данного отношения.

Потенциальный ключ K для данной таблицы R обладает двумя свойствами.

• Уникальность. В каждой строке таблицы R значение ключа K единственным образом идентифицирует эту строку.
• Неприводимость. Никакое допустимое подмножество ключа K не обладает свойством уникальности.

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

Первичный ключ – потенциальный ключ, который выбран для уникальной идентификации сток внутри таблицы.

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

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

Пустое значение – указывает, что значение столбца в настоящий момент неизвестно или неприемлемо для этой строки.

Пустое значение (которое условно обозначается как NULL) следует рассматривать как логическую величину «неизвестно». NULL не следует понимать как нулевое численное значение или заполненную пробелами текстовую строку. Нули и пробелы представляют собой некоторые значения, тогда как ключевое слово NULL обозначает отсутствие какого-либо значения.

Внешний ключ — это столбец или подмножество столбцов одной таблицы, который может служить в качестве первичного ключа для другой таблицы. Говорят также, что внешний ключ одной таблицы является ссылкой на первичный ключ другой таблицы.

Два фундаментальных правила целостности: правило целостности объектов (entity integrity rule) и правило ссылочной целостности (referential integrity rule).

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

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

Таким образом, система управления реляционной БД — это СУБД, которая удовлетворяет сформулированным выше фундаментальным требованиям реляционной модели. Критерием могут служить двенадцать правил полноты реляционных систем, сформулированных Коддом, за которыми так и закрепилось наименование правил Кодда.

Двенадцать правил Кодда определяют требования к реляционным СУБД.

1. Явное представление данных. Информация должна быть представлена в виде данных, хранящихся в ячейках.
2. Гарантированный доступ к данным. К каждому элементу данных должен быть обеспечен доступ с использованием комбинации имени таблицы, первичного ключа строки и имени столбца.
3. Полная обработка неопределенных значений. Неопределенные значения Null, отличные от любого определенного значения, должны поддерживаться для всех типов данных при выполнении любых операций. Например, если Null рассматривается как число 0 для неопределенного элемента числового типа и как пробел для неопределенного элемента символьного типа, это будет противоречить сформулированному выше правилу. Null должен рассматриваться только в качестве пропущенного, неопределенного элемента данных и никак иначе. Если же необходимо, чтобы незаданные элементы имели некоторое заранее предопределенное значение, потребитель должен иметь возможность задавать значения по умолчанию (default).
4. Доступ к описанию БД в терминах реляционной модели. Словарь данных активной БД должен сохраняться в форме таблицы, и СУБД должна поддерживать доступ к нему при помощи стандартных языковых средств доступа к таблицам. Нарушением этого правила является сохранение словаря данных в виде файлов операционной системы.
5. Полнота подмножества языка. Язык манипулирования данными и язык определения данных должны поддерживать все операции доступа к данным и быть единственным средством такого доступа, кроме, возможно, операций низшего уровня (см. правило 12). Нарушением этого правила является возможность вмешательства в содержимое файла, хранящего таблицу, средствами, не являющимися операторами языка SQL.
6. Возможность обновления представлений. Все представления, подлежащие обновлению, должны быть доступны для этого. Противоречит этому правилу ситуация, когда система позволяет объединить три таблицы и сформировать соответствующее представление, но не позволяет это представление обновить.
7. Наличие высокоуровневого языка манипулирования данными. Операции вставки, обновления и удаления должны применяться к таблице в целом. В настоящее время это правило удовлетворяется практически всеми СУБД.
8. Физическая независимость данных. Прикладные программы не должны зависеть от используемых способов хранения данных на носителях и методов обращения к ним. Если файл, в котором хранятся данные таблицы, перемещается на другой диск или переименовывается, это никак не должно сказываться на приложениях.
9. Логическая независимость данных. Прикладные программы не должны зависеть от логических ограничений. Если таблица разделяется на две, то представление должно обеспечивать слияние обеих частей с тем, чтобы это никак не сказывалось на приложениях.
10. Независимость контроля целостности. Все необходимое для поддержания целостности данных должно храниться в словаре данных. Ограничения на первичные ключи, внешние ключи, пределы допустимого диапазона значений данных, переключатели и тому подобные данные должны храниться в словаре данных.
11. Дистрибутивная независимость. Реляционная БД должна быть переносима и способна к распространению. Это правило представляет собой расширение правила 8 в том смысле, что БД должна быть переносимой не только в пределах системы (локально переносимой), но и по сети, объединяющей множество систем (удаленно переносимой).
12. Согласование языковых уровней. Если реляционная СУБД допускает низкоуровневый язык доступа (элемент доступа — запись), последний не должен совершать операций, противоречащих требованиям правил безопасности и поддержания целостности данных, которые соблюдаются языком более высокого уровня. Средства, обеспечивающие такие низкоуровневые операции, как формирование резервных копий или загрузки, не должны игнорировать существующие в системе правила опознания пользователей и их привилегий доступа, блокировок и ограничений. Однако зачастую разработчики СУБД пренебрегают этим правилом во имя повышения скорости.

СУБД, удовлетворяющая всем фундаментальным требованиям (т.е. соответствующая обеим частям определения, обладающая шестью перечисленными свойствами, поддерживающая реляционные операции и не противоречащая двум правилам целостности), а также всем двенадцати правилам Кодда, может квалифицироваться как система управления реляционными БД. Все это Кодд суммировал в правиле 0: для того чтобы систему можно было квалифицировать как реляционную СУБД, она должна использовать исключительно реляционные функции для управления базой данных.

1.4 Интерпретация реляционных операций

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

Специальные реляционные операции включают: ограничение отношения; проекцию отношения; соединение отношений; деление отношений.

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

Общая интерпретация реляционных операций

Почти все операции предложенного выше набора обладают очевидной и простой интерпретацией.

• При выполнении операции объединения двух отношений производится отношение, включающее все кортежи, входящие хотя бы в одно из отношений-операндов.
• Операция пересечения двух отношений производит отношение, включающее все кортежи, входящие в оба отношения-операнда.
• Отношение, являющееся разностью двух отношений включает все кортежи, входящие в отношение - первый операнд, такие, что ни один из них не входит в отношение, являющееся вторым операндом.
• При выполнении прямого произведения двух отношений производится отношение, кортежи которого являются конкатенацией (сцеплением) кортежей первого и второго операндов.
• Результатом ограничения отношения по некоторому условию является отношение, включающее кортежи отношения-операнда, удовлетворяющее этому условию.
• При выполнении проекции отношения на заданный набор его атрибутов производится отношение, кортежи которого производятся путем взятия соответствующих значений из кортежей отношения-операнда.
• При соединении двух отношений по некоторому условию образуется результирующее отношение, кортежи которого являются конкатенацией кортежей первого и второго отношений и удовлетворяют этому условию.
• У операции реляционного деления два операнда - бинарное и унарное отношения. Результирующее отношение состоит из одноатрибутных кортежей, включающих значения первого атрибута кортежей первого операнда таких, что множество значений второго атрибута (при фиксированном значении первого атрибута) совпадает со множеством значений второго операнда.
• Операция переименования производит отношение, тело которого совпадает с телом операнда, но имена атрибутов изменены.
• Операция присваивания позволяет сохранить результат вычисления реляционного выражения в существующем отношении БД.

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

1.5 Нормальные формы

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

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

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

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

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