Концептуальная модель наиболее полно отвечает потребностям проектирования баз знаний и построена на ряде принципов, которые мы сейчас рассмотрим. Есть две большие области понятий в концептуальной модели. Обе они построены по принципу иерархического дерева. Первая область – это дерево типов данных, вторая – дерево данных. Дерево типов описывает структуру данных дерева данных, поэтому без дерева типов нет никакой логической целостности дерева данных. Для начала, рассмотрим простой пример с телевизионной камерой. Отраженный свет попадает в объектив камеры, там он разлагается на три составляющие: синий, красный, зеленый. Записывая уровень освещенности трех составляющих света 25 раз в секунду, мы можем составить представление об освещенности и отражающей способности предметов, которые мы снимаем. Теперь дадим основные определения.

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

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

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

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

                Объект – совокупность типов и свойств, объединенных в один тип, способный описать объект реального мира. В нашем примере один тип достаточен для описания объекта, снимаемого на камеру, но бывают случаи, когда одного типа недостаточно, или уровень упрощения слишком высок, чтобы можно было составить простую модель. Например, объект машина состоит из типов: кузов, рама, мотор, колеса и т.д. Эти типы, в свою очередь, тоже являются объектами, которые состоят из типов, например для колеса: обод, камера, покрышка и т.д. Для камеры: оболочка, ниппель, давление воздуха и т.д. Можно бесконечно углубляться в детализацию, но, как правило, это не требуется. Рассмотрим разные точки зрения пользователей на наши типы, в зависимости от состояния технологического процесса производства и продажи машины. Человек, который собирает колесо, рассматривает его как объект, состоящий из типов: оболочка, ниппель, давление воздуха. Он собрал колесо и передал его на главный конвейер. Далее колесо рассматривается как тип, входящий в состав объекта рама. На последней стадии сборки, нам уже не важно иметь в поле зрения свойство колесо, практически, мы потеряли его из видимости. Далее, мы рассматриваем тип рама, входящий как свойство в объект машина. Человек, который пришел покупать машину, может рассматривать его то, как объект то, как тип, входящий как свойство в объект материальное состояние и т.д. Из этих рассуждений видно, что концептуальная модель очень гибка и самодостаточна для описания внешнего мира. Мы можем двигаться от простого к сложному, описывая все, что входит в технологический процесс.

                Связь – это свойство типа или свойства типа, характеризующая взаимосвязь типов в дереве данных или способ изменения значения свойства объектного типа соответственно. Бывают три типа связей: включение в дереве данных, вставка из другого типа значения свойства типа и ссылка на экземпляр типа в дереве данных. Включение позволяет строить дерево данных. Вот пример. Объект офис состоит из свойств объектного типа – комнаты. Мы не можем описать любой офис прямо в типе офис, т.к. заранее неизвестно, сколько комнат в нем будет, поэтому мы описываем связь типа офис с типом комната. Теперь создав экземпляр типа офис, мы можем добавить к этому узлу дерева данных нужное количество ветвей типа комната. Или, например, накладная состоит из шапки и списка товаров. Мы можем рассматривать шапку как узел дерева данных, а список товаров, как ветви дерева данных, исходящие из этого узла. Вставка значения свойства типа из другого типа – это способ редактирования свойства типа, при котором значение одного из свойств типа вставляется из экземпляра свойства другого типа. Например, мы можем описать связь цвета панели инструментов в программе, которое будет редактироваться из списка цветов операционной системы. При этом связь устанавливается только на время редактирования, по завершении которого связь полностью разрывается. Ссылка характерна тем, что будучи один раз установлена, не разрывается после редактирования. Это похоже на вычисляемое свойство таблицы базы данных. Если Вы измените тип, на который установлена ссылка, то во всех экземплярах типов, где есть ссылка на этот тип будет произведено изменение.

                Наследование – это способ описания дерева типов. Вы можете описать тип литература, от которого наследовать типы: книга, журнал, статья. При этом поддерживается полиморфизм. Так, если в литературе есть свойство автор, произведя поиск по потомкам от литературы, Вы найдете все книги, журналы и статьи этого автора.

                Имея такие богатые возможности, концептуальная модель долгое время была не реализована. Мне удалось написать реализацию концептуального подхода. Авторами концептуальной модели были Смит и Смита – американские ученые, написавшие ряд статей в 1972 – 1976 годах, которые, по общему мнению, считались утопией. В сущности,  человек мыслит именно концептуально. Мы знаем, и какие характеристики есть у объекта, и значения этих характеристик. Мы знаем, что автобус и Жигули – это машины, а Жигули, Мерсы и Тойоты – это легковые автомобили. У нас в мозгах тоже есть дерево типов (наследование + описание свойств типа) и дерево данных (в сумку можно положить хлеб и огурцы).

Инфологическая модель данных "Сущность-связь"

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

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

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

Связь – ассоциирование двух или более сущностей.

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

                В концептуальной модели это соответствует включению.

На основе этих двух видов связей, Вы можете составить более сложные связи.

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

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

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

К.Дейт определяет три основные класса сущностей: стержневые, ассоциативные и характеристические, а также подкласс ассоциативных сущностей – обозначения.

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

Ассоциативная сущность (ассоциация) – это связь вида "многие-ко-многим". Например, товар в накладной – это связь с шапкой накладной и справочником наименований товара, справочником единиц измерения.

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

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

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

                Концептуальная модель и модель “Сущьность-связь” – это общие рассуждения о принципах построения модели данных, как бы рекомендации. Это то, о чем Вы можете думать при создании реальной базы данных. В современных условиях, Вам, скорее всего, придется использовать реляционную модель, на которой (как инструмент) Вы можете создать и концептуальную модель, и модель “Сущьность-связь”. Это связано с тем, что современные серверы базы данных используют именно реляционную модель и язык SQL для организации работы с данными.

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

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

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

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

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

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

Кардинальное число или мощность отношения – это число его кортежей. Кардинальное число отношения изменяется во времени в отличие от его степени. Практически кардинальное число – это количество строк в заголовке.

Итак:

Отношение – Таблица,
Кортеж – Строка,
Атрибут – Столбец, поле.

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

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

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

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

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

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

Теперь можно дать академические определения нормальных форм:

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

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

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

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

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

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

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

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

Язык SQL, быстрый старт.

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

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

Условные обозначения типов:      A – строка;

                           S – короткое целое;

I – целое число;

F – дробное число;

D – дата;

B – BLOB массив, например текст.

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

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

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

Список платежных поручений

Справочник организаций

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

Справочник организаций

Справочник банков

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

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

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

Список платежных поручений