Структуры баз данных

Рассмотрим вкратце обобщенные логическую и физическую структуры БД.

Логическая структура БД (рис. 5.9) предполагает следующие уровни рассмотрения БД:

• база данных (database) — включает одну или несколько подбаз (файлов, таблиц, массивов), каждая из которых состоит из агрегатов данных (записей, документов) — record. Запись идентифицируется внутренним номером (ISN — internal sequential number, BH3 — внутренний номер запис SDN — sequential document number и пр.);

• запись (документ) — совокупность разнотипных и разноструктурных данных, описывающих (относящихся к) объ­ект реального мира, элемент предметной области АИС. Запись состоит из полей (field);

• поле — именованный элементарный или составной фрагмент записи (документа), содержащий информацию об оп­ределенном аспекте (аспектах) элемента (элементов) пред­метной области.

• элементарные (имеющие фиксированную или ограниченную длину) и не содержащие входящих в них структур данных;

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

• текстовые — поля переменной (неопределенной) длины и сложной внутренней структуры (обычно это иерархическая последовательность типа раздел – подраздел –предложение – слово);

• бинарные — данные, интерпретируемые как поля, однако обычно физически не входящие в состав записей БД. Не­обходимо отметить, что поля данного типа (BLOB — Binary Large Object) фактически являются данными, до обработки которых данная СУБД еще «не доросла» и поэтому работа с ними возлагается на пользователя (прикладные програм­мы). В частности, в системах FoxBase и Clipper большие текстовые (так называемые MEMO) поля также не обрабатываются системой и фактически оказываются в статусе BLOB;

• типы данных, определяемые пользователем. Далеко не все современные СУБД поддерживают типы данных, опреде­ленные пользователем. Пока только СУБД Ingres включает такой механизм. Эта система предоставляет программисту возможность определять собственные типы данных и опе­рации над ними и использовать их в операторах SQL. Для определения нового типа данных необходимо написать и откомпилировать функции на языке Си, после чего собрать редактором связей некоторые модули Ingres. Отме­тим, что введение новых типов данных является, по сути, изменением ядра СУБД. Важно также то, что в Ingres типы данных, определяемые пользователем, могут быть парамет­ризованными.

Определение нового типа данных сводится к указанию ег имени, размера и идентификатора в глобальной структуре, описывающей типы данных. Чтобы с новым типом данных можн было использовать функции, которые реализуют стандартнь операции (сравнение, преобразование в различные форматы и т. д.), программист должен разработать их самостоятельно (интерфейс функций предопределен). Указатели на эти функции являются элементами глобальной структуры. Как только новый тип данных определен, то все операции выполняются над ним, как над данными стандартного типа. Разрешение пользователю создавать собственные типы данных по сути является одним из шагов развития реляционных СУБД в направлении объектно-реля­ционных систем.

Поля, указанные в заштрихованных прямоугольниках (см. 5.9) относятся к фактографическим АИС, остальные — к до­кументальным.

Физическая структура БД в общем случае имеет вид, приве­денный на рис. 5.10, и включает следующие компоненты:

• файл (файлы) исходных (первичных) данных (текстов, бинар­ных данных) содержит собственно объекты, подлежащие поиску, обработке и пр.;

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

• индекс — файл (файлы), связывающий адрес (номер) объ­екта с его содержанием (значением атрибута объекта) обычно состоит из инверсного списка и частотного словаря, который облегчает составление запросов на поиск и по­вышает обозримость БД;

• словарь данных — файл, содержащий составленное с необ­ходимой степенью подробности описание состава БД, до­кументов, записей, агрегатов данных, их имена, типы и структуры, способы интерпретации и обработки.

Изменение содержания БД может осуществляться как в ре­жиме конечного пользователя (диалоговый ввод или коррекция записей/документов по полям) — обычный для СУБД и редкий для АИПС, так и в режиме администратора БД (обычный для АИПС и реже для СУБД), при этом происходит массовый ввод или загрузка записей/документов.

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

В конкретных случаях возможна менее полная комплект­ность приведенной физической схемы:

• в фактографических (табличных) БД вторичный файл мо­жет являться основным накопителем информации, а тек­стовые и бинарные данные фигурируют в качестве необя­зательного приложения;

• в справочно-библиографических БД текстовые данные на­ходятся во вторичном файле, а первичный отсутствует;

• в БД с полнотекстовым поиском может отсутствовать вто­ричный файл, а индексирование (построение частотны словарей и инверсных списков) проводится по первичному файлу (страницы или абзацы полных текстов);

• может отсутствовать частотный словарь или инверсн список.

Надо отметить также вариативность физической реализации и взаимосвязи лингвистического и информационного обеспече­ния АИС:

• словарь данных может физически входить в информацион­ные файлы (первичный или вторичный);

• классификаторы, кодификаторы, тезаурусы могут быть оформлены как физическими файлами (файлами ОС), так и входить в состав БД в виде отдельных таблиц (файлов БД, массивов и пр.) на логическом уровне и т. п.