В истории развития различных проектов реализации систем управления базами данных есть направление, которое существует и развивается в течение долгого времени по своему оригинальному пути. Это так называемые ПИК-образные СУБД. Архитектурные и системные решения, положенные в основу системы управления данными, оказались настолько удачны, что многие ведущие фирмы приобретали лицензии на их использование в своих разработках. В числе таких фирм можно назвать VMark Software, Ultimate, McDonnell Doauglas. Цель данной статьи - описать особенности проектирования приложений для подобных СУБД, которые позволяют достигать дополнительных преимуществ, по сравнению с использованием стандартных SQL-серверов.
Введение
Рассмотрение особенностей проектирования приложений в ПИК-образных СУБД мы проведем на примере СУБД uniVerse, которая была разработана фирмой VMark Software. Краткое описание этой СУБД было дано в [1].
Авторы считают, что знакомство с этим направлением развития СУБД будет полезно широкому кругу специалистов. В первом разделе статьи приведено краткое описание архитектуры uniVerse. Во втором разделе описаны особенности постреляционной модели данных uniVerse. В третьем - рассмотрены вопросы проектирования баз данных uniVerse на примере разработки автоматизированной информационной системы для управления торговым домом.
1. Архитектура uniVerse
UniVerse - это замкнутая среда, работающая под управлением операционной системы Unix. Во многом она подобна среде, предоставляемой стандартной Unix-оболочкой.
UniVerse имеет свой Командный процессор со словарем, включающий Unix-команды и многие команды управления данными, к которым нельзя обратиться из Unix. В этом смысле uniVerse аналогична Unix-оболочкам sh и csh. UniVerse имеет свою собственную процедуру входа и структуру счета.
Подобно Unix-оболочке, Командный процессор uniVerse интерпретирует командные строки, осуществляет некоторые подстановки в них и по каждой команде передает управление соответствующему процессу или утилите.
1.1. Структура uniVerse-системы
UniVerse состоит из:
· четырех процессоров интерактивных языков: Командного процессора uniVerse, PROVERB, Редактора и REVISE;
· процессора процедурного языка uniVerse-Basic;
· Basic-интерпретатора (далее просто Интерпретатора), который выполняет скомпилированные Basic-программы;
· набора утилит и процессов, которые вызывают языковые процессоры и Интерпретатор для выполнения их задач;
· RETRIEVE, процессора запросов базы данных и генератора отчетов;
· файлового обработчика (File Handler) uniVerse, управляющего системой uniVerse-файлов как набором Unix-файлов и Unix-директорий.
1.1.1. Командный процессор uniVerse
Командный процессор uniVerse принимает команды от терминала или из других источников и либо сам выполняет команду, либо вызывает для выполнения другой uniVerse- или Unix-процессор. Когда вы входите в среду uniVerse, Командный процессор находится под управлением вашего терминала.
1.1.2. Другие языковые процессоры uniVerse
PROVERB - процессор uniVerse, который интерпретирует сохраненные команды. Это хороший инструмент, позволяющий выполнять маленькие программы, использующие ресурсы uniVerse. Например, вы можете применить PROVERB для выполнения процедуры, печатающей ежедневные отчеты о продажах.
REVISE является словарно-управляемым процессором для ввода данных. С его помощью вы можете добавлять, изменять и удалять данные в файле. REVISE использует информацию, хранящуюся в словарях файлов, чтобы генерировать приглашения, специфицирующие вводимые в файл данные. Эта информация может также использоваться для форматного преобразования и контроля правильности ввода.
1.1.3. UniVerse-Basic
Процедурный язык uniVerse-Basic является более развитой версией языка Pick-Basic, который представляет собой расширение функциональных возможностей путем включения богатого набора операторов для манипулирования и обработки данных из базы данных. Исходные тексты Basic-программ можно создавать при помощи Unix- или uniVerse-Редактора и хранить в виде записей в uniVerse-файле. Компилятор Basic генерирует новую запись в другом файле, содержащем объектный код, который uniVerse-Интерпретатор может выполнять. Программы можно регистрировать также в локальном или системном каталоге, что дает возможность использовать их как команды или подпрограммы в других Basic-программах.
1.1.4. UniVerse-RETRIEVE, процессор запросов и генератор отчетов
RETRIEVE - один из самых мощных и универсальных процессоров управления базой данных в uniVerse. Он используется для обработки данных в базе данных и генерации отчетов. Все командные и языковые процессоры могут вызывать процессор RETRIEVE. RETRIEVE выполняет следующие функции:
· отбор записей для обработки их другими командами;
· форматирование отчетов;
· сортировку;
· действия с полями данных.
Для того чтобы обратиться к функциям RETRIEVE, можно воспользоваться командами Редактора, Командного процессора, REVISE, а также инструкциями и функциями Basic. RETRIEVE содержит программы, к которым обращаются Командный процессор, Редактор, REVISE и Интерпретатор для форматирования данных в соответствии с информацией словаря, а также для отбора записей из файла данных, удовлетворяющих определенным критериям.
1.2. Структура хранения данных
Данные хранятся в файлах специального вида, так называемых uniVerse-файлах. Логически каждый uniVerse-файл содержит в себе по крайней мере один файл данных и связанный с ним словарь файла. Файлы данных состоят из записей, в полях которых хранятся значения данных. Словари содержат записи, где находится информация о том, из чего состоят файлы данных, как обрабатывать и показывать их содержимое. На самом деле словари объединены в иерархическую систему. Существует главный словарь системы, который содержит описание словарей, соответствующих каждому счету пользователя, так называемых VOC-файлов.
VOC-файл пользовательского счета (здесь и далее термин счет используется как регистрационный счет пользователя в uniVerse или в Unix) содержит элементы, идентифицирующие сущности (глаголы, предложения, параграфы, файлы, ключевые слова, меню), которые вы можете использовать, находясь в своем uniVerse-счете. Командный процессор опирается на информацию VOC-файла, когда решает, какое действие следует предпринять для обработки очередной вводимой команду.
При создании нового uniVerse-счета в него копируется стандартный VOC-файл из счета системного администратора. Вы можете перекроить скопированный VOC-файл под свои специальные нужды, определяя синонимы к стандартным глаголам или ключевым словам, добавляя элементы для новых файлов или запоминая часто используемые предложения и параграфы. UniVerse-файлы, определенные в VOC-файле некоторого счета, могут находиться в той же директории, что и VOC-файл, или в директориях других uniVerse-счетов. UniVerse предоставляет команды создания новых VOC-элементов для доступа к uniVerse-файлам других счетов и для переключения в другие счета.
Связь между файлом данных и соответствующим ему словарем задается в элементе VOC-файла, определяющем uniVerse-файл. Записи в словаре файла определяют:
· поля связанного с ним файла данных;
· различные виды показа данных, хранящихся в некотором поле;
· способы обработки данных, хранящихся в полях;
· трансляцию данных из других файлов;
· спецификации вывода и форматы отчетов.
Все записи uniVerse-файлов имеют переменную длину, как и поля, из которых состоят записи. Единственное ограничение на количество записей в файле может быть вызвано размером вашего диска. Каждая запись идентифицируется уникальным именем, называемым ключом.
UniVerse-файлы реализуются при помощи директорий и файлов Unix. UniVerse предлагает несколько видов организации uniVerse-файла. Это разнообразие методов хранения упрощает проектирование прикладных задач и позволяет обеспечить наивысшую эффективность. Допускаются следующие файловые структуры:
· нехэшированные файлы;
· статические хэшированные;
· динамические хэшированные;
· В-деревья.
Файлы данных могут быть либо хэшированными, либо нехэшированными в зависимости от характера данных, которые вы хотите в них хранить. Словари файлов обычно - хэшированные файлы.
Нехэшированные файлы предназначены для хранения текстов, исходного кода программ и других малоструктурированных данных. Эти нехэшированные файлы реализуются как Unix-директории, в которых каждая запись хранится в виде отдельного Unix-файла.
Хэшированные файлы позволяют осуществлять быстрый доступ к отдельным записям в файле независимо от их количества в файле. Это достигается благодаря специальному методу, при помощи которого записи запоминаются и ищутся в файле. Алгоритм хэширования использует ключ записи, чтобы разбить записи на несколько групп. С помощью этого алгоритма вычисляется адрес группы, где должна находиться запись. Чтобы найти конкретную запись в хэшированном файле, uniVerse сначала определяет адрес ее группы на диске, а затем запись ищется в пределах группы.
Динамические файлы автоматически устанавливают количество групп в зависимости от меняющегося количества данных. Динамические файлы для пользователя более просты в управлении. Эффективность работы динамического файла можно увеличить, подменив некоторые параметры, принимаемые по умолчанию.
В-деревья - это особый тип uniVerse-файлов. В-деревья (или сбалансированные файлы) хранят записи упорядоченными. За счет этого сокращается время поиска, и операции доступа к записям оказываются менее дорогостоящими, чем для файлов с вторичными индексами.
2. Модель данных uniVerse
2.1. Непервая нормальная форма данных NF2.
Важным аспектом традиционной реляционной модели данных является тот факт, что элементы данных, которые хранятся на пересечении строк и столбцов таблицы, должны быть неделимы и единственны. Это значит, что данные не могут быть развернуты в процессе дальнейшей обработки. Такое правило было заложено в основу реляционной алгебры при ее разработке как математической модели данных. Дальнейшие исследования показали, что существует ряд случаев, когда ограничения классической реляционной модели существенно мешают эффективной реализации приложений [2, 3].
Опыт разработки прикладных информационных систем показал, что отказ от этой установки ведет к качественно полезному расширению модели данных. Если допустить, что значение данных может само состоять из подзначений, то в результате возникает понятие многозначного поля. Проще всего рассматривать набор многозначных полей в таблице как самостоятельную встроенную таблицу.
При условии, что встроенная таблица удовлетворяет общим критериям (например имеет уникальный ключ), естественным образом происходит расширение операторов реляционной алгебры.
Модель данных uniVerse поддерживает также ассоциированные многозначные поля, которые часто называют множественными группами. То есть вы можете связать несколько столбцов с множественными значениями в единое целое, называемое ассоциацией. При этом в строке первое значение одного столбца ассоциации соответствует первым значениям всех других столбцов ассоциации, в такой же связи находятся все вторые значения столбцов и т.д.
Многозначные поля и ассоциации не могут вкладываться друг в друга. Такая модель данных была названа постреляционной. В данной статье термин постреляционная модель используется только в этом смысле. Расширение синтаксиса SQL позволяет осуществлять доступ к полю переменной длины как в расширение реляционной модели, но, конечно, можно применять также стандартные и вспомогательные средства uniVerse: RETRIEVE, REVISE и Basic. В целом многозначность полей является очень полезным свойством при создании коммерческих приложений, где информация нередко представлена в виде списков предметов.
На рис. 1 наглядно продемонстрированы преимущества хранения данных в базах uniVerse, относящихся к непервой нормальной форме, перед более громоздким хранением в базах данных первой нормальной формы. Пример представляет хранение части данных такого типичного документа, как накладная.
INVOICES
| INVNO 0373 8374 7364 |
CUSTNO 8723 8232 8723 |
GOODS Пиво Вобла Лимонад Пиво Вафли Йогурт |
QTY 3 2 1 6 2 1 |
а) Структура хранения данных в uniVerse
INVOICES
| INVNO 0373 8374 7364 |
CUSTNO 8723 8232 8723 |
INVOICE.ITEMS
| INVNO 0373 0373 8374 8374 8374 7364 |
GOODS Пиво Вобла Лимонад Пиво Вафли Йогурт |
QTY 3 2 1 6 2 1 |
б) Структура хранения данных в традиционных системах
Структуры хранения данных с многозначными полями в uniVerse и в традиционных системах.
Так как в uniVerse можно создавать многозначные поля переменной длины, все накладные могут храниться в одном файле. При этом для хранения нужно меньше места и при обработке не требуется объединять данные, что повышает эффективность хранения данных.
Многие методологии проектирования данных позволяют определять многозначные поля и затем удалять в процессе нормализации. При этом таблицы преобразуются в первую нормальную форму или 1NF. Однако удаление многозначных полей не всегда способствует улучшению прикладных программ. В случаях, когда обычная форма доступа к полю подразумевает обращение ко всем его значениям, базе данных 1NF придется проделать операцию соединения (Join) каждый раз, когда нужно получить соответствующие значения, хранящиеся в другой таблице. Совершенно очевидно, что в подобной ситуации хранение значений физически в многозначных полях может обеспечить более эффективный доступ к информации.
О таблицах, содержащих многозначные поля, говорят, что они находятся в непервой нормальной форме, или NF2. Как было замечено ранее, при условии, что используемые поля подчиняются определенным правилам, позволяющим обращаться с ними, как с таблицами, встроенными в другие таблицы, форма NF2 не нарушает принципы реляционной алгебры. Более того, такая информация полностью доступна, так как расширенные операторы, которые работают с таблицами NF2, позволяют извлекать встроенные таблицы и рассматривать данные как информацию, поступившую из таблиц 1NF. И все же во многих случаях форма 1NF будет скорее исключением, а не правилом. В большинстве случаев гораздо более эффективно осуществлять доступ к многозначным полям одновременно с остальными данными, зная, что их всегда можно извлечь и рассматривать как отдельную таблицу в тех случаях, когда это может понадобиться.
Модель данных uniVerse представляет собой расширенную форму реляционной модели данных, которая допускает использование данных в форме NF2. В этой модели все данные хранятся в форме таблиц, как и в обычной реляционной базе данных. Как и в большинстве реляционных баз данных, таблицы описаны в словарях, содержащих логические описания, которые представляют столбцы таблиц. По словам Джона Моррелла (John Morrell), руководителя исследований International Data Corporation, "реляционные и постреляционные СУБД различаются только способами хранения и индексирования данных, во всем остальном - это одно и то же".
Моррелл утверждает, что компании автоматически выбирают реляционную модель, не давая себе труда поискать более производительный способ обработки данных. Такой подход особенно характерен для архитектур клиент-сервер, в которых сегодняшние пользователи ориентируются довольно слабо. "Как только они начинают анализировать свои проблемы, выясняется, что эффективность постреляционной технологии в управлении большими массивами быстро изменяющейся информации, например в бизнес-приложениях, гораздо выше", - говорит Моррелл [4].
Кроме того, uniVerse не требует, чтобы данные в поле были определенной длины или чтобы количество полей в записи было фиксировано. Это означает, что все данные и таблицы отличает большая гибкость относительно размера и их можно легко видоизменять.
2.2. Постреляционная модель и SQL
Реализация SQL в седьмой версии uniVerse соответствует стандарту Американского Национального Института Стандартов (ANSI) для интерактивного SQL с повышенной целостностью данных (ANSI X3.135-1989). В соответствии со стандартами ANSI SQL uniVerse обладает расширениями для обработки словарей uniVerse, фрагментов кода Basic в запросах, а также возможностями для форматирования и преобразования данных. Это позволяет обрабатывать данные одновременно с помощью операторов RETRIEVE, uniVerse и/или стандартными операторами SQL.
Естественно, существует технология перевода баз данных, созданных средствами uniVerse без SQL, в среду SQL. В целом возможности описания данных в словарях uniVerse значительно богаче и тоньше, нежели средства SQL, но тем не менее в целях упрощения изложения в данной статье мы будем в большинстве случаев для иллюстраций использовать именно SQL.
Достоинства постреляционной модели данных и SQL в среде uniVerse становятся очевидными, когда приходится обрабатывать многозначные столбцы. Многозначные столбцы с элементами переменной длины создают практичную среду для хранения данных и управления ими.
Более высокая эффективность обработки данных наглядно проявляется при сравнении SQL-инструкций SELECT, необходимых для создания отчета по накладным (рис. 2).
UniVerse:
SELECT INVNO, CUSTNO, GOODS, QTY FROM INVOICES;
Другие системы:
SELECT INVOICES.INVNO, CUSTNO, GOODS, QTY FROM INVOICES, INVOICE.ITEMS WHERE INVOICES.INVNO = INVOICE.ITEMS.INVNO;
Сравнение SQL-инструкций SELECT в uniVerse и в других системах.
2.3. Определение множественных полей в SQL
Поддержание уникальности данных в столбцах и строках. Как уже отмечалось выше, для того чтобы обеспечить корректность расширения реляционной модели включением множественных полей, необходимо наличие уникального ключа. Использование ключевого слова UNIQUE в инструкции CREATE TABLE ведет к тому, что никакая пара строк не может содержать одинаковые значения в указанном столбце. Ключевое слово UNIQUE должно следовать сразу за NOT NULL. В приведенном ниже примере в таблице CUST столбец CUSTNO определяется таким образом, что номера клиентов не могут совпадать:
CREATE TABLE CUST (CUSTNO INT NOT NULL UNIQUE NOT EMPTY, ...);
Для многозначных столбцов в целях предохранения от повторяющихся значений в пределах одной записи используется ключевое слово ROWUNIQUE. Это ключевое слово должно следовать сразу за NOT NULL. В приведенном ниже примере в файле ORD запрещается повтор номеров товаров, входящих в состав одного заказа:
CREATE TABLE ORD (PRODNO INT NOT NULL ROWUNIQUE MULTIVALUED, ...);
Ассоциирование многозначных столбцов. Можно ассоциировать многозначные столбцы, используя ключевое слово ASSOC в команде CREATE TABLE. Синтаксис таков:
ASSOC имя (столбец KEY, столбец [ KEY ], ...)
Ключевое слово ASSOC вводит ассоциацию, ее имя и столбцы, которые ассоциируются. Кроме того, по крайней мере один столбец должен стать ключом ассоциации (KEY). Ключевой столбец необходимо определить как NOT NULL.
В следующем примере приводится часть инструкции CREATE TABLE, которая устанавливает ассоциацию между многозначными столбцами PHONE и PHONEDESC таблицы CUST. Ассоциация получает имя PHONES:
CREATE TABLE CUST (CUSTNO INT NOT NULL PRIMARY KEY, BILLTO CHAR(80), PHONE INT MULTIVALUED NOT NULL ROWUNIQUE, PHONEDESC CHAR(25) MULTIVALUED, ASSOC PHONES (PHONE KEY, PHONEDESC), ...);
Примечание. Если столбец определяется как единственный ключ ассоциации, к нему автоматически применяется ограничение ROWUNIQUE. Вы не сможете хранить в строке одинаковые значения.
Выборка строки, только если каждое значение отвечает заданному критерию. Можно сделать так, чтобы выбирались только те многозначные столбцы, где каждое значение отвечает определенному критерию. Для этого достаточно употребить ключевое слово EVERY в конструкции WHERE. Синтаксис таков:
WHERE EVERY выражение
В приведенном ниже примере из таблицы CUST производится выборка только тех записей, где все телефонные номера имеют код города, равный 095 (Москва). Столбец PHONE многозначный:
SELECT BILLTO, PHONE FROM CUST WHERE EVERY PHONE LIKE "%095%";
В следующем примере производится выборка только тех записей таблицы ORD, где номер товара лежит в диапазоне от 202 до 204. Столбец PRODNO многозначный:
SELECT ORDERNO, PRODNO FROM ORD WHERE EVERY PRODNO BETWEEN 202 AND 204;
Ключевые слова IN, BETWEEN, ANY, ALL и многозначные столбцы. Для определения критериев выборки из многозначных столбцов можно пользоваться ключевыми словами IN, BETWEEN, ANY и ALL. В зависимости от того, являются ли столбец и результат подзапроса однозначными или многозначными, используются специальные соглашения, которые определяют трактовку логики запроса и его результата.
3. Проектирование постреляционных баз данных
Как и другие реляционные СУБД, uniVerse может быть использована в качестве стандартного реляционного SQL-сервера баз данных при проектировании прикладных систем. Для этого uniVerse предоставляет целый набор интерфейсов, начиная от ODBC и заканчивая набором драйверов к различным средам разработки (Uniface, NSDK и др.) При этом разработчики могут применять различные методики и соответствующий инструментарий проектирования. Для целого ряда приложений этот подход окажется оптимальным, но, по мнению авторов, при проектировании большинства бизнес-приложений, связанных с учетными задачами, такой подход не является характерным, и поэтому он не рассматривается в данной статье.
3.1. Опыт разработки приложений
Опыт применения в течение нескольких лет постреляционных СУБД в различных бизнес-приложениях, имеющийся в фирме СЕПТ, в частности разработка автоматизированной информационной системы (АИС) контроля и управления торговым домом "ТАИС", позволил выделить некоторые особенности проектирования информационных систем с использованием постреляционых баз данных. Эти особенности обусловлены наличием возможности построения трехмерных таблиц и развитых средств словарной организации данных, с одной стороны, и ориентацией таких систем на оперативную аналитическую обработку данных, так называемую OLAP-обработку, с другой. Если проанализировать типичные требования к OLAP-продуктам [5], можно увидеть, что функциональные характеристики uniVerse в значительной степени удовлетворяют им [6].
При разработке АИС "ТАИС" в качестве основных принципов проектирования были выдвинуты следующие.
- Корпоративная обработка данных с использованием единой базы данных.
- Открытость.
- Масштабируемость.
- Мобильность.
- Разумное соотношение цена/качество.
Исходя из вышеперечисленных принципов была выбрана СУБД uniVerse, как обеспечивающая режим сервера в среде Unix. Важным фактором при выборе СУБД был также положительный опыт создания учетных систем, связанных с обработкой документов, с использованием особенностей постреляционной модели.
Снижение стоимости системных составляющих проекта достигается за счет двух факторов. Во-первых, пользователи могут получать доступ к системе как через алфавитно-цифровые терминалы, так и через персональные компьютеры в режиме эмуляции терминалов, что снижает функциональные и стоимостные требования к терминальному оборудованию. Во-вторых, стоимость самой СУБД uniVerse существенно ниже стоимости других корпоративных СУБД.
Использование Unix в качестве операционной среды позволяет поддерживать самые разнообразные конфигурации системы и обеспечить переносимость на различные платформы. В настоящее время СУБД uniVerse может функционировать и под Windows NT.
Система включает три основные подсистемы: бухгалтерский учет, учет движения товаров, управление предприятием. В системе используется единая база данных предприятия.
В соответствии с принятыми международными стандартами разделения функций торговли подсистема управления движением товаров разделяется на две основные части:
FRONT-OFFICE - средства автоматизации торговых и кассовых операций в торговом зале;
BACK-OFFICE - средства автоматизации товародвижения, учета и менеджмента.
FRONT-OFFICE с помощью компьютеризированных касс обеспечивает полнофункциональный набор кассовых и расчетных операций по наличным и безналичным продажам, в том числе и с магнитными/SMART-картами, товарных операций со штучным и весовым товаром. Все операции фиксируются на чековой и контрольной лентах, в фискальной памяти и электронных копиях.
BACK-OFFICE позволяет осуществлять полномасштабное управление складами и магазинами, объединяя весь спектр товарных, складских и банковских операций в единый коммерческий комплекс. АИС "ТАИС" может выполнять функции BACK-OFFICE на торговых предприятиях различной формы среднего и крупного размера. Необходимо было обеспечить единый комплекс автоматизации бухгалтерского учета и товародвижения с обработкой всех бухгалтерских и складских документов, а также предоставить достаточно гибкие средства анализа деятельности предприятия. Кроме того, предусмотрен интерфейс взаимодействия с FRONT-OFFICE. Успешный опыт промышленной эксплуатации "ТАИС" показал правильность принятых проектных решений.
3.2. Проектирование структуры базы данных
Важнейшей особенностью проектирования постреляционных баз данных является отсутствие традиционного процесса нормализации. Переход от ER-моделей к уровню логического проектирования упрощается за счет использования данных в форме NF2. При проектировании информационной системы, являющейся отражением "реального мира", мы отталкиваемся от объектов реального мира, которыми могут быть деловые документы, люди и т.п. Как правило, эти объекты обладают довольно сложной информационной структурой, где многие атрибуты являются повторяющимися, содержащими множественные значения. Например, человек может иметь несколько детей, быть владельцем нескольких автомобилей. При обычном подходе проектировщику приходится прибегать к декомпозиции объектов, т.е. разложению его на множество более простых объектов. При этом для сохранения целостности объекта необходимо установить набор взаимосвязей. Если система включает несколько достаточно сложных объектов, то число таблиц становится настолько велико, что проектировщику трудно в них разобраться.
Модель uniVerse позволяет проектировщику управлять процессом нормализации, т.е. определять, какие элементы подлежат нормализации, а какие необходимо оставить ненормализованными, т.е. хранить объекты в более естественной структуре как некую целостную сущность. Этот последний аспект представляется нам достаточно важным, поскольку в сознании проектировщика одно отношение отражает один объект, что делает структуру проектируемой системы более похожей на реальный мир. В самом деле одним из существенных недостатков нормализованных реляционных баз данных является потеря семантики реальной предметной области.
Данные в форме NF2 хранятся в более агрегированном виде. Трехмерная организация данных позволяет с учетом целевых функций аналитических преобразований данных более компактно и удобно для генерации отчетов размещать данные.
Первоначальный анализ предметной области может быть осуществлен с использованием одной из моделей описания концептуального уровня, например ER-модели. Основная особенность проектирования состоит в том, что в представленной ER-модели определяются иерархические цепочки объектов предметной области. В каждой такой цепочке определяется базовая сущность, которой иерархически подчинены вторичные сущности. Это подчинение носит двойственный характер: с одной стороны, оно отражает обычно семантику предметной области, например связь первичных и вторичных документов, фиксирующих одну и ту же операцию предприятия, или описание некого реального объекта и связанных с ним групп атрибутов, сгруппированных по каким-либо принципам, а с другой стороны, дополнительным критерием выделения таких иерархических цепочек является учет функций генерации выходных данных. Выделенные объекты описываются в виде трехмерных таблиц.
3.3. Модель данных и выбор метода решения задачи
Использование постреляционной модели данных оказывает существенное влияние и на выбор метода решения задачи. Так, например, традиционно при проектировании баз данных для систем бухгалтерского учета данные разбиваются на ряд отношений в соответствии с общепринятой журнально-ордерной системой, проще говоря, на каждый вид учета. Это приводит к большому дроблению данных и, следовательно, к большим потерям при проведении аналитических запросов, когда приходится производить много операций соединения отношений. При использовании постреляционной модели оказалось гораздо эффективнее при реализации систем бухгалтерского учета применять мемориально-ордерную систему учета. Для внутреннего хранения и для обработки удобно в этом случае применять мемориальный ордер, который описывает отдельную проводку. Первичным документом при этом является электронная накладная, единым образом хранящая все данные, связанные с каждой операцией учета. Данные такого рода, конечно же, не могут храниться в плоских нормализованных таблицах.
Как видно из рис. 3, файл E-INVOICES содержит данные как из накладной, так и из мемориального ордера. Данные мемориального ордера включают в себя INVNO (Номер накладной), DATE (Дата), PRICE (Цена), DEBIT (Номер счета по дебету), CREDIT (Номер счета по кредиту). Весьма интересно, что в данном случае разработчики при проектировании интуитивно соединили эти данные, позднее обнаружив, что это соответствует и ручной технологии бухгалтерского учета по мемориально-ордерной форме, в которой "...проводка осуществляется непосредственно на документе (при помощи штампа) либо на прикрепленном к документу (или к группе их) бланке мемориального ордера..." [7]. Такая организация данных позволяет экономить память и упрощать доступ к данным, поскольку очевидно, что нормализация такого отношения приводит к существенному дроблению данных и увеличению потерь при выполнении операций объединения при запросах.
E-INVOICES
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Вобла |
2 |
6000 |
|
|
|
|
|
|
|
Пиво Вафли |
6 2 |
30000 13000 |
|
|
|
|
|
|
|
|
|
|
|
|
Рисунок 3.
Упрощенная структура электронной накладной.
Кроме того, в настоящее время от учетных систем, в том числе и от систем бухгалтерского учета, требуется возможность проведения аналитических расчетов, которые также легче обеспечить в таких объединенных отношениях в форме NF2. На рис. 3 приведено существенно упрощенное отношение, так как в реальной базе данных количество атрибутов значительно больше. Один из главных объектов Товар отображается в отношение в форме NF2, которое включает все атрибуты, характеризующие объект. В него включены все показатели по налогам, наценкам, таре и т.д.
Можно утверждать, что во многих случаях проектирования систем, связанных с обработкой документов, так называемых учетных систем аналогичный подход окажется достаточно эффективным, поскольку в большинстве случаев документирование операций в таких системах носит строго детерминированный характер, при котором практически каждый документ имеет первичный - порождающий и вторичный - наследующий документ.
3.4. Целостность данных
Очевидно, что при ненормализованных данных чрезвычайно важной становится проблема целостности и непротиворечивости данных. Наличие кодов конверсии и корреляции в словарях данных позволяет просто и эффективно встраивать процедуры, которые автоматически вызываются при обращении к данным и могут осуществлять функции контроля целостности и различных преобразований, а также вспомогательные вычисления.
Для этого при описании данных в словаре следует определить коды конверсии и корреляции, т.е. преобразования, которые необходимо произвести над данными в поле до или после обращения к ним. Спецификации таких преобразований могут содержать команды процессоров uniVerse, тексты Basic-программ или коды форматных преобразований.
Различие между кодами корреляции и конверсии заключается в том, что коды корреляции применяются сразу после чтения данных из файла, но перед тем, как они селектируются и сортируются (или обрабатываются еще каким-либо образом). Преобразования конверсии, напротив, выполняются после того, как данные подверглись обработке.
Механизм конверсии и корреляции позволяет легко реализовать действия по контролю целостности при включении, исключении и корректировке данных.
При проектировании базы данных можно указать подпрограммы, которые активируются или при считывании поля данных, или при его записи. Эти подпрограммы могут проверять наличие ссылок на данные, дублировать их или модифицировать соответствующим образом.
3.5. Использование словарной организации данных
Широкий набор средств описания в системе словарей данных, их взаимодействия, а также возможность ввода и обработки описателей на уровне пользователей позволяют проектировщику строить адаптивные базы данных. Большинство uniVerse-файлов состоит из одного словаря и, по крайней мере, одного файла данных. Хотя может быть создан словарь, с которым не связан ни один файл данных, так же, как и файл данных, с которым не связан ни один словарь.
Преимуществом перед большинством реляционных баз данных является возможность использовать один и тот же словарь для описания нескольких таблиц или разные словари для описания одной в зависимости от обстоятельств. В тех случаях, когда возникает необходимость ведения нескольких файлов одинаковой структуры, можно использовать для них один общий словарь (рис. 4.).
Рисунок 4.
Можно иметь один файл данных, но при этом описывать его структуру различными способами в нескольких разных словарях (рис. 5).
Рисунок 5.
Создание файла словаря, не связанного ни с одним файлом данных, имеет интересное применение для построения так называемых виртуальных таблиц (рис. 6). Виртуальная таблица описывается как совокупность столбцов, размещенных в различных файлах данных или других виртуальных таблицах. Такую таблицу можно обрабатывать стандартным образом, не проводя в действительности физического объединения данных. В принципе возможно использование файла словаря и для хранения данных.
Рисунок 6.
Интересные возможности предоставляет так называемый распределенный файл. Распределенный файл является составным хэшированным uniVerse-файлом, который состоит из множества существующих uniVerse-файлов. Каждый uniVerse-файл, принадлежащий распределенному файлу, называется подфайлом. Алгоритм распределения подфайлов в распределенном файле позволяет управлять размещением записей при помощи назначения специальных ключей подфайлам. Подфайлы могут располагаться в различных счетах. Подфайл может принадлежать более чем одному распределенному файлу.
Потребность в распределенных файлах может возникнуть, когда вы хотите файлы данных иерархически разложить по функциональным группам. Распределенные файлы позволяют получить одно итоговое сообщение по отдельным файлам. Например, вы можете иметь файл FISH.DEPT (Рыбный отдел) и MEAT.DEPT (Мясной отдел). Если вы хотите видеть SALES (Объем продаж) для обоих этих файлов, то можно воспользоваться распределенным файлом, который включает оба указанных файла.
4. Заключение
Данная статья, конечно же, не может ознакомить со всеми возможностями СУБД uniVerse. Но авторы надеются, что она даст представление о некоторых интересных особенностях проектирования и обработки данных в СУБД с использованием множественных полей в трехмерных расширениях реляционной модели данных. В целом можно сделать следующие выводы.
1. Использование множественных полей и ассоциаций в постреляционной модели при разработке многих приложений позволяет существенно экономить память и уменьшать потери вычислительных мощностей.
2. Возможно корректное расширение SQL для обработки множественных полей и ассоциаций.
3. При проектировании постреляционных баз данных необходимость нормализации данных определяется проектировщиком исходя из функциональных целей.
4. Возможность задания кодов конверсии и корреляции в словарях предоставляет проектировщику дополнительные средства создания хранимых процедур и ссылочных связей.
Авторы привели в качестве примера тот опыт, который был получен при разработке учетных бизнес-систем, хотя известен опыт использования подобных СУБД и при обработке текстовых документов, так как хранение данных в текстовом виде, наличие полей практически неограниченной длины, а также возможности контекстного поиска в них создают мощные предпосылки для этого.
Информацию о развитии и приложениях СУБД uniVerse можно получить на http://www.vmark.com.
Литература
- Лаврентьева Т.Г., Шабаев И.Г. UniVerse - развитие реляционных стандартов. - СУБД #2, 1995, стр. 102-105.
- Системы баз данных третьего поколения: Манифест. - СУБД #2, 1995, стр.143-158.
- Дэвид Васкевич. Кризис баз данных и проблема выбора: повестка дня до 2001 года. - СУБД #1, 1995, стр. 92-98.
- Там, за горизонтом, - постреляционные СУБД. - Computerworld Moscow, #37 (145), 1994, стр. 32-33.
- Э. Ф. Кодд. 12 правил OLAP. - Computerworld Moscow, #15 (145), 1995, стр. 37.
- Smith David. Post-Relational Database: Revitalizing Relational Technology for New Applications. - IDC White Paper, March 1994.
- Н. Грунтфест, Б. Щеглов. Бухгалтерский учет в промышленном предприятии. - "Беларусь", 1970, стр. 56.
Евгений Константинович Ким, Илья Гумарович Шабаев, Владимир Алексеевич Бычков,
тел.: 155-40-49