Классика баз данных - статьи

       

Зависимости данных в существующих системах


Обеспечение таблиц описания данных в разрабатываемых сегодня системах является существенным продвижением на пути к независимости данных [5,6,7]. Наличие таких таблиц облегчает изменения некоторых характеристик представления данных, хранимых в банках данных. Однако набор характеристик представления данных, которые могут быть изменены без нанесения логического ущерба некоторым прикладным программам, продолжает оставаться ограниченным. Далее, модель данных, с которыми работают пользователи, по-прежнему загромождается характеристиками представления; в особенности это касается представлений коллекций данных (а не одиночных элементов данных). Тремя основными видами зависимости данных, которые все еще требуется устранить, являются зависимость порядка, зависимость индексации и зависимость путей доступа. В некоторых системах эти зависимости четко не отделены одна от другой.

1.2.1. Зависимость порядка. Элементы данных в банке данных могут храниться разными способами, некоторые из которых не предполагают наличия какого-либо порядка, некоторые допускают участие каждого элемента только в одном порядке, а некоторые – в нескольких порядках. Обратим внимание на те существующие системы, в которых требуется или хотя бы допускается хранение элементов данных, по крайней мере, в одном полном порядке, тесно связанном с зависимым от аппаратуры порядком адресов. Например, записи в файле, описывающем детали, могут храниться в порядке убывания серийных номеров. В таких системах обычно допускается, чтобы прикладные программы основывались на предположении о том, что порядок представления записей идентичен порядку их хранения (или является его частью). Эти прикладные программы, использующие свойства упорядоченности файла, скорее всего не смогут правильно работать, если по какой-то причине потребуется изменить этот порядок. Аналогичные замечания остаются в силе для случая, когда порядок хранения реализуется посредством указателей.

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

1.2.2. Зависимость индексации. В контексте форматированных данных индекс обычно полагается компонентом представления данных, ориентированным исключительно на увеличение эффективности. Наличие индексов ускоряет выполнение запросов и операций обновления, но в то же время замедляет выполнение операций вставки и удаления. С точки зрения информативности индекс является избыточным компонентом представления данных. Если в системе используются индексы, и она должна хорошо справляться с изменениями активности среды по отношению к банку данных, то, вероятно, потребуется возможность время от времени создавать и уничтожать индексы. Возникает вопрос: могут ли при этом остаться неизменными прикладные программы и интерактивная деятельность?

В современных системах форматированных данных применяются разнообразные подходы к индексации. В TDMS [7] обеспечивается обязательная индексация по всем атрибутам. В текущей версии IMS [5] пользователю предоставляется выбор для каждого файла: между полным отсутствием индексации (иерархическая последовательная организация) и индексацией только по первичному ключу (иерархическая индексно-последовательная организация). Ни в одном из этих случаев логика пользовательского представления не зависит от обязательно поддерживаемых индексов. Однако в IDS [8] проектировщикам файлов предоставляется возможность выбора индексных атрибутов и добавления индексов в структуру файла с использованием средств дополнительных цепочек. Прикладные программы, в которых для повышения эффективности используются эти индексные цепочки, должны ссылаться на них по именам. Такие программы не смогут работать правильно, если эти цепочки будут впоследствии удалены.

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


Приведем простой пример.

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

Структура 1. Проекты подчинены Деталям



Файл Сегмент Поля
F ДЕТАЛЬ номер детали
наименование детали
описание детали
имеющееся количество
заказанное количество
ПРОЕКТ номер проекта
наименование проекта
описание проекта
подтвержденное количество
 
Структура 2. Детали подчинены Проектам

Файл Сегмент Поля
F ПРОЕКТ номер проекта
наименование проекта
описание проекта
ДЕТАЛЬ номер детали
наименование детали
описание детали
имеющееся количество
заказанное количество
подтвержденное количество
 
Структура 3. Детали и Проекты наравне, Связь назначения деталей проектам подчинена Проектам

Файл Сегмент Поля
F ДЕТАЛЬ номер детали
наименование детали
описание детали
имеющееся количество
заказанное количество
G ПРОЕКТ номер проекта
наименование проекта
описание проекта
ДЕТАЛЬ номер детали
подтвержденное количество
 
Структура 4. Детали и Проекты наравне, Связь назначения деталей проектам подчинена Деталям

Файл Сегмент Поля
F ДЕТАЛЬ номер детали
наименование детали
описание детали
имеющееся количество
заказанное количество
ПРОЕКТ номер проекта
подтвержденное количество
G ПРОЕКТ номер проекта
наименование проекта
описание проекта
<


 
Структура 5. Детали, Проекты и Связь назначения деталей проектам наравне

Файл Сегмент Поля
F ДЕТАЛЬ номер детали
наименование детали
описание детали
имеющееся количество
заказанное количество
G ПРОЕКТ номер проекта
наименование проекта
описание проекта
H ПОДТВЕРЖДЕНИЕ номер детали
номер проекта
подтвержденное количество
Теперь рассмотрим задачу выборки номера детали, названия детали и количества деталей этого типа для каждой детали, используемой в проекте с названием "альфа". Следующие наблюдения могут быть сделаны независимо от того, какая конкретная информационная система с древовидной организацией информации выбирается для решения этой задачи. Если для этого разрабатывается программа P, ориентированная на использование одной из приведенных выше структур (т.е. P не определяет, какова реальная структура представления данных), то при любом выборе P не сможет работать, по меньшей мере, с тремя потенциально возможными структурами. Более точно, если P следует структуре 5, то ей не удастся работать со всеми другими структурами; если PP следует структуре 3 или 4, то ей, по меньшей мере, не удастся работать со структурами 1,2 и 5; если P следует структуре 1 или 2, ей, как минимум , не удастся работать со структурами 3, 4 и 5. В каждом случае причина проста. Если отсутствуют проверки для определения реально заданной структуры, то работа P заканчится неудачей по причине попытки перехода по ссылке к несуществующему файлу (в доступных сегодня системах это трактуется как ошибка) или из-за отсутствия перехода по ссылке к файлу, содержащему нужную информацию. Читателю, который в этом сомневается, рекомендуется написать пробные программы для решения этой простой задачи.

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

Системы, которые предоставляют пользователям сетевую модель данных, порождают аналогичные трудности. И в случае деревьев, и в случае сетей пользователь (или его программа) должен обеспечить набор путей доступа к данным. Неважно, находятся ли эти пути в точном соответствии с определяемыми ссылками путями в хранимом представлении (в IDS это соответствие является предельно простым, в TDMS – совсем наоборот). В результате, независимо от конкретного вида хранимого представления, интерактивная деятельность и программы становятся зависимыми от существования пользовательских путей доступа.

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


Содержание раздела