Понятие базы данных

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

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

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

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

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

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

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

     Стандартизованная объектно-ориентированной модель описана  в рекоменда¬циях стандарта ODMG-93 (Object Database Management Group — группа управ¬ления  объектно-ориентированными базами данных). Реализовать в полном объе¬ме  рекомендации ODMG-93 пока не удается. Для иллюстрации ключевых идей рассмотрим несколько упрощенную модель объектно-ориентированной БД.

     Структура объектно-ориентированной БД графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стандартным типом (например, строковым — string) или типом, конструируемым пользователем (определяется как class).

     Значением свойства типа string является строка символов. Значение свойства типа class есть объект, являющийся экземпляром соответствующего класса. Каждый объект-экземпляр класса считается потомком объекта, в котором он определен как свойство. Объект-экземпляр класса принадлежит своему классу и имеет одного родителя. Родовые отношения в БД образуют связную иерархию объектов.

     Логическая  структура объектно-ориентированной  БД внешне похожа на структуру иерархической  БД. Основное отличие между ними состоит в методах манипулирования данными.

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

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

     Рассмотрим  кратко понятия инкапсуляции, наследования и полиморфизма применительно к объектно-ориентированной модели БД.

     Инкапсуляция  ограничивает область видимости имени свойства пределами того объекта, в котором оно определено.

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

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

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

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

     В 90-е годы существовали экспериментальные прототипы объектно-ориентированных систем управления базами данных. В настоящее время такие системы получили широкое распространение, в частности, к ним относятся следующие СУБД: РОЕТ (РОЕТ Software), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (Ardent Software), ODB-Jupiter (научно-производственный центр «Интелтек Плюс»), а также Iris, Orion и Postgres. 

     5 Проектирование баз данных 

     Проектирование  БД – один из начальных и основных этапов создания новой автоматизированной системы. Результат проектирования - физическая модель БД, которая описывает  ее в терминах языка, принятого в конкретной СУБД. В свою очередь, процесс проектирования делится на следующие этапы:

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

     2. Преобразование связей многие-ко-многим.

     3. Нормализация логической модели  БД.

     4. Построение физической модели: определение имен, типов и/или доменов атрибутов.

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

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

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

     2. Сбор документов. Если к моменту начала разработки имеются документы, которые поступают в ИС или должны в ней рассчитываться, то они должны быть обязательно собраны.

     3. Интервьюирование необходимый метод сбора информации. Применяется для уточнения сведений, полученных на основе анкетирования и собранных документов. Интервьюирование является наиболее важной и сложной задачей, так как должно привести к выявлению всех «мелочей», без которых проектирование БД невозможно.

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

     Второй  этап - преобразование связей многие-ко-многим. Данное преобразование осуществляется по следующему алгоритму:

     1. Создается новая сущность (сущность-ассоциация).

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

     3. Связь многие-ко-многим удаляется.

     Третий  этап - нормализация БД.

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

     В теории реляционных БД обычно выделяется следующая последовательность нормальных форм:

     - первая нормальная форма (1NF);

     - вторая нормальная форма (2NF);

     - третья нормальная форма (3NF);

     - нормальная форма Бойса-Кодда  (BCNF);

     - четвертая нормальная форма (4NF);

     - пятая нормальная форма, или  нормальная форма проекции-соединения (5NF или PJ/NF).

     Основные  свойства нормальных форм:

     - каждая следующая нормальная  форма в некотором смысле лучше  предыдущей;

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

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

     Предварительно  дадим несколько определений.

     1. Функциональная зависимость. 

     В отношении R атрибут Y функционально  зависит от атрибута X (X и Y могут  быть составными) в том и только в том случае, если каждому значению X соответствует в точности одно значение Y.

     2. Полная функциональная зависимость 

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

     3. Транзитивная функциональная зависимость

     Функциональная  зависимость атрибута Y от атрибута X в отношении R называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости Z от Х и атрибута Y от Z и отсутствует функциональная зависимость атрибута X от Z.