Лекция 12

Реляционная модель данных.

Нормализация. Нормальные формы.

Технология отображение концептуальной модели базы данных на реляционную модель данных

1. Основные понятия реляционной модели данных

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

1.1. Структурный компонент реляционной модели

С точки зрения структуры данных реляционная модель является удобной и наиболее привычной формой представления данных в виде таблицы. Понятию «таблица» соответствует понятие «отношение» (relation). Отсюда и произошло название модели – реляционная. Т.е., применительно к базам данных понятия «реляционная БД» и «табличная БД» по существу являются синонимами. В отличие от иерархической и сетевой модели, такой способ представления

1) понятен пользователю-непрограммисту;

2) позволяет легко изменять схему – присоединять новые элементы данных и записи без изменения соответствующих подсхем;

3) обеспечивает необходимую гибкость при обработке непредвиденных запросов.

К тому же любая сетевая или иерархическая схема может быть представлена двумерными отношениями.

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

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

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

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

Остальные ключи, которые можно также использовать в качестве первичных, называются потенциальными или альтернативными ключами.

Сформулируем правила назначения первичных ключей сущностей:

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

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

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

4). Значения первичного ключа не должны подвергаться частым модификациям. Идеально, если бизнес-логика предметной области такова, что эти значения вообще не предполагается изменять.

5). Правила модификации первичного ключа должны контролироваться внутренней бизнес-логикой предметной области, а не решениями, которые принимаются над ней. Например, в базе данных, разрабатываемой для нужд деканата, для сущности СТУДЕНТ не стоит выбирать в качестве первичного ключа серию и номер паспорта студента. Хотя эти данные в принципе и обладают свойствами обяза тельности и уникальности, но их изменение может быть инициировано студен ом, а не администрацией факультета.

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

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

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

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

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

12.1.2. Управляющий компонент реляционной модели

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

12.1.3. Целостность данных (слайд 5 )

Целостность на уровне доменов

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

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

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

Целостность на уровне отношений

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

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

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

NULL -значение – это некий указатель на то, что значение неизвестно. Проблема использования NULL -значения в теории реляционных баз данных окончательно не решена. Практически все реализации современных реляционных СУБД позволяют использовать NULL -значения, несмотря на их недостаточную теоретическую обоснованность.

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

Следует отметить, что большинство СУБД вполне позволяют создавать таблицы и без первичных ключей. Однако нарушение правила целостности отношений на практике сразу дает о себе знать. Например, для СУБД MS SQL-сервер станет невозможным доступ к данным по технологии OLE DB Provider .

Целостность внешних ключей (целостность на уровне БД)

Различные объекты предметной области, информация о которых хранится в базе данных, всегда взаимосвязаны. Наиболее типичный способ подобной связи между отношениями описывается ограничением внешнего ключа (FK , Foreign Key ).

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

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

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

Поскольку внешние ключи фактически служат ссылками на кортежи в другом (или в том же самом) отношении, то эти ссылки не должны указывать на несуществующие объекты.

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

12.1.4. Правила Кодда

В целом концепция реляционной модели определяется следующими двенадцатью правилами Кодда (слайд 6 ):

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

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

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

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

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

6. Правило обновления представлений. Все представления, которые теоретически можно обновить, должны быть доступны для обновления.

7. Правило добавления, обновления и удаления. Возможность работать с отношением как с одним операндом должна существовать не только при чтении данных, но и при добавлении, обновлении и удалении данных.

8. Правило независимости физических данных. Прикладные программы и утилиты для работы с данными должны на логическом уровне оставаться нетронутыми при любых изменениях способов хранения данных или методов доступа к ним.

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

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

11. Правило независимости распространения. Реляционная СУБД не должна зависеть от потребностей конкретного клиента.

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

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

Правило 3 требует, чтобы отсутствующие данные можно было представить с помощью недействительных значений (NULL ).

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

Правило 5 требует, чтобы СУБД использовала язык реляционной базы данных, например SQL . Такой язык должен поддерживать все основные функции СУБД – создание базы данных, чтение и ввод данных, реализацию защиты базы данных и т.д.

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

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

Правила 8 и 9 означают отделение пользователя и прикладной программы от низкоуровневой реализации базы данных. Они утверждают, что конкретные способы реализации хранения или доступа, используемые в СУБД, и даже изменения структуры таблиц базы данных не должны влиять на возможность пользователя работать с данными.

Правило 10 гласит, что язык базы данных должен поддерживать ограничительные условия, налагаемые на вводимые данные и действия, которые могут быть выполнены над данными.

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

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

12.2. Нормализация.

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

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

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

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

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

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

12.2.1. Функциональные зависимости

В основе процесса нормализации лежит концепция функциональной зависимости. Функциональная зависимость описывает связь между атрибутами отношения: если в отношении R , содержащем атрибуты A и B , атрибут B функционально зависит от атрибута A , то каждое отдельное значение атрибута A связано только с одним значением атрибута B (причем в качестве A и B могут выступать группы атрибутов). Атрибут или группа атрибутов A называются при этом детерминантом функциональной зависимости (слайд 8 ).

Таким образом, при наличии функциональной зависимости A →B кортежи (строки), имеющие одинаковое значение атрибута A , совпадают и по значению атрибута B . Однако обратное не верно: одно и то же значение атрибута B может соответствовать разным значениям атрибута A . Например, из функциональной зависимости Сотрудник→Должность следует, что везде, где будет указываться сотрудник «Еремеев В.К.», ему будет соответствовать должность «Профессор», но должность «Профессор» могут иметь и другие сотрудники.

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

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

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

В качестве примера рассмотрим фрагмент таблицы «Прием экзаменов (зачетов)». Таблица отражает связь дисциплины и формы отчетности с фамилией преподавателя. В этой таблице существует многозначная зависимость «Дисциплина - Преподаватель»: дисциплину «Математический анализ» ведут несколько преподавателей (Раков И. И., Рыбин К. К., Карпов К. Ю.) и, соответственно, все они могут участвовать в приеме экзаменов (зачетов). Другая многозначная зависимость – «Дисциплина – Форма отчетности»: по одной и той же дисциплине может проводиться и экзамен, и зачет. При этом Форма отчетности и Преподаватель не связны функциональной зависимостью, что приводит к появлению избыточности (чтобы добавить фамилию еще одного преподавателя, придется ввести в таблицу две новых строки).

12.2.2. Нормальные формы

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

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

Реляционная таблица находится в первой нормальной форме (1НФ), если (слайд 10 )

Каждое значение любого ее атрибута является атомарным;

В таблице отсутствуют одинаковые строки;

Каждый столбец уникально поименован именем атрибута и содержит текущее значение этого атрибута;

Каждый атрибут ассоциирован с определенным доменом (типом данных).

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

Реляционная таблица находится во второй нормальной форме (2НФ), если она удовлетворяет определению 1НФ и все ее атрибуты, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом.

Реляционная таблица находится в третьей нормальной форме (3НФ) (слайд 11 ), если она удовлетворяет определению 2НФ и ни один из ее не ключевых атрибутов не связан транзитивной функциональной зависимостью с первичным ключом (т.е. ни один из не ключевых атрибутов не связан функциональной зависимостью с любым другим не ключевым атрибутом).

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

Обычно на практике довольствуются приведением реляционной БД к 3НФ или к НФБК, поэтому здесь не будем рассматривать более старшие нормальные формы.

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

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

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

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

12.3. Процедура нормализации (слайд 14 )

Процедура приведения таблиц к 3НФ основывается на том, что единственными функциональными зависимостями в любой таблице должны быть зависимости вида А →K , где K - первичный ключ, а А - некоторый атрибут. Цель нормализации состоит в удалении других функциональных зависимостей.

Возможны два случая:

1. Таблица имеет составной первичный ключ, например, (К1,К2 ), и включает также атрибут А , который функционально зависит от части этого ключа (например, от К2 ), но не от полного ключа. В этом случае рекомендуется сформировать другую таблицу, содержащую атрибуты К2 и А (первичный ключ - К2 ), и удалить атрибут А из первоначальной таблицы (слайд 15 ).

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

Таким образом, повторяя применение двух рассмотренных правил, для любой заданной таблицы почти во всех реальных практических ситуациях можно получить в конечном счете множество таблиц, которые находятся в 3НФ или НФБК и не содержат каких-либо функциональных зависимостей вида, отличного от А →К .

12.4. Получение реляционной схемы из ER-диаграммы (слайд 17 )

1. Каждая простая сущность превращается в таблицу (отношение). Имя сущности становится именем таблицы.

2. Связь «многие ко многим» рассматривается как сущность-связь и превращается в таблицу (отношение). Тем самым связь «многие ко многим» трансформируется в две связи «многое к одному».

3. Каждый атрибут становится возможным столбцом с тем же именем. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут. Если атрибут является множественным, то для него строится отдельное отношение.

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

5. Связи «многие к одному» и «один к одному» становятся внешними ключами. Т.е. создается копия уникального идентификатора с конца связи "один", и соответствующие столбцы составляют внешний ключ.

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

7. Если в концептуальной схеме присутствуют подтипы, то возможны два варианта.

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

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

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

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

Реляционная база данных - это набор нормализованных отношений, которые различаются по именам.

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

Эти отношения обладают следующими характеристиками:

отношение имеет имя, которое отличается от имен всех других отношений в реляционной схеме;

каждая ячейка отношения содержит только одно элементарное (неделимое) значение;

каждый атрибут имеет уникальное имя;

значения атрибута берутся из одного и того же домена;

каждый кортеж является уникальным, т.е. дубликатов кортежей быть не может;

порядок следования атрибутов не имеет значения;

теоретически порядок следования кортежей в отношении не имеет значения; (Но практически этот порядок может существенно повлиять на эффективность доступа к ним)

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

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

поскольку отношение является множеством, то порядок элементов не имеет значения. Следовательно, порядок кортежей в отношении несуществен.

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

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

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

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

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

Более точно, сущность - это множество индивидуальных объектов - экземпляров, причем все эти объекты являются различными.

Связь - это функциональная зависимость между сущностями. Например, "служащий" совершает "продажи".

Каждая сущность обладает атрибутами. Атрибут - это свойство объекта, характеризующее его экземпляр. Сущность "служащий" может иметь атрибуты "имя", "дата рождения" и т.д.

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

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

Базовые отношения - это реально существующие модели отношения, которые соответствуют реальному объекту предметной области.

Пусть даны отношения R1 и R2. Пусть k1, - это первичный ключ отношения R1.

Если в отношении R2 присутствуют атрибуты k1, то для отношения R2, k1 - это внешний ключ. Если базовое отношение R2 содержит внешний ключ k1, то каждое значение k1 в R2 должно быть либо равным какому-либо значению R1, либо полностью неопределенным.

Достоинствами реляционного подхода являются:

1. Наличие простого, и в тоже время мощного математического аппарата

2. Возможность навигационного манипулирования данными без знания физических основ хранения данных.

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

Итак, условия первой нормальной формы:

Определить требуемые элементы данных, потому что они становятся столбцами в таблице. Поместить связанные элементы данных в таблицу.

Гарантировать отсутствие повторяющихся групп данных.

Гарантировать наличие первичного ключа.

Значение всех атрибутов атомарны.

Информационная система находится в первой нормальной форме.

Условия второй нормальной формы:

Отношение в первой нормальной форме.

Независимость первичных ключей и столбцов

Информационная система находится во второй нормальной форме.

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

Условия третьей нормальной формы:

Отношение во второй нормальной форме.

Все поля, не входящие в первичный ключ, зависят от первичного ключа.

Информационная система находится в третьей нормальной форме.

Таким образом, нормализация отношений успешно достигнута.

После нормализации отношений было создано 7 таблиц. Проиллюстрируем эти таблицы в режиме конструктора:

Рисунок 2.2 - Главная таблица в режиме конструктора

Рисунок 2.3 - Таблица "Инструкторы" в режиме конструктора

Рисунок 2.4 - Таблица "Клиенты" в режиме конструктора

Рисунок 2.5 - Таблица "Код операции" в режиме конструктора

Рисунок 2.6 - Таблица "Подъемник" в режиме конструктора

Рисунок 2.7 - Таблица "Прокат (прокат)" в режиме конструктора

Рисунок 2.8 - Таблица "Прокат (экипировка)" в режиме конструктора

Рисунок 2.9 - Таблица "Склон - Трансфер" в режиме конструктора

Рисунок 2.10 - Таблица "Склоны" в режиме конструктора

Рисунок 2.11 - Таблица "Услуга (трансфер)" в режиме конструктора

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

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

Реляционная модель данных

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

атрибутами и значениями на пересечении соответствующего атрибута с записью (кортежем).

Под термином "Отношение" понимается множество данных, объединенных в совокупность записей (кортежей) и описанных заголовком, содержащим множество атрибутов.

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

R{A,T},i={1..n} (11)

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

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

Вод термином "Домен" в теории баз данных понимается допустимое множество поименованных значений одного типа имеющих определенный смысл

Из данного определения следует, что домен характеризуется следующими свойствами:

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

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

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

Описание кортежей использует ряд важных свойств, некоторые из которых представлены ниже:

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

для компонентов кортежа, аналогично элементам домена, не предполагается какое-либо упорядочивание;

каждое подмножество кортежей представляется гоже кортежем.

Объединяя домены и кортежи, можно сформировать отношение, которое в общем виде определяется следующим образом;

R[<Заголовок>]{<Список кортежей >}. (1.2)

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

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

Рис. 1.13. Пример отношения "Сотрудники"

Любое отношение в реляционной базе данных характеризуется следующими свойствами.

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

Каждому атрибуту в представленном примере в рамках каждого кортежа поставлено в соответствие только одно значение, что видно на пересечении выделенного домена "ФИО сотрудника" и кортежа с ФИО "Петров Петр Петрович". Отношение, которое соответствует этому свойству, является нормализованным , т.е. находится в данном случае в первой нормальной форме, 1НФ.

2. Атрибуты не являются упорядоченными по какому-либо правилу.

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

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

3. Кортежи не являются упорядоченнымии по какому-либо правилу.

Данное свойство следует из того, что тело отношения представляется

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

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

4. В отношении отсутствуют дубликаты кортежей.

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

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

Зачастую, когда нет необходимости отражать значения, описываемые в отношении (тело отношения), в реляционной модели ограничиваются только указанием заголовка отношения с прописанием наименования самого отношения или только наименованием отношения. Такие представления реляционной модели данных являются фильтрованными отображениями, которые применяются в специализированных средствах моделирования структур баз данных, как, например, в IBM InfoSphere Data Architect (рис. 1.14).

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

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

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

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

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

Таблица 13

Варианты представления реляционных моделей данных

Вид представления	Используемая терминология	Назначение
Модель с отражением наименования отношения, атрибутивного состава, связей	Сущность Тип данных	Используется для моделирования логической структуры данных для последующего перехода на физический уровень
Модель с отражением заголовка и тела с возможными данными	Отношение Заголовок Атрибут/Домен Тип данных	Используется для представления с указанием возможных значений данных и применения при необходимости анализа возможных операций над отношениями и данными в отношениях
Модель с отображением структур физического представления данных в СУБД	Атрибут/11оле/Колонка Тип данных	Используется для отображения варианта представления структуры, которая будет реализована на физическом уровне в СУБД

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

• Бойко В. В.. Савинков В. М. Проектирование баз ланных информационных систем.
• Типы данных будут рассматриваться в рамках последующих глав.
• Термин "Нормализация" и нормальные формы будут рассматриваться в гл. 2.

Часть 2. Реляционная модель данных

Реляционная модель является удобной и наиболее привыч­ной формой представления данных в виде таблицы.

В отличие от иерархической и сетевой моделей, такой способ представления:

1. понятен пользователю-непрограммисту;

2. позволяет легко изменять схему - присоединять новые элементы данных и запи­си без изменения соответствующих подсхем;

3. обеспечивает не­обходимую гибкость при обработке непредвиденных запросов. К тому же любая сетевая или иерархическая схема может быть представлена двумерными отношениями.

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

Пользо­ватель модели сам должен для себя решить вопрос, обладают ли соответствующие сущности реального мира однородностью. Этим самым решается проблема пригодности модели для пред­полагаемого применения.

Основными понятиями, с помощью которых определяется реляционная модель, являются следующие:

1. домен,

2. отношение,

3. кортеж,

4. кардинальность,

5. атрибуты,

6. степень,

7. первичный ключ.

Соотношение этих понятий иллюстрируется рисунок 7.

Рис. 7. Основные понятия реляционной модели

Таблица 7.

Эти поня­тия представляют специальную терминологию, введенную авто­рами теоретических основ, однако они имеют и более привыч­ные аналоги (но не во всем эквиваленты), соответствие которых приведено в следующей таблице 1.

Домен - это совокупность значений, из которой берутся зна­чения соответствующих атрибутов определенного отношения. С точки зрения программирования, домен - это тип данных, определяемый системой (стандартный) или пользователем и совокупность дополнительных ограничений, накладываемых на эти данные.

В математических дисциплинах понятию «таблица» соответствует понятие «отношение» (relation). Отсюда и произошло название модели - реляционная. То есть, применительно к базам данных понятия «реляци­онная БД» и «табличная БД» по существу являются синонимами.

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

Остальные ключи, которые можно также использовать в ка­честве первичных, называются потенциальными или альтерна­тивными ключами.

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

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

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

Модель предъявляет к таблицам следующие требования:

1. данные в ячейках таблицы должны быть структурно неде­лимыми 1 ;

2. данные в одном столбце должны быть одного типа;

3. каждый столбец должен быть уникальным (недопустимо дублирование столбцов);

4. столбцы размещаются в произвольном порядке;

5. строки размещаются в таблице также в произвольном по­рядке;

6. столбцы имеют уникальные наименования.

В целом концепция реляционной модели определяется сле­дующими двенадцатью правилами Кодда (в лекции правила приводятся по ).

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

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

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

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

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

Определение данных;

Определение представлений;

Обработку данных (интерактивную и программную);

Условия целостности;

Идентификацию прав доступа;

Границы транзакций (начало, завершение и отмена).

6. Правило обновления представлений. Все представления, ко­торые теоретически можно обновить, должны быть доступны для обновления.

7. Правило добавления, обновления и удаления. Возможность работать с отношением как с одним операндом должна сущест­вовать не только при чтении данных, но и при добавлении, об­новлении и удалении данных.

8. Правило независимости физических данных. Прикладные программы и утилиты для работы с данными должны на логиче­ском уровне оставаться нетронутыми при любых изменениях способов хранения данных или методов доступа к ним.

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

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

11. Правило независимости распространения. Реляционная СУБД не должна зависеть от потребностей конкретного клиента.

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

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

Правило 3 требует, чтобы отсутствующие данные можно было представить с помощью недействительных значений (NULL ).

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

Правило 5 требует, чтобы СУБД использовала язык реляци­онной базы данных, например SQL. Такой язык должен поддержи­вать все основные функции СУБД - создание базы данных, чте­ние и ввод данных, реализацию защиты базы данных и т. д.

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

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

Правила 8 и 9 означают отделение пользователя и прикладной программы от низкоуровневой реализации базы данных. Они утверждают, что конкретные способы реализации хранения или доступа, используемые в СУБД, и даже изменения структуры таблиц базы данных не должны влиять на возмож­ность пользователя работать с данными.

Правило 10 гласит, что язык базы данных должен поддержи­вать ограничительные условия, налагаемые на вводимые данные и действия, которые могут быть выполнены над данными.

Правило 11 гласит, что язык базы данных должен обеспечи­вать возможность работы с распределенными данными, располо­женными на других компьютерных системах.

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

Литература

1. Дейт К. Введение в системы баз данных: Пер. с англ. - М.: Наука, 1980.- 463 с.

2. Грофф Дж., Ваинберг П. SQL: полное руководство / Пер. с англ. 2-е изд. К.: BHV, 2001.

Реляционная модель базируется на теоретико-множественном понятии отношения. В математических дисциплинах существует понятие «отношение » (relation), физическим представлением которого является таблица . Отсюда и произошло название модели - реляционная .

Применительно к БД понятия «реляционная БД» и «табличная БД» являются синонимами. Реляционные базы получили наибольшее распространение в мире. Почти все продукты БД, созданные с конца 70-х годов, являются реляционными.

В 1970 году появились работы, в которых обсуждались возможности применения различных табличных моделей данных. Наиболее значительной из них была статья сотрудника фирмы IBM д-ра Э. Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks (Реляционная модель данных для больших совместно используемых банков данных). CACM 13: 6, June 1970), где впервые был применен термин "реляционная модель данных" . Проект System R был разработан в исследовательской лаборатории корпорации IBM. Этот проект был задуман с целью доказать практичность реляционной модели. Реляционные СУБД относятся к СУБД второго поколения.

Цели создания реляционной модели данных:

1. Обеспечение более высокой степени независимости от данных.

2. Создание прочного фундамента для решения проблем непротиворечивости и избыточности данных.

3. Расширение языков управления данными за счет включения операций над множествами.

Коммерческие системы на основе реляционной модели данных начали появляться в конце 70-х - начале 80-х годов. В настоящее время существует несколько сотен типов различных реляционных СУБД.

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

Основными понятиями, с помощью которых определяется реляционная модель, являются следующие:

- реляционная БД - набор нормализованных отношений;

- отношение - файл, плоская таблица, состоящая из столбцов и строк; таблица, в которой каждое поле является атомарным;

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

- универсум - совокупность значений всех полей или совокупность доменов;

- кортеж - запись, строка таблицы;

- кардинальность - количество строк в таблице;

- атрибуты - поименованныеполя, столбцы таблицы;

- степень отношения - количество полей (столбцов);

- схема отношения - упорядоченный список имен атрибутов;

- схема реляционной БД - совокупность схем отношений;

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

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

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

Соотношение этих понятий иллюстрируется на рис. 4.5.

№	ФИО	Год рожд.	Должность	Кафедра
1.	Иванов И. И.		Зав. каф.	22
2.	Сидоров С. С.		Проф.	22
3.	Андреева Г. Г.		Проф.	22
4.	Цветкова С. С.		Доцент
5.	Козлов К. К.		Доцент	22
6.	Петров П. П.		Ст. преп.	22

		Атрибуты

рис. 4.5. Основные понятия реляционной модели данных.

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

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

Внешние ключи реализуют связи между таблицами БД.

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

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

Каждая реляционная таблица обладает следующими свойствами :

Имеет имя, которое отличается от имен всех других таблиц;

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

Все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;

Каждый столбец имеет уникальное имя;

Одинаковые строки в таблице отсутствуют;

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