Применение объектно-ориентированного подхода при проектировании информационной системы (Фундаментальные свойства отношений)

Содержание:

ВВЕДЕНИЕ

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

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

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

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

Изначально использовали в качестве внешней памяти: магнитные ленты и барабаны. Затем появились магнитные диски.

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

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

Во второй главе показаны основные особенности реляционных баз данных и способы проектирования этих баз.

В третьей главе рассмотрены основные особенности объектно-ориентированных баз данных.

ГЛАВА 1. БАЗЫ ДАННЫХ И СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ

1.1 В общем о базах данных и системах управления базами данных

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

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

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

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

1. сформулировать запрос к самой базе на близком или точнее понятном пользователям языке. Такие языки называются языками запросов к базам данных.

2. совместная работа нескольких пользователей с базой данных.

1.2 Ранние подходы к организации БД

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

Назовем три причны, по которым это необходимо сделать:

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

2. в ранних системах использовались методы, которые лежат в основе реляционных систем;

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

Рассмотрим только три типа таких систем, а именно, систем, основанных на инвертированных списках, иерархических и сетевых [4].

База данных основанная на инвертированных списках.

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

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

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

Теперь об иерархической базе данных.

Она состоит из упорядоченного набора деревьев.

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

На рисунке 1 изображен наглядный пример схемы иерархической базы данных.

Рисунок 1. Схема иерархической базы данных

Здесь Отдел - это предок Начальника и Сотрудников, а Начальник и Сотрудники – это потомки Отдела. Между типами записей поддерживаются связи.

Согласно схеме на рисунке 1 можно показать пример такой базы данных. Такой пример приведен на рисунке 2.

Рисунок 2. Пример иерархической базы данных

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

У этих баз данных имеется и некоторые правила, например ни один потомок без родителя не существует.

Наконец перейдем к сетевой базе данных.

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

Пример схемы сетевой базы данных показан на рисунке 3.

Рисунок 3. Пример схемы сетевой базы данных

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

Сильные места:

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

Недостатки:

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

ГЛАВА 2. РЕЛЯЦИОННАЯ БАЗА ДАННЫХ

Приступим к рассмотрению реляционных БД и СУБД. В настоящее время данных подход является самым распространенным.

К достоинствам реляционного подхода относится [3]:

• простота моделирования;
• имеется достаточно мощный математический аппарат;
• простое манипулирование данными без знания физической организации баз данных.

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

2.1 Общие понятия реляционного подхода к организации БД

К основным понятиям реляционных БД можно отнести домен, тип данных, первичный ключ, кортеж, атрибут и отношение [7].

Покажем смысл всех этих понятий. для примера возьмем отношение СОТРУДНИКИ, изображенное на рисунке 4.

Данное отношение содержит информацию о сотрудниках любой организации.

Рисунок 4. Смысл основных понятий реляционных баз данных

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

В нашем примере мы имеем дело с данными трех типов: целые числа и деньги, а также строки символов.

Под доменом понимается допустимое потенциальное, ограниченное подмножество значений данного типа. [9].

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

Следует отметить, что данные являются сравнимыми, если они относятся к одному домену. У нас домены "Номера групп" и "Номера пропусков" не являются сравнимыми, хоть и являются целыми числами.

Под схемой отношения понимается именованное множество пар {имя атрибута, имя домена}[8]. Мощностью множества называется степень схем отношения. Отношение СОТРУДНИКИ имеет степень равную четырем.

Схемой базы данных (в структурном смысле) считают набор именованных схем отношений.

Под кортежем понимается набор именованных значений заданного типа [16].

Под отношением подразумевается множество кортежей из одной схемы отношения. Чтобы не путаться, разделяют "отношение-схему" и "отношение-экземпляр". Схему отношения также иногда называют его заголовком, а отношение, состоящее из кортежей - телом. [8]

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

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

Таким образом, реляционная БД - это набор отношений, имена которых совпадают с именами схем отношений в схеме базы данных [8].

В теории реляционных баз данных все понятия определяются абсолютно точно.

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

Рассмотрим некоторые важные свойства отношений, которые следуют из приведенных ранее определений [3]:

• отсутствие кортежей-дубликатов;
• отсутствие упорядоченности кортежей;
• отсутствие упорядоченности атрибутов;
• атомарность значений атрибутов.

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

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

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

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

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

Рисунок 5. Пример ненормализованного отношения

Пример нормализованного отношения приведен на рисунке 6.

Рисунок 6. Нормализованный вариант отношения

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

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

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

• структурной части;
• манипуляционной части;
• целостной части.

В структурной части говорится, что в реляционных БД единственной структурой является нормализованное n-арное отношение.

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

В целостной части говорится о двух базовых требований целостности реляционной СУБД:

1. требование целостности сущностей. Любой кортеж отношения отличим от любого другого кортежа этого отношения, или по другому любое отношение должно обладать первичным ключом [16].
2. требование целостности по ссылкам. Данное требование является несколько более сложным. Очевидно, что при соблюдении нормализованности отношений сложные сущности представляются в виде нескольких кортежей отношений [16].

Представим, что нам требуется задать в реляционной базе данных сущность ОТДЕЛ с атрибутами О_НОМЕР (номер отдела), О_КОЛ (количество сотрудников) и О_СОТР (сотрудники отдела). Для каждого сотрудника нужно хранить свой номер НОМЕР_СОТР (номер сотрудника), ИМЯ_СОТР (имя сотрудника) и ЗАРП_СОТР (заработная плата сотрудника). При проектировании базы данных выделяем два отношения: ОТДЕЛЫ (О_НОМЕР, О_КОЛ) (первичный ключ - О_НОМЕР) и СОТРУДНИКИ (НОМЕР_СОТР, ИМЯ_СОТР, ЗАРП_СОТР, СОТР_ОТД_НОМ) (первичный ключ - НОМЕР_СОТР).

Атрибут СОТР_ОТД_НОМ появляется в отношении СОТРУДНИКИ лишь для того, чтобы иметь возможность восстановить при необходимости полную сущность ОТДЕЛ. Значение атрибута СОТР_ОТД_НОМ в любом кортеже отношения СОТРУДНИКИ должно соответствовать значению атрибута О_НОМ в некотором кортеже отношения ОТДЕЛЫ. Атрибут такого рода называется внешним ключом, поскольку его значения задают значения первичного ключа.

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

Для поддержания целостности по ссылкам используют три подхода:

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

2.4 Понятие нормализации

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

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

В теории реляционных баз данных выделяют следующие нормальные формы [9]:

• первая нормальная форма;
• вторая нормальная форма;
• третья нормальная форма;
• нормальная форма Бойса-Кодда;
• четвертая нормальная форма;
• пятая нормальная форма, или нормальная форма проекции-соединения.

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

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

Рассмотрим понятие второй нормальной формы на следующем примере схемы отношения:

СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ

(НОМЕР_СОТР, ЗАРП_СОТР, О_НОМЕР, НОМЕР_ПРОЕКТА, СОТР_ЗАДАН)

Первичный ключ:

НОМЕР_СОТР, НОМЕР_ПРОЕКТА

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

НОМЕР_СОТР -> ЗАРП_СОТР

НОМЕР_СОТР -> О_НОМЕР

О_НОМЕР -> ЗАРП_СОТР

НОМЕР_СОТР, НОМЕР_ПРОЕКТА -> СОТР_ЗАДАН

Как видно, хотя первичным ключом является составной атрибут НОМЕР_СОТР, НОМЕР_ПРОЕКТА, атрибуты ЗАРП_СОТР и О_НОМЕР зависят от части первичного ключа, атрибута НОМЕР_СОТР. Из-за чего мы не можем вставить в отношение СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ кортеж, описывающий сотрудника, невыполняющего никакого проекта, так как первичный ключ не может содержать неопределенное значение. Удалять кортеж тоже нельзя, так как мы не только разрушим связь данного сотрудника с данным проектом, но и утратим информацию о том, что он работает в некотором отделе. Таким образом, при переводе сотрудника в другой отдел нам необходимо модифицировать все кортежи, описывающие этого сотрудника, иначе получим непредсказуемый результат.

Путем нормализации можно избавиться от такой ситуации.

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

Проведем следующую декомпозицию отношения СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ в два отношения СОТРУДНИКИ-ОТДЕЛЫ и СОТРУДНИКИ-ПРОЕКТЫ:

СОТРУДНИКИ-ОТДЕЛЫ (НОМЕР_СОТР, ЗАРП_СОТР, О_НОМЕР)

Первичный ключ:

НОМЕР_СОТР

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

НОМЕР_СОТР -> ЗАРП_СОТР

НОМЕР_СОТР -> О_НОМЕР

О_НОМЕР -> ЗАРП_СОТР

СОТРУДНИКИ-ПРОЕКТЫ (НОМЕР_СОТР, НОМЕР_ПРОЕКТА, СОТР_ЗАДАН)

Первичный ключ:

НОМЕР_СОТР, НОМЕР_ПРОЕКТА

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

НОМЕР_СОТР, НОМЕР_ПРОЕКТА -> CОТР_ЗАДАН

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

Раскроем понятие третьей нормальной формы, воспользовавшись тем же отношением СОТРУДНИКИ-ОТДЕЛЫ, находящимся уже во второй нормальной форме. Заметим, что функциональная зависимость НОМЕР_СОТР -> ЗАРП_СОТР является транзитивной; она является следствием функциональных зависимостей НОМЕР_СОТР -> О_НОМЕР и О_НОМЕР -> ЗАРП_СОТР. Другими словами, заработная плата сотрудника характеризует не сотрудника, а отдел, в котором он работает.

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

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

Можно произвести декомпозицию отношения СОТРУДНИКИ-ОТДЕЛЫ в два отношения СОТРУДНИКИ и ОТДЕЛЫ:

СОТРУДНИКИ (НОМЕР_СОТР, О_НОМЕР)

Первичный ключ:

НОМЕР_СОТР

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

НОМЕР_СОТР -> О_НОМЕР

ОТДЕЛЫ (О_НОМЕР, ЗАРП_СОТР)

Первичный ключ:

О_НОМЕР

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

О_НОМЕР -> ЗАРП_СОТР

Каждое из этих двух отношений находится в третьей нормальной форме.

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

Дальнейшее рассмотрение примера схемы отношения:

СОТРУДНИКИ-ПРОЕКТЫ (НОМЕР_СОТР, СОТР_ИМЯ, НОМЕР_ПРОЕКТА, СОТР_ЗАДАН)

Возможные ключи:

НОМЕР_СОТР, НОМЕР_ПРОЕКТА

СОТР_ИМЯ, НОМЕР_ПРОЕКТА

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

НОМЕР_СОТР -> CОТР_ИМЯ

НОМЕР_СОТР -> НОМЕР_ПРОЕКТА

СОТР_ИМЯ -> CОТР_НОМЕР

СОТР_ИМЯ -> НОМЕР_ПРОЕКТА

НОМЕР_СОТР, НОМЕР_ПРОЕКТА -> CОТР_ЗАДАН

СОТР_ИМЯ, НОМЕР_ПРОЕКТА -> CОТР_ЗАДАН

Здесь предполагаем, что сотрудник полностью определяется своим номером и именем.

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

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

И тогда отношение R находится в нормальной форме Бойса-Кодда в том и только в том случае, если каждый детерминант является возможным ключом [8].

Данное требование не выполняется для отношения СОТРУДНИКИ-ПРОЕКТЫ. Разложим его на следующие отношения СОТРУДНИКИ и СОТРУДНИКИ-ПРОЕКТЫ:

СОТРУДНИКИ (НОМЕР_СОТР, СОТР_ИМЯ)

Возможные ключи:

НОМЕР_СОТР

СОТР_ИМЯ

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

НОМЕР_СОТР -> CОТР_ИМЯ

СОТР_ИМЯ -> НОМЕР_СОТР

СОТРУДНИКИ-ПРОЕКТЫ (НОМЕР_СОТР, НОМЕР_ПРОЕКТА, СОТР_ЗАДАН)

Возможный ключ:

НОМЕР_СОТР, НОМЕР_ПРОЕКТА

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

НОМЕР_СОТР, НОМЕР_ПРОЕКТА -> CОТР_ЗАДАН

Продолжим нашу нормализацию и рассмотрим пример следующей схемы отношения:

ПРОЕКТЫ (НОМЕР_ПРОЕКТА, СОТР_ПРОЕКТА, ЗАДАН_ПРОЕКТА)

Отношение ПРОЕКТЫ содержит номера проектов, список сотрудников для выполнения каждого проекта, и список заданий проектов. Сотрудники могут выполнять несколько проектов, при этом задания могут быть одинаковыми для разных проектов.

Сотрудники, участвующие в проектах, и их задания связываются между собой в некоторый проект при помощи кортежа отношений. Единственным ключом отношения является составной атрибут НОМЕР_ПРОЕКТА, СОТР_ПРОЕКТА, ЗАДАН_ПРОЕКТА, других детерминантов также нет. Значит, наше отношение находится в нормальной форме Бойса-Кодда. При этом, когда некоторый сотрудник захочет присоединиться к данному проекту, тогда придется вставлять в отношение ПРОЕКТЫ столько кортежей, сколько заданий предусмотрено в этом проекте.

Определим понятие многозначной зависимости, которая существует в отношении R (A, B, C) и имеет вид R.A -> -> R.B при этом это возможно лишь в том случае, если множество значений B, соответствующее паре значений A и C, зависит только от A и не зависит от С.

В отношении ПРОЕКТЫ существуют следующие две многозначные зависимости:

НОМЕР_ПРОЕКТА -> -> СОТР_ПРОЕКТА

НОМЕР_ПРОЕКТА -> -> ЗАДАН_ПРОЕКТА

Легко показать, что в общем случае в отношении R (A, B, C) существует многозначная зависимость R.A -> -> R.B в том и только в том случае, когда существует многозначная зависимость R.A -> -> R.C.

И дальнейшая нормализация отношения использует теорему Фейджина: Отношение R (A, B, C) можно спроецировать без потерь в отношения R1(A, B) и R2(A, C) в том и только в том случае, когда существует A->->B|C [8].

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

Четвертая нормальная форма. Отношение R находится в четвертой нормальной форме лишь в том случае, если в многозначной зависимости A -> -> B все остальные атрибуты R функционально зависят от A [16].

Разобъем отношение ПРОЕКТЫ на два отношения ПРОЕКТЫ-СОТРУДНИКИ и ПРОЕКТЫ-ЗАДАНИЯ:

ПРОЕКТЫ-СОТРУДНИКИ (НОМЕР_ПРОЕКТА, СОТР_ПРОЕКТА)

ПРОЕКТЫ-ЗАДАНИЯ (НОМЕР_ПРОЕКТА, ЗАДАН_ПРОЕКТА)

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

Пятая нормальная форма является последней нормальной формой, которую можно получить путем декомпозиции. Ее условия достаточно нетривиальны, и на практике пятая нормальная форма не используется [9].

ГЛАВА 3. ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД ПРИ ПРОЕКТИРОВАНИИ ИНФОРМАЦИОННОЙ СИСТЕМЫ

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

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

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

Как отмечается в Манифесте группы ведущих ученых, которые занимаются наработками объектно-ориентированных баз данных, современная ситуация в этой области напоминает ситуацию с реляционными БД в середине 1970-х [1].

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

Постараемся раскрыть наиболее важные аспекты этих баз данных.

3.1 Общие понятия объектно-ориентированного подхода

В основе объектно-ориентированного подхода лежат следующие концептуальные составляющие [11]:

• объектов;
• классов;
• методов;
• атрибутов;
• наследования классов;
• иерархии классов.

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

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

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

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

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

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

Проектирование, разработка и сопровождение объектно-ориентированных баз данных является процессом, объединяющим структурную и поведенческую части проектирования [10].

В объектно-ориентированных базах данных имеется три аспекта, которых нет в традиционном понятии базы данных [12]:

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

3.2 Объектно-ориентированные модели данных

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

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

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

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

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

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

Рассмотрим особенности используемой в объектно-ориентированной системе управления базами данных O2 модели данных [11].

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

В О2 организовать данные можно двумя способами: используя классы и типы. Каждому классу сопоставляется тип, на основе которого описывается структура класса. Все типы создаются рекурсивно, используя атомарные типы и ранее определенные типы и классы, с использованием конструкторов.

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

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

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

Создание любого метода в O2 проходит в два этапа:

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

В O2 поддерживается множественное наследование классов. В подклассе допускается добавление и переопределение атрибутов и методов. Неоднозначности такого наследования исправляются путем переименования или путем явного указания источника наследования.

Из всего выше сказанного можно понять, что в О2 также поддерживается и такой стандартный класс как "Оbject", который является корнем всей решетки классов в данной системе. Таким образом, любой создаваемый класс неявно наследуется от класса "Object" и обладает всеми его методами (например: "is_same", "is_value_equal" и т.д.).

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

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

СПИСОК ЛИТЕРАТУРЫ

1. Гради Буч; Роберт А. Максимчук; Майкл У. Энгл; Бобби Дж. Янг; Джим Коналлен. Объектно-ориентированный анализ и проектирование с примерами приложений (UML 2). 3-е издание. - : «Вильямс» 2008г, 720 стр.
2. Иан Грэхем. Объектно-ориентированные методы. Принципы и практика (3-е издание). – М: «Вильямс» 2004г, 880 стр.
3. Кириллов В. В.; Громов Г. Ю. Введение в реляционные базы данных. – М: «BHV» 2009г, 464 стр.
4. Крёнке.Д. Теория и практика построения баз данных, 8-е изд. – М : «Питер» 2003г, 800 стр.
5. Кузнецов С.Д. Базы данных. Модели и языки. –М: «Бином» 2008г, 720 стр.
6. Галина Мирошниченко. Реляционные базы данных: практические приемы оптимальных решений. – М: «БХВ-Петербург» 2005г,- 400 с.
7. Райордан Р. Основы реляционных баз данных. Пер, с англ. - М.: Издательско-торговый дом "Русская Редакция", 2001. - 384 с.
8. Туманов.В.Е Основы проектирования реляционных баз данных. – М: «Бином.ЛБЗ» 2007г,-420 стр.
9. Уидом Дж. Ульман Д. Основы реляционных баз данных. - М: «Лори».2006г, -374 стр.
10. Харрингтон. Д. Проектирование объектно-ориентированных баз данных. - М: ДМК ПРЕСС, 2001г,- 272 стр.
11. «Объектно-ориентированные базы данных - основные концепции, организация и управление: краткий обзор» Автор: Кузнецов Сергей http://www.citforum.ru/database/articles/art_24.shtml#lit
12. «Объектно-ориентированные базы данных: среда разработки программ плюс хранилище объектов» Авторы: Андреев А.М.; Березкин Д.В.; Кантонистов Ю.А http://inteltec.ru/publish/articles/objtech/oodbms_o.shtml
13. «Реляционные базы данных» Автор: Пит Лошин 04.02.2001г. http://www.osp.ru/cw/2001/05/9215/
14. «Основы проектирования реляционных баз данных» Автор: Кириллов.В.В. http://cs.ifmo.ru/education/documentation/dbguide/index.shtml
15. «Реляционная база данных и её связи между таблицами» http://shkola.lv/index.php?mode=cht&chtid=511
16. «Базы данных. Вводный курс» Автор: Кузнецов Сергей. http://www.citforum.ru/database/advanced_intro/

Приложение 1

Глоссарий:

Понятие (термин)	определение	источник
База данных (БД)	централизованное хранилище данных, обеспечивающее хранение, доступ, первичную обработку и поиск информации.	http://php-myadmin.ru/glossary/
Система управления базой данных (СУБД)	СУБД обеспечивает поддержку создания баз данных, централизованного управления и организации доступа к ним различных пользователей.	http://www.znannya.org/?view=PHP_SUBD_main
Объектно-ориентированная БД	база данных, в которой данные оформлены в виде моделей объектов, включающих прикладные программы, которые управляются внешними событиями.	http://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5_%D0%B1%D0%B0%D0%B7%D1%8B_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
Локальные СУБД	это СУБД, работающие на одном компьютере. К таким относятся dBase, FoxPro, Microsoft Access, Paradox и т.д.	http://www.alblog.tu2.ru/?p=436
Сетевые СУБД	это СУБД, позволяющие нескольким компьютерам использовать одну и ту же БД с помощью технологии клиент-сервер. Примером таких СУБД являются InterBase, Oracle, Microsoft SQL Server и т.д.	http://www.alblog.tu2.ru/?p=436
Схема БД (в структурном смысле)	это набор именованных схем отношений.	http://lib.profi.net.ua/doc/databases/osbd/glava_16.htm
Реляционная база данных	база данных, основанная на реляционной модели данных	http://lib.profi.net.ua/doc/databases/osbd/glava_16.htm
кортеж	это набор именованных значений заданного типа.	http://lib.profi.net.ua/doc/databases/osbd/glava_16.htm
язык базы данных	специальный язык, предназначенный для работы с базами данных.	http://www.citforum.ru/database/osbd/glava_23.shtml#_2_3_1_3
Индекс	объект базы данных, создаваемый с целью повышения производительности выполнения запросов.	http://php-myadmin.ru/glossary/
Поле	строка в таблице с данными. Синоним термина реляционной базы данных "кортеж".	http://php-myadmin.ru/glossary/
Ключ	объект базы данных, создаваемый с целью повышения производительности выполнения запросов.	http://php-myadmin.ru/glossary/
Словарь данных	отведенное место в базе данных, которое используется для хранения информации о самой базе данных. Словарь данных может содержать информацию: об архитектуре базы данных, о хранимых процедурах, о пользовательских привилегиях, и др.	http://php-myadmin.ru/glossary/
Столбец	это часть данных определённого типа, единого для всех полей таблицы. Синоним термина реляционной базы данных "атрибут".	http://php-myadmin.ru/glossary/
Строка	строка в таблице с данными. Синоним термина реляционной базы данных "кортеж".	http://php-myadmin.ru/glossary/
Таблица	набор элементов данных организованных, определённых и сохранённых в виде горизонтальных строк и вертикальных столбцов, где каждый элемент может быть идентифицирован по его имени, ключу или позиции по отношению к другим элементам.	http://php-myadmin.ru/glossary/
Сущность	это реальный или представляемый объект, информация о котором должна сохраняться и быть доступной.	http://www.intuit.ru/department/database/rdbintro/9/2.html
Связь	это графически изображаемая ассоциация, устанавливаемая между двумя типами сущностей.	http://www.intuit.ru/department/database/rdbintro/9/2.html
Атрибут сущности	Атрибутом сущности является любая деталь, которая служит для уточнения, идентификации, классификации, числовой характеристики или выражения состояния сущности.	http://www.intuit.ru/department/database/rdbintro/9/2.html
свойство	это однозначный факт о некоторой сущности, то есть данные о сущности, которые нужно сохранить	http://works.tarefer.ru/69/100747/index.html
Первая нормальная форма	Говорят, что сущность находится в первой нормальной форме, когда все её атрибуты имеют единственное значение.	http://works.tarefer.ru/69/100747/index.html
Вторая нормальная форма	Говорят, что сущность находится во второй нормальной форме, если она уже находится в первой нормальной форме, и каждый неидентифицирующий атрибут зависит от всего уникального идентификатора сущности. Если некий атрибут не зависит полностью от уникального идентификатора сущности, значит, он внесён ошибочно и должен быть удалён.	http://works.tarefer.ru/69/100747/index.html
Третья нормальная форма	Третья нормальная форма требует, во-первых, соответствия второй (а та - первой). А во-вторых - чтобы значение любого поля, не входящего впервичный ключ не зависело от других полей, не входящих в первичный ключ.	http://www.realcoding.net/articles/urok-3-nekotorye-pravila-postroeniya-baz-dannykh.html
нормальная форма Бойса-Кодда	Отношение R находится в нормальной форме Бойса-Кодда (BCNF) в том и только в том случае, если каждый детерминант является возможным ключом.	http://www.citforum.ru/database/osbd/glava_23.shtml#_2_3_1_3
Рекурсивная связь	Связь называется рекурсивной, когда каждая сущность, участвующая в связи, описывает другую и описывается ею.	http://works.tarefer.ru/69/100747/index.html
Степень	показывает, сколько экземпляров описываемой сущности должны описывать один экземпляр описываемой сущности. Степень выражается с помощью разных значений взаимосвязей	http://works.tarefer.ru/69/100747/index.html
Отношение	это множество кортежей, соответствующих одной схеме отношения.	http://lib.profi.net.ua/doc/databases/osbd/glava_16.htm
Ссылочная целостность	это ограничение базы данных, гарантирующее, что ссылки между данными являются действительно правомерными и неповрежденными.	http://www.cyberguru.ru/database/database-theory/reference-integrity.html
Домен	В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных.	http://lib.profi.net.ua/doc/databases/osbd/glava_16.htm
элемент домена	Если вычисление произвольного логического выражения, применяемого к элементу типа данных дает результат "истина", то элемент данных является элементом домена.	http://lib.profi.net.ua/doc/databases/osbd/glava_16.htm
Схема отношения	это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)}.	http://lib.profi.net.ua/doc/databases/osbd/glava_16.htm
Первичный ключ	минимальный набор полей, уникально идентифицирующий запись в таблице.	http://www.znannya.org/?view=PHP_SUBD_main
Альтернативные ключи	После выбора первичного ключа из набора потенциальных ключей, оставшиеся ключи называются альтенативными.	http://www.realcoding.net/articles/urok-3-nekotorye-pravila-postroeniya-baz-dannykh.html
файл	это именованная область внешней памяти, в которую можно записывать и из которой можно считывать данные.	http://www.citforum.ru/database/osbd/glava_6.shtml
Транзакция	это последовательность операций над БД, рассматриваемых СУБД как единое целое.	http://www.citforum.ru/database/osbd/glava_6.shtml
Журнал	это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью, в которую поступают записи обо всех изменениях основной части БД.	http://www.citforum.ru/database/osbd/glava_23.shtml#_2_3_1_3
кардинальное число	показывает, сколько экземпляров описываемой сущности должны описывать один экземпляр описываемой сущности.	http://works.tarefer.ru/69/100747/index.html
объектная модель	модель, в которой данные представляются в виде набора объектов и классов, связанных между собой родственными отношениями, а работа с объектами осуществляется с помощью скрытых в них методов.	http://www.znannya.org/?view=PHP_SUBD_main
взаимосвязь "один" к "одному"	Вид взаимосвязи один к одному означает, что каждая запись одного объекта БД будет указывать на единственную запись другого объекта.	http://www.alblog.tu2.ru/?p=436
взаимосвязь "один" ко "многим"	Один ко многим означает, что одной записи объекта БД будет соответствовать несколько записей других объектов.	http://www.alblog.tu2.ru/?p=436
взаимосвязь "много" к "одному"	Много к одному означает, что нескольким записям объектов БД будет соответствовать одна запись другого объекта.	http://www.alblog.tu2.ru/?p=436
взаимосвязь "много" ко "многим"	Много ко многим устанавливается между двумя типами объектов БД.	http://www.alblog.tu2.ru/?p=436
сериализация	Под сериализаций параллельно выполняющихся транзакций понимается такой порядок планирования их работы, при котором суммарный эффект смеси транзакций эквивалентен эффекту их некоторого последовательного выполнения.	http://www.citforum.ru/database/osbd/glava_6.shtml
Сериальный план	это такой план, который приводит к сериализации транзакций.	http://www.citforum.ru/database/osbd/glava_6.shtml
SQL (Structured Query Language)	Стандартный язык наиболее распространенных в настоящее время реляционных СУБД	http://www.citforum.ru/database/osbd/glava_23.shtml#_2_3_1_3
Детерминант	любой атрибут, от которого полностью функционально зависит некоторый другой атрибут.	http://www.citforum.ru/database/osbd/glava_23.shtml#_2_3_1_3
Метод	программный код, привязанный к конкретному классу и применимый к объектам этого класса.	http://www.citforum.ru/database/osbd/glava_112.shtml
Публичный метод	метод доступными из объектов других классов	http://www.citforum.ru/database/osbd/glava_112.shtml
класс	это тип, описывающий устройство объектов. Понятие «класс» подразумевает некоторое поведение и способ представления.	http://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5
Приватный метод	доступными только внутри данного класса	http://www.citforum.ru/database/osbd/glava_112.shtml
наследование	позволяет описать новый класс на основе уже существующего (родительского), при этом свойства и функциональность родительского класса заимствуются новым классом.	http://ru.wikipedia.org/wiki/%D0%9D%D0%B0%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%28%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%29
полиморфизм	взаимозаменяемость объектов с одинаковым интерфейсом.	http://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%BB%D0%B8%D0%BC%D0%BE%D1%80%D1%84%D0%B8%D0%B7%D0%BC_%28%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%29
объект	Понятие «объект» подразумевает нечто, что обладает определённым поведением и способом представления.	http://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5
Нормальная форма БД	формальное свойство отношения, которое характеризует степень избыточности хранимых данных и возможные проблемы.	http://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%BB%D1%8F%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D1%8B%D0%B5_%D0%B1%D0%B0%D0%B7%D1%8B_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
Нормалиация	Целью нормализации является устранение недостатков структуры базы данных, приводящих к вредной избыточности в данных, которая в свою очередь потенциально приводит к различным аномалиям и нарушениям целостности данных.	http://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%BB%D1%8F%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D1%8B%D0%B5_%D0%B1%D0%B0%D0%B7%D1%8B_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
инкапсуляция	свойство языка программирования, позволяющее объединить данные и код в объект и скрыть реализацию объекта от пользователя.	http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D0%BA%D0%B0%D0%BF%D1%81%D1%83%D0%BB%D1%8F%D1%86%D0%B8%D1%8F_%28%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%29

Приложение 2

Ментальная карта: