Общая характеристика реляционной модели данных

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

• 
  Структурной части.
• 
  Целостной части.
• 
  Манипуляционной части.

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

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

В данной главе рассматривается структурная часть реляционной модели.

^ Типы данных

Любые данные, используемые в программировании, имеют свои типы данных.

Важно! Реляционная модель требует, чтобы типы используемых данных были простыми .

Для уточнения этого утверждения рассмотрим, какие вообще типы данных обычно рассматриваются в программировании. Как правило, типы данных делятся на три группы:

• 
  Простые типы данных.
• 
  Структурированные типы данных.
• 
  Ссылочные типы данных.

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

• 
  Логический.
• 
  Строковый.
• 
  Численный.

• 
  Целый.
• 
  Вещественный.
• 
  Дата.
• 
  Время.
• 
  Денежный.
• 
  Перечислимый.
• 
  Интервальный.
• 
  И т.д.…

^

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

• 
  Массивы
• 
  Записи (Структуры)

Называемое множеством индексов. Отображение

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

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

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

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

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

^ Ссылочные типы данных

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

^ Типы данных, используемые в реляционной модели

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

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

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

Домены

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

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

• 
  Домен имеет уникальное имя (в пределах базы данных).
• 
  Домен определен на некотором простом типе данных или на другом домене.

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

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

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

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

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

Замечание . Не всегда очевидно, как задать логическое условие, ограничивающее возможные значения домена. Я буду благодарен тому, кто приведет мне условие на строковый тип данных, задающий домен "Фамилия сотрудника". Ясно, что строки, являющиеся фамилиями не должны начинаться с цифр, служебных символов, с мягкого знака и т.д. Но вот является ли допустимой фамилия "Ггггггыыыыы"? Почему бы нет? Очевидно, нет! А может кто-то назло так себя назовет. Трудности такого рода возникают потому, что смысл реальных явлений далеко не всегда можно формально описать. Просто мы, как все люди, интуитивно понимаем, что такое фамилия, но никто не может дать такое формальное определение, которое отличало бы фамилии от строк, фамилиями не являющимися. Выход из этой ситуации простой - положиться на разум сотрудника, вводящего фамилии в компьютер.

^ Отношения, атрибуты, кортежи отношения

Определения и примеры

Фундаментальным понятием реляционной модели данных является понятие отношения . В определении понятия отношения будем следовать книге К. Дейта .

Определение 1. Атрибут отношения есть пара вида <Имя_атрибута: Имя_домена>.

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

Определение 2 . Отношение , определенное на множестве доменов (не обязательно различных), содержит две части: заголовок и тело.

Заголовок отношения содержит фиксированное количество атрибутов отношения:

Тело отношения содержит множество кортежей отношения. Каждый кортеж отношения представляет собой множество пар вида <Имя_атрибута: Значение_атрибута>:

Таких что значение атрибута принадлежит домену

Отношение обычно записывается в виде:

Или короче

,

Или просто

Число атрибутов в отношении называют степенью (или -арностью ) отношения.

Мощность множества кортежей отношения называют мощностью отношения.

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

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

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

Пример 1 . Рассмотрим отношение "Сотрудники" заданное на доменах "Номер_сотрудника", "Фамилия", "Зарплата", "Номер_отдела". Т.к. все домены различны, то имена атрибутов отношения удобно назвать так же, как и соответствующие домены. Заголовок отношения имеет вид:

Сотрудники (Номер_сотрудника, Фамилия, Зарплата, Номер_отдела)

Пусть в данный момент отношение содержит три кортежа:

(1,Иванов, 1000, 1)

(2, Петров, 2000, 2)

(3, Сидоров, 3000, 1)

Такое отношение естественным образом представляется в виде таблицы:

^ Таблица 1 Отношение "Сотрудники"

Определение 3 . Реляционной базой данных называется набор отношений.

Определение 4 . Схемой реляционной базы

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

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

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

1. 
   ^ В отношении нет одинаковых кортежей . Действительно, тело отношения есть множество кортежей и, как всякое множество, не может содержать неразличимые элементы (см. понятие множества в гл.1.). Таблицы в отличие от отношений могут содержать одинаковые строки.
2. 
   ^ Кортежи не упорядочены (сверху вниз) . Действительно, несмотря на то, что мы изобразили отношение "Сотрудники" в виде таблицы, нельзя сказать, что сотрудник Иванов "предшествует" сотруднику Петрову. Причина та же - тело отношения есть множество, а множество не упорядочено. Это вторая причина, по которой нельзя отождествить отношения и таблицы - строки в таблицах упорядочены. Одно и то же отношение может быть изображено разными таблицами, в которых строки идут в различном порядке .
3. 
   ^ Атрибуты не упорядочены (слева направо) . Т.к. каждый атрибут имеет уникальное имя в пределах отношения, то порядок атрибутов не имеет значения. Это свойство несколько отличает отношение от математического определения отношения (см. гл.1 - компоненты кортежей там упорядочены ). Это также третья причина, по которой нельзя отождествить отношения и таблицы - столбцы в таблице упорядочены. Одно и то же отношение может быть изображено разными таблицами, в которых столбцы идут в различном порядке .
4. 
   ^ Все значения атрибутов атомарны . Это следует из того, что лежащие в их основе атрибуты имеют атомарные значения. Это четвертое отличие отношений от таблиц - в ячейки таблиц можно поместить что угодно - массивы, структуры, и даже другие таблицы.

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

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

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

Труднее всего дать определение вещей, которые всем понятны. Если давать не строгое, описательное определение, то всегда остается возможность неправильной его трактовки. Если дать строгое формальное определение, то оно, как правило, или тривиально, или слишком громоздко. Именно такая ситуация с определением отношения в Первой Нормальной Форме (1НФ ). Совсем не говорить об этом нельзя, т.к. на основе 1НФ строятся более высокие нормальные формы, которые рассматриваются далее в гл. 6 и 7. Дать определение 1НФ сложно ввиду его тривиальности. Поэтому, дадим просто несколько объяснений.

Объяснение 1 . Говорят, что отношение находится в 1НФ, если оно удовлетворяет определению 2.

Это, собственно, тавтология, ведь из определения 2 следует, что других отношений не бывает. Действительно, определение 2 описывает, что является отношением, а что - нет, следовательно, отношений в непервой нормальной форме просто нет.

Объяснение 2 . Говорят, что отношение находится в 1НФ, если его атрибуты содержат только скалярные (атомарные) значения.

Опять же, определение 2 опирается на понятие домена, а домены определены на простых типах данных.

Непервую нормальную форму можно получить, если допустить, что атрибуты отношения могут быть определены на сложных типах данных - массивах, структурах, или даже на других отношениях. Легко себе представить таблицу, у которой в некоторых ячейках содержатся массивы, в других ячейках - определенные пользователями сложные структуры, а в третьих ячейках - целые реляционные таблицы, которые в свою очередь могут содержать такие же сложные объекты. Именно такие возможности предоставляются некоторыми современными пост-реляционными и объектными СУБД.

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

Таким образом появляется третье объяснение Первой Нормальной Формы:

Объяснение 3 . Отношение находится в 1НФ, если оно является плоской таблицей.

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

Выводы

Реляционная модель данных состоит из трех частей:

• 
  Структурной части.
• 
  Целостной части.
• 
  Манипуляционной части.

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

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

Отношение обладает следующими свойствами:

• 
  В отношении нет одинаковых кортежей.
• 
  Кортежи не упорядочены (сверху вниз).
• 
  Атрибуты не упорядочены (слева направо).
• 
  Все значения атрибутов атомарны.

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

Отношение находится в Первой Нормальной Форме (1НФ ), если оно содержит только скалярные (атомарные) значения.

Терминология и базовые понятия реляционных БД

Почти все программные продукты, созданные с конца 70-х г. основаны на реляционном подходе:

1. Данные представлены в двухмерных таблицах, организованных по определенным правилам.

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

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

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

Базовые понятия реляционных баз данных:

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

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

3. Кортеж , соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения.

4. Атрибут – столбец таблицы, поле файла БД. Значения атрибутов в таблице-отношении могут иметь только один определенный вид функциональной зависимости друг от друга, а именно все значения в произвольном кортеже должны по отдельности зависеть только от значений столбца или группы столбцов - одних для всего отношения. Такой столбец или группа столбцов называются ключевыми, а значения атрибутов в них - ключами.

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

6. Степень отношения определяется количеством атрибутов, которое оно содержит. Отношение с одним атрибутом имеет степень 1 и называется унарным отношением. Отношение с двумя атрибутами называется бинарным, отношение с тремя атрибутами – тернарным, а для отношения с большим количеством атрибутов используется термин n-арное.

7. Кардинальность отношений – количество кортежей, которое содержится в отношении. Эта характеристика меняется при каждом удалении или добавлении кортежей.

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

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

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

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

· Уникальность. В каждом кортеже отношения R значение ключа К единственным образом идентифицирует этот кортеж.

· Неприводимость. Никакое допустимое подмножество ключа К не обладает свойством уникальности.

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

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

14. Отношение - это множество кортежей, соответствующих одной схеме отношения.

15. Базовое отношение – отношение, кортежи которого физически хранятся в базе данных.

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

17. Фундаментальные свойства отношений:

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

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

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

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

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

· Порядок следования атрибутов не имеет значения.

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

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

1. Структура модели основывается на нормализованных отношениях с учетом базовых понятий реляционной БД.

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

3. Целостность (от англ. integrity – нетронутость, неприкосновенность, сохранность, целостность) понимается как правильность данных в любой момент времени.

Лекция БД Глава 2 РЕЛЯЦИОННЫЕ БАЗЫ ДАННЫХ 2.1. Термины и определения Развитие реляционных баз данных началось в конце 1960-х гг., когда появились первые работы, в которых обсуждались возмож-ности использования привычных для специалиста способов фор-мализованного представления данных в виде таблиц. Некоторые специалисты такой способ представления информации называли таблицами решений, другие - табличными алгоритмами. Теоре-тики реляционных баз данных табличный способ представления информации называли даталогическими моделями. Основоположником теории реляционных баз данных считается сотрудник фирмы IВM доктор Э. Ф. Кодд, опубликовавший 6 июня 1970 г. статью «Реляционная модель данных для больших коллек-тивных банков данных» «А Relational Model of Data for Large Shared Data Banks». В этой статье впервые и был использован термин «ре-ляционная модель данных», что и положило начало реляцион-ным базам данных. Теория реляционных баз данных, разработанная в 1970- х гг. в США доктором Э. Ф. Коддом, опиралась на математический аппарат те-ории множеств. Он доказал, что любой набор данных МОЖНО пред-ставить в виде двумерных таблиц особого вида, известных в матема-тике как отношения. От английского слова «relation» «отношение») и произошло название «реляционная модель данных». В настоящее время теоретическую основу проектирования баз данных (БД) состав-ляет математический аппарат реляционной алгебры (см. подразд. 1.2). Таким образом, реляционная БД представляет собой инфор-мацию (данные) об объектах, представленную в виде двумерных массивов - таблиц, объединенных определенными связями. База данных может состоять и из одной таблицы. Прежде чем присту-пить к дальнейшему изучению реляционных баз данных, рассмот-рим применяемые в теории и практике термины и определения. Таблица базы данных - двумерный массив, содержащий ин-формацию об одном классе объектов. В теории реляционной ал-гебры двумерный массив (таблицу) называют отношением. Таблица состоит из следующих элементов: поле, ячейка, за-пись (рис. 2.1). Поле содержит значения одного из признаков, характеризу-ющих объекты БД. Число полей в таблице соответствует числу при-знаков, характеризующих объекты БД. 22 Ячейка содержит конкретное значение соответствующего поля (признака одного объекта). Запись - строка таблицы. Она содержит значения всех призна-ков, характеризующих один объект. Число записей (строк) соот-ветствует числу объектов, данные о которых содержатся в таб-лице. В теории баз данных термину запись соответствует понятие кор-теж - последовательность атрибутов, связанных между собой от-ношением AND (И). В теории графов кортеж означает простую ветвь ориентированного графа - дерева. В табл. 2.1 приведены термины, применяемые в теории и прак-тике разработки реляционных баз данных. Одним из важных понятий, необходимых для построения оп-тимальной структуры реляционных баз данных, является понятие ключа, или ключевого поля. Ключом считается поле, значения которого однозначно опреде-ляют значения всех остальных полей в таблице. Например, поле «Номер паспорта», или «Идентификационный номер налогопла-тельщика (ИНН)», однозначно определяет характеристики любого физического лица (при составлении соответствующих таблиц баз данных ДЛЯ отделов кадров или бухгалтерии предприятия).
23

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

Учет данных факторов при проектировании реляционных баз данных осуществляется методами нормализации таблиц и уста-HoBлeHиeM связей между ними.

первая нормальная форма (First Normal Form - 1NF); вторая нормальная форма (Second Normal Form - 2NF); третья нормальная форма (Third Normal Form - ЗNF); нормальная форма Бойса - Кодда (Brice - Codd Normal Form -BCNF); четвертая нормальная форма (Foиrth Normal Form - 4NF); пятая нормальная форма, или нормальная форма проекции--соединения (Fifth Normal Form - 5NF, или PJ/NF).

Поле «Габаритные размеры (длина х ширина х высота), мм» , разделить на три поля: «Длина, мм», «Ширина, мм», «Высота, мм». Ключевым полем данной таблицы может быть поле «Модель станка» или «№ п/п» Вид нормальной формы имеет табл. 2.3. Рассмотрим еще один пример. На рис. 2.2 показан фрагмент бланка зачетно-экзаменационной ведомости, который, как и в предыдущем примере, изначально не предназначался для компь-ютерной обработки. Пусть мы хотим создать базу данных для автоматизированной обработки результатов зачетно-экзаменационной сессии в соответствии
27

с содержанием зачетно-экзаменационной ведомости. Для этого преобразуем содержание бланка в таблицы базы данных. Ис-ходя из необходимости соблюдения условий функциональной за-висимости между полями необходимо сформировать, как мини-мум, две таблицы (рис. 2.3) (ключевые поля в каждой таблице выделены полужирным шрифтом). В первой таблице содержатся результаты сдачи зачета (экзамена) каждым студентом по конк-ретному предмету. Во второй таблице содержатся результирующие итоги сдачи зачета (экзамена) конкретной группы студентов по конкретному предмету. В первой таблице ключевым является поле «ФИО студента», а во второй таблице - поле «Дисциплина». Таб-лицы должны быть связаны между собой по полям «Дисциплина» И «Шифр группы».

Представленные структуры таблиц полностью отвечает требо-ваниям первой нормальной формы, но характеризуется следу-ющими недостатками: добавление новых данных в таблицы требует ввода значений для всех полей; в каждую строку каждой таблицы необходимо вводить повто-ряющиеся значения полей «Дисциплина», «ФИО преподавателя», «Шифр группы». Следовательно, при таком составе таблиц и их структуре име-ется явная избыточность информации, что, естественно, потре-бует дополнительных объемов памяти. Чтобы избежать перечисленных недостатков, необходимо при-вести таблицы ко второй или третьей нормальной форме. Вторая нормальная форма. Таблица находится во второй нор-мальной форме, если она удовлетворяет требованиям первой нор-мальной формы и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом. 28

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

Если же первичный ключ составной, то таблица необязатель-но находится во второй нормальной форме. Тогда ее необходимо разделить на две или более таблиц таким образом, чтобы первич-ный ключ однозначно идентифицировал значение в любом поле. Если в таблице имеется хотя бы одно поле, не зависящее от пер-вичного ключа, то в первичный ключ необходимо включить до-полнительные колонки. Если таких колонок нет, то необходимо добавить новую колонку. Исходя из данных условий, определяющих вторую нормаль-ную форму, можно сделать следующие выводы по характеристике составленных таблиц (см. рис. 2.3). В первой таблице нет прямой связи между ключевым полем и полем «ФИО преподавателя», поскольку зачет или экзамен по одному предмету могут принимать разные преподаватели. В табли-це существует полная функциональная зависимость только между всеми остальными полями и ключевым полем «Дисциплина». Аналогично во второй таблице нет прямой связи между ключе-вым полем и полем «ФИО преподавателя». Для оптимизации базы данных, в частности для уменьшения требуемого объема памяти из-за необходимости повторения в каждой записи значений полей «Дисциплина» И «ФИО препо-давателя», необходимо изменить структуру базы данных - пре-образовать исходные таблицы во вторую нормальную форму. Состав таблиц измененной структуры базы данных показан на рис. 2.4. Преобразованная структура базы данных состоит из шести таб-лиц, две из которых связаны между собой (ключевые поля в каж-дой таблице выделены полужирным шрифтом). Все таблицы удов-летворяют требованиям второй нормальной формы. Пятая и шестая таблицы имеют в полях повторяющиеся значе-ния, но, учитывая, что эти значения представляют собой целые числа вместо текстовых данных, общий объем требуемой памяти для хранения информации значительно меньше, чем в исходных таблицах (см. рис. 2.1). Кроме того, новая структура базы данных обеспечит возмож-ность заполнения таблиц различными специалистами (подразде-лениями управленческих служб). Дальнейшая оптимизация таб-лиц баз данных сводится к приведению их к третьей нормальной форме. Третья нормальная форма. Таблица находится в третьей нор-мальной форме, если она удовлетворяет определению второй нор-мальной формы и ни одно из ее не ключевых полей не зависит функционально от любого другого не ключевого поля. 29

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

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

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

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

На реляционной модели данных строятся реляционные базы данных .

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

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

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

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

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

Сущность – некоторый обособленный объект или событие, информацию о котором необходимо сохранять в базе данных и который имеет определенный набор свойств – атрибутов. Сущностями могут быть как физические (реально существующие) объекты, например СТУДЕНТ (атрибуты – Номер зачетной книжки, Фамилия, Имя, Отчество, Специальность, Номер группы и т.д.), так и абстрактные, например ЭКЗАМЕН (атрибуты – Дисциплина, Дата, Преподаватель, Аудитория и пр.). Для сущностей различают тип и экземпляр. Тип характеризуется именем и списком свойств, а экземпляр – конкретными значениями свойств.

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

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

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

3) однозначные и многозначные. Атрибуты могут иметь соответственно одно или много значений для каждого экземпляра сущности;

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

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

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

Схема отношения (заголовок отношения) представляет собой список имен атрибутов с указанием имен доменов.

Кортеж, соответствующий данной схеме отношения, представляет собой множество пар (имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута. Аргумент “значение” является допустимым значением домена данного атрибута.

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

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

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

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

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

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

Раздел 3. «Базы данных»

1. Информационное обеспечение автоматизированных систем.

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

По ГОСТ 24.205-80 описание информационного обеспечения АСУ должно состоять из следующих разделов:

принципы организации информационного обеспечения;

организация сбора и передачи информации;

построение системы классификации и кодирования;

организация внутримашинной информационной базы;

организация внемашинной информационной базы.

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

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

Информационное обеспечение автоматизированной системы – это совокупность форм документов, классификаторов, нормативной базы и реализованных решений по объемам, размещению и формам существования информации, применяемой в автоматизированной системе при ее функционировании (ГОСТ 34.003-90 ("Автоматизированные системы. Термины и определения")).

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

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

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

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

ИО автоматизированных информационных систем состоит из внемашинного и внутри машинного ИО .

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

Внутримашинное ИО содержит массивы данных на машинных носителях и программу организации доступа к этим данным.

Внемашинное ИО - информация, которая воспринимается человеком без каких-либо технических средств (документы).

Под классификацией понимается условное расчленение множества элементов информации на подмножества на основании сходства или различия по какому-то признаку.

2. СУБД и приложения баз данных.

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

Современная СУБД состоит из:

ядра - части программ СУБД, отвечающих за управление данными в памяти и журнализацию; Процессора языка базы данных, обеспечивающего оптимизацию запросов на извлечение и изменение данных, и создание БД;

Подсистемы поддержки времени исполнения, интерпретирующую программы манипуляции данными, которые создают интерфейс пользователя СУБД;

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

Основными функциями СУБД являются

Управление данными, хранящимися во внешней памяти;

Управление данными, загруженными в оперативную память с использованием дискового кэша; Журнализация событий и изменений, резервное копирование и восстановление БД после сбоев;

Поддержка языков обращения с БД (язык определения данных, язык манипулирования данными);

Классификации СУБД

Существует несколько признаков, по которым можно классифицировать СУБД.

СУБД по модели данных бывают:

Иерархические СУБД, Сетевые СУБД, Реляционные СУБД, Объектно-ориентированные СУБД, Объектно-реляционные СУБД. В настоящее время в серьезных проекта используются 2 последних типа. СУБД по степени распределённости. Локальные (СУБД размещается только на одном компьютере) Распределённые (части СУБД могут размещаться на 2-х и более компьютерах).

Приложений баз данных

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

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

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

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

Механизм внутреннего представления данных является ядром приложения баз данных. Он обеспечивает хранение полученных данных в приложении и предоставляет их по запросу других частей приложения.

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

Бизнес-логика приложения представляет собой набор реализованных в программе алгоритмов обработки данных.

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

Источник данных представляет собой хранилище данных (саму базу данных) и СУБД, управляющую данными, обеспечивающую целостность и непротиворечивость данных.

3. Современная концепция реляционных БД.

Основные концепции реляционных баз данных

Прежде чем подробно рассматривать каждый из этих шагов, остановимся на основных концепциях реляционных баз данных. В реляционной теории одним из главных является понятие отношения. Математически отношение определяется следующим образом. Пусть даны n множеств D1,D2,...,Dn. Тогда R есть отношение над этими множествами, если R есть множество упорядоченных наборов вида , где d1 - элемент из D1, d2 - элемент из D2, ..., dn - элемент из Dn. При этом наборы вида называются кортежами, а множества D1,D2,...,Dn - доменами. Каждый кортеж состоит из элементов, выбираемых из своих доменов. Эти элементы называются атрибутами, а их значения - значениями атрибутов, рис.9-а представляет нам графическое изображение отношения с разных точек зрения.

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

отношение, таблица

кортеж, строка, запись

атрибут, столбец, поле.

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

Атрибут (или набор атрибутов), который может быть использован для однозначной идентификации конкретного кортежа (строки, записи), называется первичным ключом. Первичный ключ не должен иметь дополнительных атрибутов. Это значит, что если из первичного ключа исключить произвольный атрибут, оставшихся атрибутов будет недостаточно для однозначной идентификации отдельных кортежей. Для ускорения доступа по первичному ключу во всех системах управления базами данных (СУБД) имеется механизм, называемый индексированием. Грубо говоря, индекс представляет собой инвертированный древовидный список, указывающий на истинное местоположение записи для каждого первичного ключа. Естественно, в разных СУБД индексы реализованы по-разному (в локальных СУБД - как правило, в виде отдельных файлов), однако, принципы их организации одинаковы.

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

Для поддержания ссылочной целостности данных во многих СУБД имеется механизм так называемых внешних ключей. Смысл этого механизма состоит в том, что некоему атрибуту (или группе атрибутов) одного отношения назначается ссылка на первичный ключ другого отношения; тем самым закрепляются связи подчиненности между этими отношениями. При этом отношение, на первичный ключ которого ссылается внешний ключ другого отношения, называется master-отношением, или главным отношением; а отношение, от которого исходит ссылка, называется detail-отношением, или подчиненным отношением. После назначения такой ссылки СУБД имеет возможность автоматически отслеживать вопросы “ненарушения“ связей между отношениями, а именно:

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

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

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

ДОПОЛНЕНИЕ

Базовые понятия реляционных баз данных

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

Тип данных

Понятие тип данных в реляционной модели данных полностью адекватно понятию типа данных в языках программирования. Обычно в современных реляционных БД допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких как "деньги"), а также специальных "темпоральных" данных (дата, время, временной интервал). Достаточно активно развивается подход к расширению возможностей реляционных систем абстрактными типами данных (соответствующими возможностями обладают, например, системы семейства Ingres/Postgres). В нашем примере мы имеем дело с данными трех типов: строки символов, целые числа и "деньги".

Домен

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

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

Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми только в том случае, когда они относятся к одному домену. В нашем примере значения доменов "Номера пропусков" и "Номера групп" относятся к типу целых чисел, но не являются сравнимыми. Заметим, что в большинстве реляционных СУБД понятие домена не используется, хотя в Oracle V.7 оно уже поддерживается.