Поуровневое сравнение возможностей баз данных для коммерческих и конструкторских систем

Уровень	Конструкторские БД	Коммерческие БД
Сематика Запросы Язык	Символы Графы Изображения	Атрибуты Действия Сообщения
Описание данных Манипулирование данными	Сегменты Атрибуты Логический ввод Примитивы	Строки Элементы данных Отношения Транзакции
Механизм доступа	Нормализованные координаты Абсолютные и относительные положения Векторы	Пути доступа Кластеры Объекты Связи Индексы
Драйверы устройств	Сколка “Мышь” Световое перо Видеотерминал Графопостроитель	Клавиатура Речевой ввод Видеотерминал Печатающее устройство

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

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

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

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

Непротиворечивость данных

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

Ограничения по времени

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

1. После запроса на выдачу простого изображения пользователь должен увидеть “картинку” не позднее чем через 1 с.

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

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

Интеграция графических и неграфических данных

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

Можно выделить три уровня абстракции.

1. Внешний: описание концептуальной подсхемы.

2. Концептуальный: описание информационных объектов и связывающих их отношений.

3. Внутренний: описание структур хранения данных и путей доступа к ним.

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

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

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

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

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