Методическое пособие по выполнению лабораторных работ в СУБД D3 по курсу "Проектирование баз данных"

48 Pages·2010·0.517 MB·Russian

by  Болотская Т.М., Щукин Б.А.

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ
ЯДЕРНЫЙ УНИВЕРСИТЕТ «МИФИ»

Т.М. Болотская, Б.А. Щукин

Методическое пособие
по выполнению лабораторных работ в СУБД D3
по курсу «Проектирование баз данных»

Москва 2010
УДК 004.065(07)
ББК 32.973-018.2я7
Б 79

Болотская Т.М., Щукин Б.А. Методическое пособие по выполнению лабора-
торных работ в СУБД D3 по курсу «Проектирование баз данных». М.: НИЯУ
МИФИ, 2010. 48 с.

Рассмотрены основные вопросы проектирования баз данных в СУБД D3, ори-
ентированные на использование средств, встроенных в саму СУБД, а именно про-
цессоров UPDATE и ACCESS. Приведен пример, демонстрирующий применение
этих средств при практической работе по построению прототипа информационной
системы на лабораторных занятиях.
Пособие предназначено для студентов НИЯУ МИФИ, изучающих курс «Про-
ектирование баз данных» в течение восьмого и девятого семестров факультета
«К».

Рецензент канд. техн. наук, доц. А.В. Кузовкин

Рекомендовано к изданию редсоветом НИЯУ МИФИ

ISBN 978-5-7262-1312-5 © Национальный исследовательский
ядерный университет «МИФИ», 2010

Редактор М.В. Макарова

Подписано в печать 07.07.2010. Формат 60х84 1/16
Уч.-изд.л. 3,0. Печ.л. 3,0. Тираж 100 экз.
Изд. № 055-1 Заказ № 223

Национальный исследовательский ядерный университет «МИФИ».
Типография НИЯУ МИФИ.
115409, Москва, Каширское ш., 31
Оглавление 

1.  Полуструктурированная модель данных.....................................4 
1.1.  Полуструктурированная модель данных и модель данных
СУБД D3...............................................................................................5 
1.2.  Представление полуструктурированных данных в Pick
UDM ...................................................................................................9 
1.2.1.  Как представляется класс объектов?...........................10 
1.2.2.  Как представляются связи класса объектов?..............10 
1.2.3.  Как представляются нестандартные связи объектов?12 
2.  Базовые средства проектирования в D3......................................15 
2.1.  Базы данных, поддерживаемые СУБД D3...........................15 
2.2.  Проблема разделения счетов................................................16 
2.3.  Структура счета с данными (базы данных)........................16 
2.4.  Структура программного счета...........................................18 
2.5.  Пользователь работает в счете с программами..................20 
2.6.  Пользователь работает в счете с данными..........................21 
2.7.  Пользователь работает в специальном счете......................21 
2.8.  Встроенные средства разработки D3...................................22 
2.9.  Проектирование структур файлов.......................................23 
2.10.  Моделирование процессов «вручную»...............................25 
2.11.  Сохранение и восстановление базы....................................26 
3.  Лабораторный практикум по курсу «Проектирование баз
данных»..................................................................................................28 
3.1.  Лабораторная работа 1. Разработка базы данных
многопользовательской системы....................................................28 
3.2.  Лабораторная работа 2. Использование кодов обработки в
многозначных базах данных............................................................38 
3.3.  Лабораторная работа 3. Разработка меню..........................42 
3.4.  Лабораторная работа 4. Демонстрация работы
многопользовательской системы....................................................44 
3.5. Заключение по лабораторным работам..................................46 
Список рекомендуемой литературы....................................................47
1. Полуструктурированная модель данных 

Полуструктурированная модель данных (semi-structured data
model) – определяется по-разному. Считается1, что информация,
представляемая в рамках этой модели, не разделяется на данные и
схему, т.е. происходит нивелирование различия между данными и
метаданными. Эта модель изначально была ориентирована на об-
мен данными между гетерогенными информационными системами,
так как она обеспечивает гибкий формат обмена между различны-
ми типами баз данных.
Позднее стали говорить о базах полуструктурированных данных
[1], основным свойством которых является отсутствие предписы-
вающей схемы. Многие свойства этих баз вытекают из этого фун-
даментального свойства. Заметим, что традиционно системы баз
данных, будь то реляционные или объектные, опираются на пред-
писывающую схему данных.
Для обращения к базе полуструктурированных данных исполь-
зуются описывающие схемы, каждая из которых соответствует це-
ли обращения.
Преимущества построения базы данных с использованием полу-
структурированной модели следующие:
• в рамках этой модели можно представлять данные, не
связанные некоторой предписывающей схемой;
• структурированные данные всегда можно рассматривать как
полуструктурированные, при этом вместо предписывающей схемы,
в соответствии с которой создавались данные, всегда может быть
использовано несколько описывающих схем, которые создаются
непосредственно в процессе эксплуатации.
С другой стороны, полуструктурированные данные всегда мож-
но представить как структурированные, переходя на более высокий
уровень абстракции при отображении предметной области. Напри-
мер, данные, представленные в соответствии с RDF-моделью2,
можно рассматривать как реляционную таблицу с атрибутами

1 Semi-structured data model, http://en.wikipedia.org/wiki/Semi-structured_model
2 RDF 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.

Таблица 1

Системные разделители, используемые в СУБД D3

Назначение ASCII HEX DEC
Разделитель записей _ FF 255
Разделитель полей ^ FE 254
Разделитель значений ] FD 253
Разделитель подзначений \ FC 252

Замечание. Не путайте 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> =
“Болконский\Андрей]Ростова\Наташа]Безухов\Пьер”
Item<2,1> = “Болконский\Андрей”
Item<2,1,1> = “Болконский”
Item<2,1,2> = “Андрей”
Item<2,2> = “Ростова\Наташа”
Item<2,2,1> = “Ростова”
Item<2,2,2> = “Наташа”
Item<2,3> = “Безухов\Пьер”
Item<2,3,1> = “Безухов”
Item<2,3,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

ЛИЧНОСТЬ ЛИЧНОСТЬ

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