Традиционные файловые системы.
«Безопасные корабли – это вытащенные на берег корабли»
АНАХАРСИС(Мудрый), VIв. до н.э.
Файловая система – это набор программ, которые выполняют для пользователя некоторые операции с данными, например создания отчетов. Каждая программа определяет свои собственные данные и управляет ими. Они появились как средство автоматизации ручных картотек. Файл есть последовательность записей, т.е. это физический контейнер для кортежей реляционного отношения. Сложности с файловыми системами возникают при необходимости обработки перекрёстных ссылок, увеличении количества пользователей и больших объемах информации. Пользователи данных могут договориться о схемах, но экземпляры реляционных отношений у них разделены (каждый отвечает и использует свои файлы).
Файловые системы, как архитектура информационных систем, морально устарела в силу следующих причин:
Разделения и изоляции данных в отдельных файлах, доступ к которым весьма затруднен;
Дублирования данных из-за их децентрализации, проводимым каждым субъектом независимо от других - приводит к неэкономному расходу ресурсов и нарушению их целостности, т.е. общие данные у различных субъектов могут стать противоречивыми;
Зависимости от данных, жестко зафиксированная в коде программ приложений;
Несовместимости форматов файлов, зависящих от языка приложений (COBOL и С);
Сложности развития и модификации приложений, т.к. изменение схем данных требует редакции код во всех местах использования и преобразования текущих и архивных файлов;
Быстрого нарастание количества новых приложений, т.к. обычно отсутствовали средства автоматического создания или поддержки универсальных запросов.
Все перечисленные выше ограничения есть следствия двух факторов:
Определение данных хранится внутри приложений, а не отдельно и независимо от них;
Кроме программных приложений, нет других инструментов обработки данных.
Архитектура «реляционной» файловой системы, данная в заголовке, не хуже многих традиционных. Но все равно, для повышения эффективности работы с данными, необходимы новые парадигмы баз данных (database - БД) и систем управления базами данных (Database Managment System DMS - СУБД). Рассмотрим, каким образом можно организовать надстройку над файловой системой, обеспечивающую элементы поддержки реляционной модели данных для схем файлов.
Допустим, что мы имеем пользователей, которые решают единственный класс задач имитационного моделирования в формализме сетей Петри. Такие ситуции часто возникают при создании специализированных программных комплексов. Отметим, что само представление схемы реляционной базы данных в виде универсального отношения не очень удобно и не учитывает двух новых сущностей: наличие множества экземпляров реляционных отношений и пользователей, которые манипулируют ими как исходными данными и результатами моделирования.
Введем системные соглашения об организации иерархии файловой системы. Пусть в системной директории (имя которой «petry») содержится системная информация, т.е. схема схем, каталоги схем и их экземпляров и т.д. Для каждого пользователя, который регистрируется в системе под своим идентификатором, создается в корневая одноименная вложенная директория (навигация “...\petry\user_name”. Каждый файл в данной архитектуре организации данных есть экземпляр реляционного отношения. Имя файла есть пара: имя экземпляра и имя схемы, разделённая точкой. Принадлежность файла пользователю пока не поддерживается.
Нам следует начать со схемы схем, которую мы трансформируем из схемы универсального отношения (RSS) в схему реляционной базы данных (RDB). Для этого мы выделим атрибуты каталога схем (SC):
SchId - имя схемы реляционного отношения,
AtrId - имя атрибута в схеме «SchId»,
isKey- признак ключевого атрибута в схеме (1-да\0-нет),
DomId - имя домена атрибута «AtrId» в схеме «SchId»,
TypeId – имя типа домена «DomId» (системное соглашение).
Связи между реляционными отношениями на базе указанных сущностей (и смысл их кортежей) мы будем поддерживать по общим идентификаторам атрибутов (полагая совпадающие значения образами одного и того же). Новая версия экземпляра схемы схем rdb(RDB) будет метаописывать схему реляционной базы данных. Он остается неизменным для любой организации файловой системы (или реляционной базы данных). Поэтому часто этот экземпляр подразумевается и как файл физически отсутствует.
rdb(RDB)
RelId AtrId DomId TypId Comnt
SS RelId RelDm iden имя схемы
SS AtrId AtrDm iden имя атрибута
SS DomId DomDm iden имя домена
SS TypId TypDm type тип значений домена
SS Comnt ComDm string комментарий к кортежу
Рассмотрим определение схемы реляционной базы данных как экземпляра отношения rdbs(RDB) в случае выделения в ней каталога схем (SC) и каталога экземпляров (EC). Значение экземпляра, показаное ниже, задает структуру системной части реляционной базы данных, которая в свою очередь является реляционной базой данных. Это свойство в дальнейшем допускает конструкцию самоописание данных, которое будет рассматриваться особо.
rdbs(RDB)
RelId AtrId DomId TypeId Comnt
SC SchId SchDm iden имя схемы
SC AtrId AtrDm iden имя атрибута
SC isKey KeyDm bool признак ключа(0\1)
SC DomId DomDm iden имя домена атрибута
SC TypId TypDm iden имя типа атрибута
EC Pool PntDm pntr указатель пула памяти
EC ExmId ExmDm iden имя экземпляра отнош.
EC SсhId SсhDm iden имя схемы отношения
Каталог экземпляров EC используется для работы с данными в приложении. В нашем случае это программа имитационного моделирования сетей Петри и схема её реляционной базы данных уже описана нами (см. экземпляр petry(RDB)). Итак, существование схемы предметной области petry(RDB) подразумевает существование её схемы метапредметной области (например, экземпляра rdbs(RDB)). Для однозначной трактовки последнего нам надо иметь экземпляр схемы метеметапредставления rdb(RDB). Все они необходимы для последовательного раскрытия смысла (семантики) любой реляционной базы данных на разных метауровнях.
Несложно заметить, что все три экземпляра имеют общую схему. Это позволяет нам объединить их в едином описании схемы предметной области, которое будет обладать свойством самоописания. Для этого потребуется расширить схему схем дополнительным атрибутом «MetaN» уровня схемы.
Petry_fs(RDBS) MetaN RelId AtrId DomId TypId Comnt
2 SS MetaN MetDm unsigned метауровень
2 SS RelId RelDm iden имя схемы
2 SS AtrId AtrDm iden имя атрибута
2 SS DomId DomDm iden имя домена
2 SS TypId TypDm type тип знач.домена
2 SS Comnt ComDm string комм. к кортежу
1 SC SchId SchDm iden имя схемы
1 SC AtrId AtrDm iden имя атрибута
1 SC isKey KeyDm bool признак ключа
1 SC DomId DomDm iden имя домена атр.
1 SC TypId TypDm iden имя типа атриб.
1 EC Pool PntDm pntr указ. пула пам.
1 EC ExmId ExmDm iden имя экз.отнош.
1 EC SсhId SсhDm iden имя схемы отн.
0 S SN SNDm iden место-состояние
0 S SM SMDm unsigned кол-во ресурсов
0 T TN TNDm iden место-переход
0 T TD TDDm timedelay задержка
0 ST SN SNDm iden связь с сост.
0 ST TN TNDm iden связь с пер.
0 ST TI TIDm unsigned захват. ресурсы
0 TS TN TNDm iden связь с пер.
0 TS SN SNDm iden связь с сост.
0 TS TO TODm unsigned сбрас. ресурсы
0 SP SN SNDm iden сост. воздейс.
0 SP TM TMDm time момент воздейс.
0 SP NM NMDm int кол-во ресурсов
0 EC TN TNDm iden активный пер.
0 EC TK TKDm time вр.окон.актив.
0 TP TN TNDm iden процесс пер.
0 TP TK TKDm time окон. процесса
Мы получили достаточно полное и универсальное описание схемы реляционной базы данных на примере поддержания обслуживания не одной, а потока задач имитационного моделирования сетей Петри многими пользователями. Ясно, что мы далеко не полностью поддерживаем эти процессы с помощью «реляционной надстройки» к файловой системе. Но следующий шаг развития потребовал совсем иного уровня интеграции и организации вычислений.
До сих пор мы игнорировали очень важный аспект задачи – пользователей приложения и их права по отношению к данным. Другим интересным аспектом задачи выступает поддержание связей между данными (процессами их определения) и процессами их последующего использования в других вычислениях. Эта аспекты оказываются крайне важной для самых различных проблем, решение которых подразумевает междисциплинарную кооперацию специалистов и поэтому имеет распределённый характер. Не претендуя на её полноценное решение, мы покажем что даже простая (т.е. учебная) реляционная база данных позволяет более успешно поддержать совместную деятельность.