Болотская Методическое пособие по выполнению лабораторных 2010

Оглавление

1.1.Полуструктурированная модель данных и модель данных

1.2.Представление полуструктурированных данных в Pick

1.2.3.Как представляются нестандартные связи объектов?12

3.Лабораторный практикум по курсу «Проектирование баз

3.1.Лабораторная работа 1. Разработка базы данных

3.2.Лабораторная работа 2. Использование кодов обработки в

3.4.Лабораторная работа 4. Демонстрация работы

1.Полуструктурированная модельданных

Полуструктурированная модель данных (semi-structured data model) – определяется по-разному. Считается1, что информация, представляемая в рамках этой модели, не разделяется на данные и схему, т.е. происходит нивелирование различия между данными и метаданными. Эта модель изначально была ориентирована на обмен данными между гетерогенными информационными системами, так как она обеспечивает гибкий формат обмена между различными типами баз данных.

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

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

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

•в рамках этой модели можно представлять данные, не связанные некоторой предписывающей схемой;

•структурированные данные всегда можно рассматривать как полуструктурированные, при этом вместо предписывающей схемы,

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

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

уровень абстракции при отображении предметной области. Например, данные, представленные в соответствии с RDF-моделью2,

можно рассматривать как реляционную таблицу с атрибутами

1Semi-structured data model, http://en.wikipedia.org/wiki/Semi-structured_model

2RDF Primer / W3C - http://www.w3.org/TR/2004/REC-rdf-primer-20040210

4

«Объект», «Свойство», «Значение» и оперировать этими данными с помощью языка SQL.

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

Чтобы иметь возможность устранить этот недостаток, если он существенен, полуструктурированные модели данных делят на тя-

желовесные (heavyweight) и легковесные (lightweight) [1].

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

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

1.1.Полуструктурированная модель данных и модель данных СУБД D3

Модель данных, используемую в СУБД D3, вполне можно отнести к тяжеловесным моделям полуструктурированных данных.

Во-первых, в соответствии с ней можно построить запись со строго структурированной частью, в которой каждое поле интерпретируется однозначно. Например, если поле 2 выделено для фамилии личности, то в любой записи в этом поле будет стоять фамилия. Оставшаяся «полуструктурированная» часть записи может состоять из пар полей, при этом в каждой паре первое поле будет содержать некоторую метаинформацию, например имя атрибута, в соответствии с которым интерпретируется второе поле пары.

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

5

Замечание. При обработке средствами СУБД D3 данных windows папка рассматривается как область данных файла СУБД D3, а каждый файл в папке как запись.

Модель данных СУБД D3 оригинальна. В разное время ее называли расширенной реляционной моделью (extended relational data model), после выхода статьи [3] стали называть постреляционной моделью данных (postrelational data model), а в настоящее время именуют Pick Universal Data Model (Pick UDM)3.

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

Файлы состоят из записей переменной длины. Каждая запись файла, будь то словарь или область данных, представляет собой строку переменной длины, которая получается при сохранении в долговременной памяти трехмерного динамического массива – основной структуры, с которой приходится оперировать при написании программ обработки (отсюда название – D3). Слово «динамический» означает, что границы измерений априорно не определены и могут быть сколь угодно большими.

Первое измерение динамического массива соответствует полям записи. Таким образом, количество полей в записи не ограничено и заранее не оговаривается. Каждое поле – строка переменной длины.

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

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

3 Pick Universal Data Model (Pick UDM) – http://www.tigerlogic.com

6

Структуризация строк осуществляется с помощью специальных выделенных кодов из ASCII-алфавита. Эти коды представлены в табл. 1.

Замечание. Не путайте ASCII-представление символов разделителей с самими символами, изображаемыми этими значками. Например, значок «_» как символ «подчеркивание» имеет код ASCII HEX: 5F; DEC: 95; и может быть использован в пользовательских данных, например в именах атрибутов. Разделители в пользовательских данных появляться не могут.

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

Таким образом, в рассматриваемой модели поддерживается единственный тип данных – строка переменной длины. Все средства СУБД D3 оптимизированы для работы с этим типом данных. В то же время в СУБД D3 запись может быть двоичным объектом, какими являются откомпилированные программы, или такие сохраненные внешние файлы, как файлы изображений или докумен-

ты MS Word.

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

Item<i,j,k>.

Пусть, например, имеем запись в области данных файла «Персонажи произведений Льва Толстого», представляемую строкой:

7

1^Война и мир^Болконский\Андрей]Ростова\Наташа ]Безухов\Пьер_;

Тогда получим значения всех элементов структуры данных, которые представлены на рис. 1.1.

Item<0> = 1

Item<1> = “Война и мир” Item<2> =

“Болконский\Андрей]Ростова\Наташа]Безухов\Пьер”

Рис. 1.1. Значения всех элементов структуры данных

Таким образом, из алфавита D3 выделены символы разделителиразделители записей, полей, значений и подзначений – это последние четыре символа ASCII. Так как их использование зарезервировано, то они не могут появляться в пользовательском тексте.

Заметим, что термин «основная память» взят в кавычки. D3 работает с виртуальной памятью, которая образуется из основной памяти и всего свободного дискового пространства.

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

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

8

Если поле записи определяется номером (цифрой натурального ряда – 0,1,2,…), то атрибут – именем. Имя атрибута – идентификатор записи, определяющей атрибут в словаре файла. Пусть определен атрибут «Name» на поле с номером 2. Это значит, что в словаре определена запись с идентификатором «Name» (значение поля 0 = “Name”), в которую включена ссылка на программный модуль, выполняющий некоторое функциональное преобразование, например, выделяющее имя как второе подзначение значения поля. В этом случае значения атрибута «Name» будут следующими:

Name: Андрей]Наташа]Пьер

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

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

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

1.2.Представление полуструктурированных данных в Pick UDM

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

•объекты;

•свойства объектов;

9

•связи;

•свойства связей.

Однородные объекты объединяются в классы.

1.2.1. Как представляется класс объектов?

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

Рассмотрим для примера класс ЛИЧНОСТЬ, который представим именем класса и совокупностью имен атрибутов:

ЛИЧНОСТЬ(Nсв, Фамилия, Имя, Отчество, Пол,

ДатаРожд, ...)

Представленные атрибуты Nсв – «Номер свидетельства о рождении» и другие – характеризуют собственно личность как таковую. Это четко выраженные атрибуты, которые применимы к любой личности, именно поэтому их целесообразно выделить на уровне описания класса.

1.2.2. Как представляются связи класса объектов?

Так как у каждой личности есть родители, то эта связь объектов достойна того, чтобы быть вынесенной на уровень связи классов

(рис. 1.2).

Рис. 1.2. Связь между объектами, вынесенная на уровень связи классов

10