Диплом К

Табл. 5. Список стандартных типов ключей

БД теперь не имеет логической структуры, которая перенесена на уровень доку-

ментов, и представляет собой “рабочий стол” документов, которые в принципе могут образовывать в рамках одной БД сложную иерархию. Документы могут иметь совер-

шенно различный внутренний формат, но, тем не менее, записываться в БД по единому механизму.

Осуществление взаимодействия между документами, после их считывания из БД,

производится с помощью механизма рассылки сообщений с определенными параметра-

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

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

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

Естественно, что за новые возможности надо платить. В нашем случае плата – это хранение структуры у каждого объекта1, что увеличивает объем файла данных.

3.5.1. Возможные области применения.

Наиболее подходящими являются задачи двух классов:

ориентированные на сложный поиск в слабо формализованных предметных об-

ластях;

часто изменяющиеся, но формализованные предметные области.

В качестве примеров первого класса можно привести различные медицинские,

юридические, образовательные, библиотечные задачи. Во всех них содержимое доку-

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

ременного размера, требуется осуществление полноценного текстового поиска, жела-

тельно по запросам, заданным на естественном языке.

1Реляционные БД хранят логическую структуру БД один раз, обычно в начале файла данных, так

как она одинакова для всех записей.

Вторые задачи могут иметь четкое разбиение содержимого документов на поля, но это разбиение может часто меняться. Примеры – банковские, бухгалтерские и биржевые задачи. Здесь на момент изменения структуры документа, БД уже может содержать де-

сятки тысяч документов, поэтому требование реорганизации всех записей при измене-

нии логической структуры БД является неприемлемым.

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

3.5.2. Почему разработанная СУБД не является реляционной?

Разработанная СУБД предназначена для работы с неструктурированной инфор-

мацией и не являются реляционной базой данных по определению. В любой реляцион-

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

кими таблицами, необходимые для выполнения этих функций, зафиксированы и четко определены. Конечно, это касается не теории реляционных СУБД, а их реализации.

4. ИССЛЕДОВАТЕЛЬСКАЯ ЧАСТЬ

4.1. Исследование реализации файла данных

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

4.1.1. Анализ компактности размещения записей переменной длины.

Основным предназначением разработанной реализации файла данных является хранение записей переменного размера. Естественно, что для этого надо идти на какие-

то накладные расходы при организации хранения информации. В результате длина фай-

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

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

Для первой страницы в цепочке введен термин головная, а для остальных – термин хво-

стовая. Широко известным примером такого подхода является организация хранения файлов на внешних носителях в операционной системе MS-DOS. В нашей реализации в качестве названия сегмента используется термин страница.

Оценим теоретически величину накладных расходов при хранении записей пере-

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

ляющие:

заголовок записи;

заголовки страниц (для каждой страницы);

незаполненная часть на последней хвостовой странице.

Для исходных величин введем следующие обозначения:

L - длина записи,

Lстр - длина страницы,

pз - длина заголовка записи,

pстр - длина заголовка страницы.

Тогда число страниц в одной записи (n) можно рассчитать следующим образом:

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

ных.

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

тервале. Для эксперимента примем, что размер записей является равномерно распреде-

ленной случайной величиной в интервале от 200 до 30000 байт. По результатам экспе-

римента были построены графики, показанные на рисунках 26 и 27. Результаты экспе-

римента показывают, что доля служебной информации колеблется от 4% до 17%, в за-

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

це.

4.1.2. Время выполнения базовых операций с записями.

В качестве основных были выбраны наиболее часто используемые операции: до-

бавление новой записи, удаление существующей и чтение заданной. Рассмотрим каж-

дую в отдельности, а результаты помести на один график.

В значение времени для операции добавления входит две составляющие: время по-

зиционирования на нужную страницу и время записи данных на страницу. Обозначим их соответственно tп и tз. Время записи tз можно принять постоянной величиной (для нашей аппаратной платформы), даже при изменении длины страницы. Время позицио-

нирования tп линейно зависит от номера страницы (смещения от начала файла). Таким образом для одной страницы имеем:

где l - время позиционирования до начала файла данных, nстр - порядковый номер запи-

сываемой страницы, k - коэффициент времени позиционирования, физический смысл которого – время позиционирования на следующую страницу файла данных. Эти три величины определяются параметрами аппаратной части.

Тогда время добавления записи будет подчиняться следующему закону:

где n - число страниц, на которых разместится запись, а ni - порядковый номер i-ой страницы. Расчет n проводится по формуле (1). В итоге мы имеем линейную зависи-

мость времени добавления от числа страниц, на которых разместится запись, и от поло-

жения, которое займет новая запись в файле данных (наиболее часто - это место за кон-

цом файла). Все расчеты проводились в предположении, что на запись каждой страни-

цы требуется одна операция ввода-вывода.

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

цы: головная страница записи и последняя страница из списка свободных страниц. Та-

ким образом можно, используя уже введенные обозначения записать выражения для времени удаления: