СодержаниеСодержание
Содержание 2
1. Введение 3
2. Техническое задание. 12
3. Описание предметной области. 14
3.1. Архитектура uniVerse 14
3.2. Модель данных uniVerse 19
3.3. Проектирование постреляционных баз данных 25
3.4. Технология ASP 31
3.5. UvObjects 33
3.6. Объединение ASP и UvObjects 34
4. Обзор существующих решений проблемы. 35
5. Спецификация системы Update 37
5.1. Глобальные переменные. 38
5.2. Глобальные процедуры и функции. 38
5.3. Модули и файлы. 39
5.4. Взаимодействие с окружением. 40
5.5. Безопасность. 41
5.6. Тестирование системы. 41
5.7. Концепция интерфейса 42
5.8. Использование JavaScript 43
5.9. Системные требования 45
Приложение А. Руководство пользователя. 46
1. Введение 46
2. Подсистема аутентификации и персональных настроек. 46
3. Подсистема стандартного интерфейса 48
4. Подсистема обновления. 51
Приложение Б. Руководство программиста 55
1. Установка системы 55
2. Глобальные переменные. 58
3. Глобальные функции. 59
4. Модули и файлы. 60
5. Подключение к UniVerse 63
6. Заключение 65
Список используемой литературы 67Введение1. Введение
Существует целый класс бизнес-задач (так называемые учетно-аналитические задачи) в которых обращение к данным удобно вести по так называемым бизнес-объектам – аналогам реальных документов. В Финансо-вой сфере примерами бизнес-объектов могут служить счета-фактуры, мемо-риальные ордера, накладные. С информационной точки зрения бизнес-объекты представляют собой наборы информации, зачастую довольно слож-ные, содержащие повторяющиеся элементы, но связанные в единое целое. Существует два подхода при проектировании информационной системы из таких бизнес-объектов.
При первом подходе проектировщику необходимо осуществить норма-лизацию информации, то есть разложить данные, содержащиеся в бизнес-объектах на множество таблиц содержащих неделимые "атомарные" элемен-ты информации. При этом проектировщику необходимо решить ряд проблем: установить связи между этими таблицами, при определении отношений "множество к множеству" создать промежуточные таблицы перекрестных ссылок, установить ограничения целостности и так далее.
При проектировании системы содержащей несколько бизнес-объектов проектировщик получает набор одноранговых таблиц с множеством связей, которые можно легко представить в виде диаграммы. Бизнес-объекты как бы "размываются" на фоне таблиц, поскольку таблицы не имеют иерархии. Ведь бизнес-объекты иерархичны по своей сути. Например, строки товаров в сче-те-фактуре не могут существовать и не имеют смысла без самого счета. При обращении к бизнес-объекту проектировщик определяет в операторах SQL операции "JOIN" для выборки информации из нескольких таблиц.
При втором подходе проектировщик осуществляет операции выбор-ки/доступа к данным оперируя непосредственно над бизнес-объектами. Нор-мализация данных производится динамически, в оперативной памяти, тогда, когда это действительно необходимо: например, когда производится группи-ровка счетов-фактур по типу товара.
Этот подход обеспечивает максимальную эффективность при работе с бизнес-объектами, но требует от СУБД поддержки сложных структур - таких как вложенные таблицы или массивы, а также возможности динамической нормализации этих структур. Таблицы в такой системе приобретают некото-рую иерархию: выделяются "главные" и "вспомогательные" таблицы.
Под многомерной СУБД понимается система управления базами дан-ных, реализующая т.н. Ненормализованную Реляционную Форму (ННРФ), способную обрабатывать модели данных, адекватные представлениям реаль-ного мира и свободную от принципиальных общеизвестных недостатков, присущих традиционным СУБД на основе нормализованной реляционной формы (SQL подобные СУБД Oracle, Informix, MS SQL Server и т.п.).
Основной эксплуатационный недостаток традиционных СУБД заклю-чается в необходимости привлечения высококвалифицированных програм-мистов для малейших изменений структуры базы данных и связанных с ней отчётов, запросов, экранных форм и прочего. Вторым важнейшим недостат-ком является невозможность для конечного пользователя самостоятельно анализировать данные в порядке, непредусмотренном программистами. Ко-нечно, некоторые пользователи могут писать некоторые запросы, но делать это штатным средством не удаётся. Можно спорить, но в практику это не вошло нигде, несмотря на затраты.
На самом деле, НРФ является лишь частным случаем ННРФ. Можно дока-зать, что любая структура данных, реализуемая в НРФ, всегда реализуема в ННРФ. Но не наоборот.
Рассмотрим это утверждение подробнее.
• Согласно Нормализованной Реляционной Форме, данные представляют-ся в виде линейных массивов (отрезков), где уникальному ключу эле-мента данных сопоставляются значения признаков данных. В теории эти линейные массивы называются кортежами, значения признаков данных находятся в полях. Записи объединяются в таблицы. В каждом поле мо-жет находиться только одно значение, причем строго одного, опреде-лённого заранее типа. Процедура записи проверяет соответствие типов данных, и несоответствие вызывает фатальную ошибку.
• Ненормализованная реляционная система так же состоит из записей, од-нако, не требует ни определения типа данных, ни длины поля, ни коли-чества значений в поле. Вообще, с точки зрения процедуры запи-си/чтения, структура или длина записи не имеет никакого значения, что позволяет иметь в одном файле записи различной структуры. Это свой-ство весьма точно отражает реальную картину мира – документы в Ва-шей папке имеют разное количество листов и разную длину абзацев. Содержимое поля – всего лишь аморфная последовательность бит, что позволяет трактовать её и как строку, и как внутреннее представление какого-либо числа или даты, или как мультимедийный двоичный объект. Тип данных – сугубо личное дело того процесса, который ими пользует-ся, но никак не процедуры записи.
• Легко доказать, что даже такая задача, как простейший телефонный справочник, способна создать большой объём работ для программистов. Рассмотрим эту ситуацию. Требуется создать базу данных, содержащую адрес, ФИО, телефон. Сначала всё просто и очевидно. Создаётся про-стейшая таблица из трёх полей, в каждом из которых одно значение. Всё прекрасно, пока не появляется человек с двумя и более телефонами. За-писать их в поле через запятую нельзя, т.к. другой тип данных. Менять тип данных – значит корректировать соответствующие программы, ра-ботающие с этим полем. Можно объявить поле типа массив, но такие поля в данном стандарте не индексируются, поиск по ним ведётся край-не медленно. Придётся подставлять ещё один файл, т.е. создавать ещё одну такую же таблицу. А если представить себе, что в данной квартире могут жить несколько людей и их надо описать, то становится ясным, что в итоге программисты должны любить и защищать такие СУБД – они гарантируют им вечную занятость даже на элементарных задачах.
• В многомерной СУБД телефонный справочник решается одним дейст-вием: созданием файла и указанием, что то, что читается из поля № 1 – адреса, из поля № 2 – ФИО и из поля № 3 читаются телефоны. Посколь-ку в поле может храниться неограниченное количество значений, то ввод второго или двадцать второго телефона ничем не запрещён – вво-дите на здоровье. Поскольку процедуры не зависят от структуры записи, никаких ошибок не возникнет. Даже на трёх полях – сокращение трудо-ёмкости вдвое, а если полей в системе сотни или даже тысячи (что не проблема) – то себестоимость разработки и эксплуатации падает на по-рядок.
Многомерные СУБД обладают всеми достоинствами реляционных СУБД и лишены их принципиальных недостатков.
Математический аппарат СУБД с изменяемой размерностью (многомер-ных СУБД) был разработан выдающимся американским математиком Доном Нельсоном в 60-х годах по заказу министерства обороны США. С 1968 года по настоящее время многомерные СУБД широко используются федеральны-ми службами многих стран мира. Определенный вклад в развитие многомер-ных систем, внесла компания «ПримТехнополис». Ей были реализованы крупные задачи, например:
Реализация №1 – управление городским хозяйством (ИС УГХ).
Система введена в эксплуатацию в 1992 году на PC/AT 286, который ра-ботал в многопользовательском и многозадачном режиме с виртуальной па-мятью, имея 10 МГц и 1Мб, обслуживалось 6 одновременно работающих на терминалах пользователей. Сейчас работает 25 пользователей. Система обес-печивает решение расчётно-аналитических задач в объёме УГХ, а именно от коммунальных расчётов, льгот и субсидий до учёта жилищного фонда и ин-женерного оборудования с вычислением сроков ремонтов и т.д.ЛитератураСписок используемой литературы
1. Лаврентьева Т.Г., Шабаев И.Г. UniVerse – развитие реляционных стандартов. // СУБД #2, 1995, 102-105.
2. Системы баз данных третьего поколения: Манифест. // СУБД #2, 1995, 143-158.
3. Васкевич. Д. Кризис баз данных и проблема выбора: повестка дня до 2001 года. // СУБД #1, 1995, 92-98
4. Там, за горизонтом, - постреляционные СУБД. // Computerworld Moscow, #37 (145), 1994, 32-33
5. Кодд. Э. Ф. 12 правил OLAP. // Computerworld Moscow, #15 (145), 1995, 37.
6. Smith D. Post-Relational Database: Revitalizing Relational Technology for New Applications. // IDC White Paper, March 1994.
7. Б. Сайлер и Д. Споттс. Использование Visual Basic 6. – Изд. дом Вильямс. Москва 1999
8. С. Айзекс. Dynamic HTML. – «BHV – Санкт-Петербург». 1998
9. А. Матросов, А. Сергеев, М. Чаунин. HTML 4.0. – «BHV – Санкт-Петербург». 1999
10. Е.К. Ким, И.Г. Шабаев, В.А. Бычков. Проектирование трехмерных баз данных в СУБД uniVerse // СУБД #3, 1996
11. Морозов И.В., Морозова Я.Р. Многомерные СУБД и практика построения корпоративных информационных систем. Тезисы докладов, Международный семинар ISIS-99. Владивосток, 1999.
|
|
