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

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

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

Методическое пособие по выполнению лабораторных работ в СУБД 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 2

Semi-structured data model, http://en.wikipedia.org/wiki/Semi-structured_model 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 FF FE FD FC

DEC 255 254 253 252

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

Поле с номером 0 каждой записи (единственное поле, которое может иметь только одно неструктурированное значение) должно содержать уникальный ключ, по которому на основе встроенной хэш-функции производится размещение записи в памяти системы и доступ к ней. Таким образом, в рассматриваемой модели поддерживается единственный тип данных – строка переменной длины. Все средства СУБД D3 оптимизированы для работы с этим типом данных. В то же время в СУБД D3 запись может быть двоичным объектом, какими являются откомпилированные программы, или такие сохраненные внешние файлы, как файлы изображений или документы MS Word. В дальнейшем будем говорить только о записях с текстовыми данными. Любая запись, считываемая из таблицы базы данных в некоторую переменную «основной памяти», например переменную Item, принимает структуру динамического массива, к элементам которого можно обращаться по целочисленным индексам: Item. Пусть, например, имеем запись в области данных файла «Персонажи произведений Льва Толстого», представляемую строкой: 7

1^Война и мир^Болконский\Андрей]Ростова\Наташа ]Безухов\Пьер_; Тогда получим значения всех элементов структуры данных, которые представлены на рис. 1.1. Item = 1 Item = “Война и мир” Item = “Болконский\Андрей]Ростова\Наташа]Безухов\Пьер” Item = “Болконский\Андрей” Item = “Болконский” Item = “Андрей” Item = “Ростова\Наташа” Item = “Ростова” Item = “Наташа” Item = “Безухов\Пьер” Item = “Безухов” Item = “Пьер” Рис. 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

Как же отражается эта связь на структуре класса ЛИЧНОСТЬ в представлении класса средствами СУБД D3? Для этой цели в словаре определяется атрибут «Родители»: ЛИЧНОСТЬ(Nсв, Фамилия, Имя, Отчество, Пол, ДатаРожд, Родители...) а в области данных вводится поле, имеющее максимум два значения. Это поле содержит ключи записей родителей как объектов класса ЛИЧНОСТЬ. Если родители конкретной личности представлены в базе данных, то эта личность для них является ребенком (рис. 1.3). 1

Родители

2

ЛИЧНОСТЬ

ЛИЧНОСТЬ N

Дети

0

Рис. 1.3. Производная связь на уровне классов

Связь «Дети» – производная: как только зарегистрирована некоторая «Личность», то у ее «Родителей» (у каждой «Личности», как матери, так и отца) ссылка на эту «Личность» автоматически должна появиться в качестве значения атрибута «Дети». На уровне области данных файла ЛИЧНОСТЬ запись на конкретный объект будет выглядеть примерно так, как показано на рис. 1.4. Как видно из примера (см. рис. 1.4) в поле 006, на котором определен атрибут «Родители», реально хранятся ключи записей на отца и на мать. Атрибут «Родители» может быть определен как преобразование этих ключей к виду: Иванов И.А.]Иванова М.В. На этом же поле 006 можно определить атрибут «Дата_Рождения_Родителей» и т.д. 11

ЛИЧНОСТЬ 000 N124 001 002 003 004 005 006 007

Иванов Иван Иванович м 10200 N089]N063

- запись - Номер свидетельства о рождении (Ключ) - Фамилия - Имя - Отчество - Пол - Дата Рождения - Ключ записи отца]Ключ записи матери - Детей нет

Рис. 1.4. Пример записи области данных файла ЛИЧНОСТЬ

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

1.2.3. Как представляются нестандартные связи объектов? На уровне связи классов декларируется возможность произвольных связей между объектами. Например, между личностями можно декларировать наличие «Других Связей» (рис. 1.5). 12

ЛИЧНОСТЬ

1

Другие связи

N

ЛИЧНОСТЬ

Рис. 1.5. Нестандартные связи между объектами

Любая такая связь характеризуется именем (типом), возможно еще какими-то свойствами. На уровне атрибутной структуры класса это выглядит следующим образом: ЛИЧНОСТЬ(Nсв, ..., Дети, ДругиеСвязи, ТипДругойСвязи) «ДругиеСвязи» и «ТипДругойСвязи» это жестко связанные многозначные атрибуты: при удалении значения из атрибута «ДругиеСвязи» автоматически удаляется соответствующее значение из атрибута «ТипДругойСвязи». На уровне области данных файла ЛИЧНОСТЬ запись на конкретный объект будет выглядеть примерно так, как показано на рис. 1.6. ЛИЧНОСТЬ 000 N124 001 002 003 004 005 006

Иванов Иван Иванович м 10200 N089]N063

007 008 N145]N165]N165 009 1]7]7

- запись - Номер свидетельства о рождении (Ключ) - Фамилия - Имя - Отчество - Пол - Дата Рождения - Ключ записи отца]Ключ записи матери - Детей нет - Другие связи - Тип Другой Связи

Рис. 1.6. Пример записи области данных файла ЛИЧНОСТЬ с нестандартными связями 13

На уровне атрибутов два последних поля могут быть представлены так: ДругиеСвязи Смирнова С.И. Алексеев В.Ф. Глазунов А.Ю.

ТипДругойСвязи Гражданский брак Одноклассники Одноклассники

Наиболее полно идее «полуструктрированности» соответствует модель данных RDF, представляемая графом общего вида. Однако и эти данные на метауровне задаются четкой структурой: «Объект», «ИмяСвойства», «ЗначениеСвойства». Эта структура универсальна, но оперировать полуструктурированными данными объективно сложнее, чем структурированными. Это естественно относится и к манипулированию полуструктурированными данными в модели Pick UDM.

14

2.

Базовые средства проектирования в D3 

2.1.

Базы данных, поддерживаемые СУБД D3

Название СУБД D3 или D3 создает ассоциации, связанные с объемом, подчеркивая, что используемая в ней структура данных отличается от «плоской» структуры данных реляционных СУБД. В мире пользователей D3 для базы данных принято название «счет», или «account». Считается, что база данных СУБД D3 состоит из «таблиц». Однако это не таблицы реляционной базы данных. Можно сказать, что D3 работает с ненормализованными таблицами, в которых каждое поле может содержать несколько значений. Более того, для компонентов базы данных D3 таблица – не очень удачная абстракция, так как в общем случае каждая строка таблицы может содержать разное количество полей. Таблицы, принятые в реляционной базе данных, естественно представляются в СУБД D3, при этом с ними можно работать как с «родными» средствами D3, так и с помощью SQL, правда через интерфейс ODBC. Стандартно принимается, что каждая таблица D3 реализуется двумя файлами: словарем (dict) и областью данных (data). На самом деле при конкретном словаре можно создавать сколько угодно областей данных, в том числе и ни одной, однако нельзя создать только отдельную (т.е. вне связи с каким-либо словарем) область данных. С другой стороны, одна и та же область данных может обрабатываться, ориентируясь на определения разных словарей. Таким образом, реальные таблицы D3 могут быть далеки от стандартных. Традиционно программы в D3, написанные на языке FlashBasic, хранятся в стандартной таблице, т.е. имеющей как словарный файл, так и файл с областью данных. Исходный текст программы хранится в области данных, откомпилированный модуль – в словаре.

15

2.2.

Проблема разделения счетов

Прикладная система, построенная на основе D3, должна состоять как минимум из одного счета или из одной базы данных, содержащей как таблицы с данными, так и, по крайней мере, одну таблицу с программами. На практике в настоящее время в прикладных системах часто удобно отделять данные от программ, т.е. иметь счета с данными (истинную «базу данных») и счета с программами. СУБД D3 ориентирована на построение подобных «n-уровневых» систем. На практике наиболее часто разрабатываются двухуровневые системы, которые состоят по меньшей мере из счета с данными и счета с программами. В рамках программного счета сосредотачивается вся логика функционирования системы и определяется структура данных. Как сейчас принято говорить – «бизнес правила». Именно здесь должны находиться все словари для определения атрибутов. В счете с данными должны храниться данные и более ничего, это есть истинная «база данных». Счетов с данными может быть несколько. Это одна из разновидностей двух уровневых систем. Рассмотрим кратко структуру информационных систем, построенных с использованием СУБД D3, в зависимости от того, в каком счете «работает» пользователь. Пользователь может работать:

• в программном счете; • в счете с данными; • в специальном счете пользователя. В зависимости от того, в каком счете работает пользователь, строятся главные словари (MD) разделенных счетов.

2.3.

Структура счета с данными (базы данных)

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

совершенно не нужны, фактически для него можно отвести всего 1 фрейм, оставив минимум необходимых глаголов, так как только изредка нужно будет заходить непосредственно в счет данных. При таком «максималистском» подходе в счете должен быть определен один единственный словарь с модуло, равным 1 (в крайнем случае, 3). В этом словаре должны быть «прописаны» все файлы с данными и находиться только записи определения файлов данных (File Defining Item – FDI). Никаких определений атрибутов. Чтобы создать такой счет, воспользуйтесь глаголом accountmaint, определив модуло счета (т.е. главного словаря), равный 1. После создания счета войдите в него, с помощью sselect создайте список всех записей MD созданного счета и сохраните его, например в pointer-file. Откорректируйте список, удалив из него следующие слова: logto, md, to, off. Они нужны, чтобы выйти из счета, если вошли в него. Это минимум-миниморум, хотите оставить еще что-нибудь – оставляйте, но не увлекайтесь. Можно оставить утверждения для работы с файлами: create-file, delete-file, data, dict, create-index, delete-index, clear-file, clear-index, create-file, create-index, istat, hash-test. Чтобы просмотреть список файлов с помощью макроса lf, оставьте *a1, dictionary-code, lf, list-files, sselect, with. Оставьте утверждение who. Этими утверждениями заполнили фрейм, отводимый под MD, примерно наполовину. После сохранения с помощью get-list активизируйте список и глаголом delete уничтожьте соответствующие записи в MD, а затем и сам список, правда последнее сможете сделать только из другого счета, например из DM. Сделав один раз такой MD, потом сможете копировать его сколько угодно. Все корректировки, в том числе и записей FDI, будете делать из рабочего счета. Таким образом, одного фрейма для MD-счета с данными более чем достаточно. Один фрейм для простого словаря позволяет сохранить примерно 40 записей описания файлов данных (FDI). Если файлов больше, нужна более емкая первичная область словаря. Три фрейма позволяют сохранить примерно 120 ссылок на области данных, не вылезая за пределы первичной области. 17

Первичная область каждого файла с данными должна быть такой, какой она должна быть. Воспользуйтесь глаголами istat, hash-test для моделирования распределения своих записей по группам и выбирайте модуло области данных таким, каким они его рекомендуют. Помните, однако, что делать счет с данными очень большим не следует: необходимо соизмерять его объем с возможностями сохранения. Вполне возможно, что в конкретных условиях лучше иметь несколько счетов с данными умеренного объема. Итак, обсудили структуру автономного счета с данными.

2.4.

Структура программного счета

Как выглядит стандартный программный счет, в котором не работает пользователь? Это определяется его назначением: хранить общие, совместно используемые программы и атрибуты. Прежде всего, в нем должна быть определена стандартная таблица, содержащая программы. Напомним, что исходные тексты программ находятся в области данных, а откомпилированные модули – в словаре. Ничего кроме программ в этой таблице не должно находиться. Специальных словарей для определения атрибутов должно быть столько, сколько необходимо! Подчеркнем еще раз, что эти словари определяются без областей данных. Сколько должно быть словарей? Это в значительной степени – дело вкуса. Можно создать один большой словарь и свалить туда все. Другая крайняя точка зрения – создать по одному однофреймовому словарю специально для каждого экрана. В системной документации по D3 понятия «атрибут», «поле» рассматриваются как синонимичные. И то, что хранится непосредственно в записи, – атрибут и сложнейшее функциональное преобразование хранимых значений – тоже атрибут. Будем называть полем то, что непосредственно хранится в записях файлов, а функциональное преобразование значений полей – атрибутами. Поле полностью определяется порядковым номером и поле с этим номером всегда одно. Атрибутов, связанных с конкретным полем, может быть сколько угодно. Каждый атрибут имеет уникальное имя и 18

определяет конкретное функциональное преобразование содержимого поля или совокупности полей. Атрибут чрезвычайно мощное понятие D3, используемое всеми системными процессорами для ссылок на данные, а декларативный способ определения атрибута в словарях делает его очень удобным для практической работы. Для связи с файлами базы данных используются так называемые Q-указатели. Следовательно, в программном счете, а именно в MD, должны быть определены указатели на все необходимые файлы данных. Структура Q-указателя очень проста. Приведем пример Qуказателя из счета «Program» на файл «Team» счета «Football». Для этого в главном словаре счета «Program» нужно создать запись с именем «Team»: :u 01 02 03

md Team Q Football Team

Связь словарей с конкретными файлами данных осуществляется в рамках следующего синтаксиса: ГЛАГОЛ Q-указатель сок_атрибутов ОПЦИИ

USING

DICT

имя_словаря

спи-

Например, LIST Материалы USING DICT КлЦенник Код Название ЕдИзм Цена (h где «Материалы» – имя Q-указателя, определенного в MD программного счета; «КлЦенник» – имя словаря в программном счете; «Код», «Название», «ЕдИзм», «Цена» – имена атрибутов, определенных в словаре «КлЦенник». Кроме указанных компонентов, в MD программного счета можно определять меню и макросы.

19

2.5.

Пользователь работает в счете с программами

Данная ситуация предполагает, что единая база данных трактуется пользователем или группой пользователей достаточно своеобразно. Это выливается в то, что программный и атрибутный состав достаточно уникален для каждой группы и интересен только пользователям этой группы. Например, в случае хранения в базе данных описаний конкретных объектов каждый программный счет – конкретный функциональный взгляд на базу данных, который имеет конкретный пользователь или группа пользователей. Эти точки зрения могут пересекаться, но не должны совпадать. Все определяется тем, насколько четко определены функции соответствующих подразделений. Рабочими счетами в этом случае являются программные счета. В MD этих счетов, которые в данной ситуации должны быть полноценными, должны находиться ссылки (Q-указатели) на файлы базы данных. В каждом программном счете должны быть объявлены словари для определения атрибутов, соответствующих потребностям обслуживаемой функции. Обязательно должны быть определены одна или несколько рабочих таблиц. Рабочие таблицы необходимы для хранения самых разнообразных списков, промежуточных записей, которые наверняка потребуются в процессе функционирования системы. При этом постоянные списки и другие записи многократного использования следует хранить в словарях, а рабочие фрагменты текущего сеанса – в области данных. В этом нет слишком глубокого смысла, это просто добровольные соглашения, которые, однако, способствуют взаимопониманию разработчиков. В качестве обязательной составляющей любого рабочего счета должны быть меню и, возможно, макросы. Еще раз отметим, что в этом случае вся работа пользователей осуществляется в счетах с программами.

20

2.6.

Пользователь работает в счете с данными

В ряде случаев более адекватна ситуации другая точка зрения на разделение счетов: программный счет сделать базовым, общим, а счета с данными – индивидуальными, пользовательскими. В этом случае данные должны быть более динамичными, но и более однородными в разных счетах. Это значит, что в разных счетах обрабатываются файлы с одними и теми же именами, с идентичными атрибутами. Например, в случае использования CASE-технологии для проектирования приложений каждый счет с данными – отдельный проект, который ведет конкретный разработчик или группа разработчиков. Программный счет в этом случае – поддержка единой методологии проектирования с конкретной программной реализацией. Рабочими счетами являются счета данных. В MD этих счетов, которые в этом случае должны быть полноценными, должны находиться ссылки (Q-указатели) на словари программного счета и на используемые программы (т.е. программы должны быть каталогизированы в счетах данных). Обязательно должны быть определены одна или несколько рабочих таблиц. Рабочие таблицы необходимы для хранения самых разнообразных списков, промежуточных записей, которые, наверняка, потребуются в процессе функционирования системы. При этом постоянные списки и другие записи многократного использования следует хранить в словарях, а рабочие фрагменты текущего сеанса – в области данных. В этом нет слишком глубокого смысла, это просто добровольные соглашения, которые, однако, способствуют взаимопониманию разработчиков. Именно так предлагается разделять счета в генераторе приложений SB+. Еще раз отметим, что в этом случае вся работа пользователей осуществляется в счетах с данными.

2.7.

Пользователь работает в специальном счете

В настоящее время очень популярной становится трехуровневая структура, при которой наряду с общим счетом с данными, общим 21

программным счетом, выделяются специальные рабочие счета для пользователей. Говорят, что это придает максимальную гибкость системе. К слову, D3 предоставляет среду для создания n-уровневых приложений. На практике могут встретиться самые разнообразные варианты. Мы рассмотрели более или менее подробно два противоположных. Каждый случай уникален! Для того и учат разработчиков, чтобы они принимали грамотные решения в конкретных ситуациях.

2.8.

Встроенные средства разработки D3

К встроенным средствам разработки прикладных систем D3 следует отнести: • UPDATE-процессор; • ACCESS-процессор; • OUTPUT-процессор; • процессор меню; • макропроцессор; • Flash-Basic. Это то, что имеем, устанавливая D3. Для использования этих средств не надо покупать никаких дополнительных лицензий. Все эти процессоры написаны на виртуальном ассемблере и работают весьма эффективно. С помощью них можно создавать довольно серьезные приложения, однако они будут иметь следующие ограничения: 1) символьный экранный интерфейс (эти средства не приспособлены для работы в графическом интерфейсе); 2) довольно архаичный клавиатурный интерфейс (это ограничение можно в значительной степени преодолеть, перекодируя поток от клавиатуры либо аппаратурно, либо программно). Поэтому встроенные средства целесообразно применять для быстрого прототипирования приложений, используя Flash-Basic для склеивания отдельных частей приложения, придания ему вида единого процесса. Flash-Basic также необходим для реализации отклика на нажатие функциональных клавиш. Разрабатывать приложения на одном Flash-Basic не рекомендуется: это доро22

го, а результата, отвечающего современным требованиям, получить все равно не удастся. Современный подход к реализации прикладных систем – так называемое событийное программирование. Создается некая среда, которая «чувствует» определенные события в системе и позволяет разработчику откликнуться на эти события. Таким образом, устроены все языки уровня 4GL, в частности мощнейший генераторинтерпретатор кода SB+, таким же образом устроен Visual Basic от Microsoft. Однако все они требуют покупки лицензии. Единственным встроенным процессором, который позволяет реагировать на некоторые события в прикладной системе, является UPDATE-процессор. Какие же события отслеживает UPDATE -процессор? 1. Событие считывания записи из файла. Точка входа для программной реакции: input-conversion FDI. 2. Событие сохранения записи в файле. Точка входа для программной реакции: correlative FDI. 3. Событие нажатия функциональной (горячей) клавиши в поле ввода. Точка входа для программной реакции: hotkeys FDI,ADI. Это нечто вполне осязаемое. Следовательно, в основе прототипирования прикладной системы встроенными средствами разработки должен лежать UPDATE-процессор. Весьма существенен также тот факт, что UPDATE-процессор работает как процессор данных, используя атрибуты для ссылок на данные. Это определяет в значительной степени декларативный характер разработки, обеспечивая уникальные возможности для модификации и модернизации приложений, ибо всю семантику можно заложить в определения атрибутов.

2.9.

Проектирование структур файлов

СУБД D3 предоставляет чрезвычайно гибкие средства для представления информации. На средних объемах файлов (порядка нескольких тысяч записей) ошибки в физических структурах файлов не особенно заметны для потребителей. Тем не менее настоятельно рекомендуется тщательно продумать структуру своих данных и 23

зафиксировать свое представление о ней в так называемой ERдиаграмме или диаграмме классов. Отображение построенной логической структуры данных в реальные файлы D3 можно выполнить десятками способов. D3 все стерпит и будет работать! Но прежде чем принимать конкретные решения, постарайтесь ответить на следующие вопросы. 1. D3 позволяет хранить записи любой длины и практически любой сложности. Очень часто в реальных системах приходится видеть записи с очень большим количеством полей, что, однако, не вызвано необходимостью. Если запись содержит десятки полей, практически, наверняка, их можно разнести по нескольким файлам. Очень важно понимать, что с точки зрения просмотра и печати данных словарная система D3 позволяет видеть данные в любых разрезах, независимо от того, где они реально находятся. Для пользователя это всегда один файл. С точки же зрения ввода и корректировки данных желательно, чтобы один экран вводакорректировки по крайней мере в незаполненном состоянии не превышал физических размеров экрана. Обычно запись файла представляет некоторый объект информационной системы, а поля – свойства этого объекта. Разделить свойства объекта по семантической близости и разнести их по записям разных файлов, используя один и тот же идентификатор объекта (ключ записи) – дело вполне естественное и оправданное. Итак, чем оправдывается необходимость «сотни» полей в структуре записи физического файла? 2. Файлы данных ни в коем случае не должны содержать никаких полей, служащих оформительским целям. Все оформительские детали экранов ввода, отчетов должны храниться в словарях файлов. Итак, все ли поля данных действительно информативны? 3. Любое поле файла данных может быть закомментировано! Но все комментарии должны быть вынесены в специальный файл и не должны храниться вместе с основными данными. Более того, некоторые поля текстового характера, вроде бы являющиеся основными, целесообразно оформлять как комментарии. Например, поле для атрибута «Название_Объекта» можно оставить в основной структуре, а поле для атрибута «Описание_Объекта» лучше оформить как комментарий к названию, или еще как-нибудь, но удалить из основного файла. 24

Итак, все ли текстовые поля действительно необходимо иметь в основной структуре? Нельзя ли их оформить как комментарии? 4. Первое поле в записи – самое доступное. Это истина! Поля, по которым наиболее часто производится выборка записей, которые чаще используются для вывода и т.д., должны быть первыми полями в записи (входить в первую десятку). Поиск и выборка возможны по любому полю, но по первым полям они более эффективны, особенно, если нет индекса. Создание индексов по отдаленным полям существенно убыстряет поиск по ним. Итак, продуман ли порядок расположения полей в записи? 5. Значения полей по возможности должны быть стандартизованы. Плохо, когда в одной записи стоит «Пушкин А.С.», в другой – «Ал.Серг.Пушкин», а в третьей – «Пушкин Александр Сергеевич» и т.д. Предпочтительно использование системных справочниковкодификаторов, определенных как стандарты для отрасли, для страны, как международные стандарты. Итак, определились ли с кодировочными справочниками? Разумеется, этим не исчерпываются все вопросы анализа структур файлов. Конкретные ситуации ставят конкретные вопросы. Не страшно, если не учли мелких деталей, важно не делать грубых ошибок.

2.10. Моделирование процессов «вручную» Все процессы обработки данных, которые будут связаны непосредственно с основными таблицами из счетов с данными (т.е. именно с базой данных), должны выполняться UPDATE-, ACCESS- и OUTPUTпроцессорами и проходить исключительно на атрибутном уровне. Удерживайте себя от соблазна обрабатывать непосредственно физические поля с помощью процедур Flash-Basic. Если не согласны с этим тезисом, то лучше сразу работать с Visual Basic от Microsoft и библиотеками ODBC или RPC (Win32), по крайней мере хоть получите графический интерфейс. Дальнейшее чтение этого раздела целесообразно в том случае, если согласны с этим тезисом! Прежде всего, необходимо промоделировать все процессы обработки данных «вручную» на уровне TCL. Создайте необходимое множество атрибутов. Для ввода данных запишите соответствую25

щие UPDATE-утверждения. Для простейшего вывода – ACCESSутверждения, в частности для вывода в файл используйте глагол reformat. Проведите все необходимые сортировки, поиск, сравнения, работая со списками. Для более рафинированного вывода используйте OUTPUT-процессор. Выполняя все это, работайте с базовыми, фундаментальными средствами D3. Они должны работать абсолютно надежно. Если на установке эти средства работают ненадежно, то переходить к различным надстройкам вообще не имеет никакого смысла. Далее следует уяснить уровень «настраиваемости» приложения, который от нас, как от разработчика, ожидают. Должно ли приложение настраиваться на группы пользователей, а степень его вариабельности быть в пределах каждой группы? Для этого надо понять технологию работы с данными каждой группы и т.д. В конце концов, все сводится к различным сортировкам и вариациям атрибутного состава экранов ввода-корректировки и отчетов. Именно для того, чтобы обеспечить «настраиваемость» приложения, необходимо выйти на уровень Flash-Basic. Мы говорим о технологии разработки путем создания прототипов. Это обычная практика разработок «изнутри», когда в организации имеется отдел разработки и эксплуатации информационной системы. В этом случае не пишут громоздких постановок, чаще всего их вообще нет. Приложение «притирается» в процессе эксплуатации к реальным потребностям путем перманентной модернизации. Можно считать это этапом постановки задачи. После того, как приложение «притрется», можно говорить о более тщательном перепрограммировании его. Правда, реально это осуществляется очень редко.

2.11. Сохранение и восстановление базы Как сохранить разработанную базу данных? Мы находимся в разработанном нами счете (базе данных) D3, например с именем «Sklad». Требуется сохранить базу данных «Sklad» на носителе, внешнем по отношению к D3, например на нашей флешке. Исторически сложилось так, что внешними носителями для D3 считаются ленты. При установке СУБД D3 на нашем компьютере в выбранном нами месте была создана папка D3, в которой находится 26

папка D3Virtual. Именно в файл pseudo0.d3p этой папки, моделирующий ленту, и будет выгружаться наш счет. Перед началом сохранения счета рекомендуется удалить файл, pseudo0.d3p, так как он, возможно, содержит ранее сохраненные счета и наш счет будет записан в хвост ленты. Для сохранения счета «Sklad» требуется выполнить следующие действия: Выполняемая команда :to dm :set-device 2

:t-rew :account-save Sklad :t-det

Комментарий Переход в счет dm ! Происходит захват файла pseudo0.d3p. Если такого файла нет в папке D3Virtual, то он создается «Лента» подматывается в начало Счет Sklad записывается в файл pseudo0.d3p Файл pseudo0.d3p освобождается и может быть скопирован на флешку. Для выхода из D3 рекомендуется выполнить команду shutdown

Как восстановить разработанную базу данных? Наша база данных (счет) «Sklad» находится на внешнем носителе (флешке) в виде файла windows pseudo0.d3p. Чтобы восстановить базу данных в D3, необходимо выполнить следующие действия: Выполняемая команда Средствами windows скопировать файл pseudo0.d3p в папку D3Virtual :to dm :set-device 2 :t-rew :account-restore Sklad :t-det :to Sklad

Комментарий Если в папке D3Virtual. уже есть файл с таким именем, его надо переименовать или удалить Переход в счет dm ! Происходит захват файла pseudo0.d3p «Лента» подматывается в начало Счет Sklad восстанавливается Файл pseudo0.d3p освобождается Переход в счет «Sklad» 27

3.

Лабораторный практикум 

3.1.

Лабораторная работа 1. Разработка базы данных многопользовательской системы

При подготовке к лабораторной работе 1 требуется разработать концептуальную модель предметной области, для которой создается многопользовательская система. Так как база данных системы должна поддерживаться СУБД с многозначной моделью данных, то концептуальную модель предметной области лучше представлять в виде диаграммы классов, хотя можно использовать и ERдиаграммы. В процессе выполнения лабораторной работы на основе концептуальной модели предметной области должна быть разработана схема базы данных. Составляющие элементы схемы базы данных в СУБД D3 хранятся в словарях файлов, в так называемых записях описания файлов (File Defining Item – FDI) и записях описания атрибутов (Attribute Defining Item – ADI). Существенно, что схема базы данных в СУБД D3 играет не предписывающую, как в реляционных СУБД, а описывающую роль. Это значит, что одни и те же данные могут быть описаны многократно, т.е. существовать несколько схем, в соответствии с которыми будут обрабатываться данные, хранимые в областях данных. Существенной особенностью систем, построенных с использованием СУБД D3, является широкое использование виртуальных атрибутов. Фактически это оригинальный способ использования встроенных процедур. Для создания виртуальных атрибутов используются так называемые коды обработки. СУБД D3 предоставляет большое число встроенных кодов, которые применяются в атрибутах для выполнения типовых операций обработки, а для какойлибо оригинальной обработки с помощью языка FlashBasic программист может написать свой собственный код. Заметим, что виртуальные атрибуты, хотя и привязаны к конкретному файлу базы данных, фактически могут получаться путем обработки данных многих файлов. При этом эти атрибуты имеют все права, что и ат28

рибуты, отражающие непосредственное значение поля некоторой записи. Создание схемы базы данных предполагает: • создание файлов; • указание способа формирования ключей записей файлов; • создание триггеров, реагирующих на изменение записей файлов, в частности мосты, связывающие файлы, – один из способов создания триггеров; • определение атрибутов файлов; • декларацию ассоциаций атрибутов файла. Создание схемы базы данных продемонстрируем на примере разработки базы данных для предметной области «Мониторинг чемпионата России по футболу». На рис. 3.1 и 3.2 показаны предельно упрощенная модель предметной области и схема базы данных. Модель предметной области представлена в стиле диаграммы классов, причем виртуальные (вычисляемые) свойства представлены как методы. Схема базы данных приведена в виде модифицированной диаграммы классов, что определяется особенностями реализации базы под управлением СУБД D3. СУБД D3 предоставляет очень простые средства для прототипирования систем. Фактически можно построить вполне работоспособный прототип информационной системы, практически не прибегая к программированию. В представленной на рисунках модели предметной области и соответствующей схеме базы количество виртуальных (вычисляемых) свойств (атрибутов) значительно больше числа реально существующих полей в записях файлов. Прототипирование информационной системы сводится к разработке вычисляемых атрибутов с последующем использованием системных процессоров UPDATE и ACCESS, соответственно, для модификации базы данных и составления различных отчетов. Именно так построена система «Футбольный чемпионат», подобные системы предстоит построить в ходе выполнения лабораторных работ. Базу данных составляют два файла «Team» и «Play».

29

Команда «Play» ID Название Игры дома (M) Игры в гостях (M)

Игра

2

1

ID Хозяин Гость Забил хозяин Забил гость

Количество Игр дома Счет дома (M) Очки дома (M) Количество Игр в гостях Счет в гостях (M) Очки в гостях (M) Количество Игр Мячи Очки

Рис. 3.1. Модель предметной области Team 1 2 3 4

ID_Team TeamName plD plG

2 PlayD 2 SochD 2 GdD 2 PlayG 2 2 2 2 2

SochG GdG SochW GdW PlayW

Play

Команда bTeam;2;3 Название Игры дома (M) Игры в гостях (M)

bTeam;3;4

1 2 3 4 5

Игра

ID_Play t1 Хозяин t2 Гость z1 Забил хозяи z2 Забил гость

Количество игр дома Очки дома Мячи дома Количество игр в гостях Очки в гостях Мячи в гостях Очки общие Мячи общие ИгрW

3 chD 3 ochD

Счет дома (M) Очки дома (M)

4 chG 4 ochD

Счет в гостях (M) Очки в гостях (M)

Рис. 3.2. Схема базы данных. Класс «Команда» представлен файлом D3 «Team», а класс «Игра» – файлом «Play» 30

Файлы создаются с помощью оператора (глагола) createfile. Например, create-file Team 1 1 при этом одновременно создается словарь файла и область данных файла. Из рис. 3.2 видно, что эти два файла связаны двумя мостами (bridge) от файла «Play» к файлу «Team». Мосты – специальные триггеры, которые срабатывают при сохранении записи об очередной игре в файле «Play» и заносят ссылку на эту игру в записи файла «Team», представляющие каждую из команд, принимавших участие в игре. Ссылка, заносимая в записи файла «Team», – идентификатор записи об игре в файле «Play». Мосты кодируются в записях описания файлов (File Defining Item – FDI), в данном случае в записи описания файла «Play». Работа с записями описания файлов. На рис. 3.3 и 3.4 показаны фрагменты записи описания файлов «Play» и «Team». Для работы с записями словарей нужно использовать макрос ud (update dictionary). Например, чтобы просмотреть и/или изменить запись описания файла «Play» (см. рис. 3.3), нужно выполнить команду: :ud Play ‘Play’ Часть атрибутов этой записи формируется при создании файла, изменению подлежат атрибуты correlative, macro, outputmacro. Особое внимание надо уделить атрибуту correlative, в котором описывается способ формирования ключей записей области данных файла, а также триггеры, связанные с файлом. Напомним, что СУБД D3 поддерживает многозначную модель данных. Это значит, что любой атрибут априорно считается многозначным, если не указано противное. Это полностью относится и к атрибуту correlative.

31

dictionary-code base modulo structure retrieval-lock update-lock output-conversion correlative attribute-type column-width input-conversion macro output-macro

D 13683 1

ida1 bTeam;2;3 bTeam;3;4 L 10 ID_Play t1 t2 z1 z2

Рис. 3.3. Запись описания файла «Play» dictionary-code D base 13687 modulo 1 structure retrieval-lock update-lock output-conversion correlative id5 I13689a1 attribute-type L column-width 10 input-conversion macro TeamName PlayD GdD SochD PlayG GdG SochG PlayW GdW SochW *-70 plD chD ochD *-70 plG chG ochG *-70 output-macro TeamName plD GdDL SochL plG GDGL SochGL PlayW GdWL SochWL CountPlays countplaysH Рис. 3.4. Запись описания файла «Team»

Из рис. 3.3 видно, что первым значением атрибута correlative является «ida1». Это комбинация кода обработки «id» и кода обработки «a». Код обработки «id» генерирует ключ записи области данных файла, а код обработки «a» указывает способ генерации – ключ формируется алгебраическим выражением, сле32

дующим за кодом «a». В данном случае за кодом «a» следует «1», т.е. в качестве ключа принимается значение первого поля записи. Это значит, что первое поле должно содержать единственное значение, которое при сохранении записи принудительно копируется в нулевое поле. Вторым значением атрибута correlative в записи описания файла «Play» (см. рис. 3.3) является «bTeam;2;3». Раскроем смысл этого выражения. Код «b» говорит, что указанное выражение представляет мост (bridge) из файла «Play» в файл, имя которого непосредственно следует за «b», т.е. файл «Team». Цифра «2» представляет номер поля в записи файла «Play», в котором находится ключ записи файла «Team», в данном случае – идентификатор команды «хозяина» игры, т.е. команды, на поле которой проходила игра. Цифра «3» представляет номер поля в записи файла «Team», в которое будет помещен ключ записи файла «Play» в результате срабатывания триггера (моста). Поле 3 записи файла «Team» – многозначное, в нем находятся идентификаторы всех игр, которые команда провела «дома». Третье значение атрибута correlative в записи описания файла «Play» (см. рис.3.3) также представляет мост «bTeam;3;4». В данном случае цифра «3» представляет номер поля в записи файла «Play», в котором находится ключ записи файла «Team», – идентификатор команды «гостя», т.е. команды, играющей на поле хозяина. Цифра «4» представляет номер поля в записи файла «Team», в которое будет помещен ключ записи файла «Play», в результате срабатывания триггера (моста). Поле 4 записи файла «Team» – также многозначное, в нем находятся идентификаторы всех игр, которые команда провела «в гостях». Обратите внимание на атрибут correlative в записи описания файла «Team» (см. рис. 3.4). Первое значение этого атрибута – id5 – говорит о том, что записи в области данных файла «Team» имеют ключи (идентификаторы команд), которые генерируются автоматически путем прибавления 1 к последнему сгенерированному ключу. В данном случае (см. рис. 3.4) последний сгенерированный ключ есть 5, поэтому при вводе следующей записи с описанием команды ее ключом будет 6. 33

Второе значение этого атрибута – I13689a1 – генерируется СУБД D3 автоматически при определении индекса. В данном случае это значение говорит о том, что на первом поле определен индекс. Помимо атрибута correlative в записях описания файлов желательно заполнить атрибут macro и output-macro. Их можно не заполнять, например в записи описания файла «Play» (см. рис. 3.3) атрибут output-macro не заполнен. В этих атрибутах через пробел перечисляются атрибуты разрабатываемого файла, которые процессорами D3 используются по умолчанию. Атрибут macro используется UPDATE-процессором. Например, команда D3: :u Play ‘121’ эквивалентна команде :u Play ‘121’ ID_Play t1 t2 z1 z2 Следует иметь ввиду, что приоритет отдается программной строке, т.е. команда: :u Play ‘121’ ID_Play t1 t2 будет обрабатывать только три, явно заданные в строке атрибуты. Атрибут output-macro используется ACCESS-процессором, применяемым для генерации отчетов. Если же он – пустой (см. рис. 3.3), ACCESS-процессор будет использовать атрибуты из macro: :list Play эквивалентна команде :list Play ID_Play t1 t2 z1 z2 Работа с записями описания атрибутов. На рис. 3.5а и 3.5б показаны фрагменты записи описания атрибутов файла «Team». Напомним, что записи описания атрибутов находятся (сохраняются) в словарях файлов (в данном случае «DICT Team»). Для рабо34

ты с записями словарей нужно использовать макрос ud (update dictionary). Например, :ud Team ‘TeamName’ DICT Team ‘TeamName’size = 53 dictionary-code a attribute-count 2 substitute-header Команда: structure output-conversion correlative attribute-type l column-width 10 Рис. 3.5а. Фрагмент записи описания «хранимого» атрибута

Чтобы работать с записью описания вычисляемого атрибута с именем «Gdd» («Мячи дома»), нужно выполнить команду: :ud Team ‘Gdd’ DICT Team ‘Gdd’ size = 93 dictionary-code a attribute-count 2 substitute-header Мячи дома structure d;1 output-conversion correlative a;s(3(tPlay;x;;4)):":":s(3(tPlay;x;;5)) attribute-type r column-width 2 input-conversion x Рис. 3.5б. Фрагмент записи описания «вычисляемого» атрибута

Отметим, что имена атрибутов «TeamName» и «Gdd» есть ключи записи описания атрибута в файле «DICT team», при этом ка35

вычки при обращении к описанию атрибута можно опускать, т.е. запись команды: :ud Team Gdd также будет правильная. В запись описания атрибута данные вводятся только разработчиком. Рассмотрим их последовательно. Атрибут «dictionary-code» определен на поле 1 записи описания атрибута и должен иметь значение «a» – код, указывающий, что это запись описания атрибута (для области данных файла). Замечание. В словаре файла определяем атрибуты для области данных файла. Атрибуты для словаря файла, в частности «dictionary-code», определяются в словаре более высокого уровня, а именно главном словаре базы данных (счета) – «master dictionary», для которого предназначен файл «md» (см. рис. 3.6). Попробуйте выполнить команду: :ud md ‘dictionary-code’

md Dict team Data team

Рис. 3.6. Иерархия описания атрибутов

Атрибут «attribute-count» определен на поле 2 записи описания атрибута и вводит номер поля в записи области данных, 36

для которого определяется этот атрибут. В данном случае (см. рис. 3.5а, 3.5б) это поле 2. Атрибут «substitute-header» определен на поле 3 записи описания атрибута и вводит заголовок, под которым атрибут выводится в отчетах. В данном случае (см. рис. 3.5а, 3.5б) это «Мячи дома». Атрибут «structure» определен на поле 4 записи описания атрибута и вводит код, который определяет зависимость атрибутов записи области данных. В данном случае это «d;1», который определяет, что этот атрибут зависит от атрибута, определенного на поле 1, у которого в «structure» стоит код «c;2». Если эти атрибуты многозначны, то, используя эти атрибуты при обработке данных, мы фактически имеем дело с таблицей, включенной в запись области данных. Атрибут «output-conversion» определен на поле 7 записи описания атрибута и вводит код преобразования значения поля, который срабатывает непосредственно перед выводом на экран или печать. В данном случае (см. рис. 3.5а, 3.5б) в этом атрибуте значение не определено. Атрибут «correlative» определен на поле 8 записи описания атрибута и вводит код преобразования значения поля, который срабатывает непосредственно перед использованием атрибута в любом преобразовании. В данном случае (см. рис. 3.5б) в этом атрибуте стоит алгебраическое преобразование: a;s(3(tPlay;x;;4)):":":s(3(tPlay;x;;5)) Это преобразование достаточно сложно и его целесообразно объяснять, когда будут понятны его составляющие. Атрибут «attribute-type» определен на поле 9 записи описания атрибута и вводит тип атрибута. Интересны два значения: «r» – строка сдвинута вправо (если она состоит из цифр, то интерпретируется как число); «l» – строка сдвинута влево. Проверьте использование этих типов на сортировке записей по атрибуту, содержащему цифры. 37

Атрибут «column-width» определен на поле 10 записи описания атрибута и вводит ширину столбца при выводе в табличном формате. Атрибут «input-conversion» определен на поле 14 записи описания атрибута и вводит код входного преобразования. В данном случае (см. рис. 3.5б) это «х». Такой код означает, что атрибут вычисляется, а не соответствует значению, хранимому в поле 2 записи области данных. Компоненты записи описания атрибута, не представленные на рис. 3.5а и 3.5б, для выполнения лабораторных работ не очень нужны, а при необходимости их значения можно узнать в документации.

3.2.

Лабораторная работа 2. Использование кодов обработки в многозначных базах данных

Из краткого описания предметной области и соответствующих файлов видно, что большинство атрибутов файла «Team» являются вычисляемыми. Для определения вычисляемых атрибутов используются коды обработки, они позволяют построить системы средней сложности, практически не прибегая к программированию. Коды обработки полностью описаны в электронном учебном пособии (база «lectur» в D3), а также доступны «on-line» при определении атрибутов. Однако целесообразно разобрать хотя бы несколько примеров. Чтобы быть более конкретными, давайте разберем выражение, определяющее значение атрибута «Gdd» – «Мячи дома»: a;s(3(tPlay;x;;4)):":":s(3(tPlay;x;;5)) Это – алгебраическое выражение, на что указывает код «a;». Алгебраической операцией в данном случае является операция конкатенации строк – «:». Заметим, что ":" в этом выражении это тоже строка. Первая часть этого выражения s(3(tPlay;x;;4)) говорит о том, что суммируются значения многозначного поля 3, предварительно преобразованные. 38

О суммировании говорит код «s», который применяется к выражению 3(tPlay;x;;4). Напомним, что в поле 3 записи файла «Team» хранятся идентификаторы игр, проведенных командой на своем поле. Складывать идентификаторы игр просто нелепо, их надо преобразовать. Код tPlay;x;;4 называется «трансляцией через файл» и применяется он к каждому значению многозначного поля 3 записи файла «Team» (игр на своем поле может быть много). В терминологии реляционной модели происходит эквисоединение файлов «Team» и «Play» с проекцией на поле 4 файла «Play». Напомним, что в этом поле файла «Play» хранится количество мячей забитых «хозяином». Оставшаяся часть выражения объясняется аналогично. Результат всех преобразований, выполненных этим алгебраическим выражением – скалярная строка, например «16:10». Этот результат говорит, что команда, играя на своем поле, забила во всех играх 16 мячей, а пропустила – 10. Разумеется, использование кодов обработки также требует творческого подхода, как и программирование. Попробуйте сами построить выражение, используя только что рассмотренные коды обработки, определяющее количество игр дома. Ответ можно увидеть по адресу4. Возникает вопрос: «Почему атрибут «Gdd» (см. рис. 3.5б) определен на поле 2 записи файла «Team», хотя для его определения значение поля 2 не используется?» Напомним, что в поле 2 хранится название футбольной команды. Самая главная причина – этот атрибут по семантике однозначен, поэтому он должен быть обязательно определен на однозначном поле. Очень часто для этого используется поле 0, которое всегда однозначное. Вторая причина – удобство построения ассоциаций. Так как система «Футбольный чемпионат» доступна (она входит в базу «К9», предоставляемую студентам), попробуйте определить атрибут «Gdd» на поле 3 файла «Team», которое многозначно. Получите многозначный результат, проверьте какой.

4

correlative

a;s(3=3). 39

Как уже говорилось, коды обработки доступны «on-line» при определении атрибутов. При определении атрибута (см. рис. 3.5а и 3.5б), когда курсор стоит на определенной строке, нажав F1 или CtrlX,1, получим список кодов, которые могут быть использованы при формировании этой строки. Пусть, например, курсор стоит на строке «output-conversion». Нажав F1, получим экран со списком кодов, представленный на рис. 3.7. Всю информацию, связанную с использованием конкретного кода, можно получить, встав курсором на соответствующую строку и нажав F1. a c call d f

Алгебраические преобразования в обычной записи Конкатенация Конверсия с помощью подпрограммы пользователя Конверсия дат Алгебраические преобразования в обратной польской записи g Выделение групп if Конверсия с использованием условий l Длина строки либо вывод строки заданной длины m Конверсия цифровых величин и строк с помощью маски mc Семейство специальных конверсий буквенно-цифровых строк mp Десятичная упаковка ms Изменение последовательности сортировки mt Конверсия времени mx Конверсия ASCII ───> HEX my Конверсия HEX ───> ASCII o Сортировка значений многозначного атрибута p Совпадение с шаблоном r Числовой Интервал s Подстановка text.extract Выделение подстроки translate Трансляция через файл Рис. 3.7. Коды обработки, используемые в атрибутах «output-conversion» и «correlative»

40

Пусть, например, требуется сконвертировать дату. Нажав F1 на коде «d», получим исчерпывающую информацию по этому коду и примеры их применения, которые представлены на рис. 3.8. Обращаем внимание, что внутреннее представление даты – целое число, причем нулю (0) соответствует 31 декабря 1967 г. Важное качество разработанной «on-line» помощи состоит в том, что, выйдя на необходимую информацию и нажав F3, можно непосредственно проверить результаты, к которым приводит применение того или иного кода. Покажем это на примере конвертирования денежных сумм. Данные 0 1 -1 15342 15342 15342 19/05/2010 15342 15342 15342 15342 15342 15342 15480 15342

│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │

Код d d2dd0 d0d di dj dm dma dq dw dwa d d4y

│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │

Вывод 31 Dec 1967 01-01-68 30-12-1967 01 Jan 01-01 1 Jan 2010 15480 1 1 January 1 5 Friday 19 May 2010 2010

Рис. 3.8. Примеры кодов обработки, используемых для конвертирования дат из внутреннего представления во внешний

Денежные суммы во внутреннем представлении обычно выражаются в копейках или центах и при выводе должны быть соответствующим образом оформлены. Для этого используется код маски «m», к которому приписываются уточняющие факторы. Чтобы получить информацию по этому коду, нажимаем F1, а чтобы перейти к интерактивным примерам, затем нажимаем F3. В частности, видим пример: 41

Код mr2,$

Сумма в центах 123456

Вывод $1,234.56

В коде «mr2,$»: m – маска; r – сдвиг вправо (число); 2 – точность (два знака после десятичной точки); , – разделитель целой части; $ – знак доллара. Код маски обычно используется в атрибуте «outputconversion», чтобы оформить данные непосредственно перед выводом, так как в отформатированном виде их обрабатывать достаточно сложно.

3.3.

Лабораторная работа 3. Разработка меню

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

Внешний вид меню «футбол» представлен на рис. 3.9. В нем показаны четыре опции, которые выполняют команды, представленные в записи файла «md», показанной на рис. 3.10. Эта запись имеет ключ или идентификатор (Item ID в терминологии D3) ‘футбол’. Эта запись может быть сформирована с помощью UPDATEпроцессора, который в данном случае работает как простой полноэкранный редактор, работающий с полями записи, а не с атрибутами. Ф У Т Б О Л Ь Н Ы Й 1) 2) 3) 4)

Ч Е М П И О Н А Т

Список игр чемпионата Очередная игра Таблицы игр для команд Таблица чемпионата

Enter number of choice, number? for Help, to exit menu:

<Enter>

Рис. 3.9. Внешний вид меню «футбол»

md ‘футбол’ size = 250 01 me 02 Ф У Т Б О Л Ь Н Ы Й Ч Е М П И О Н А Т 03 Список игр чемпионата Вы смотрите список игр чемпионата России! list Play by t1 by t2 id-supp 04 Очередная игра Результаты очередной игры чемпионата! u Play (c 05 Таблицы игр для команд Интегрированная информация по командам! u Team * (c 06 Таблица чемпионата Сводная таблица чемпионата! list Team by-dsnd SochAW id-supp Рис. 3.10. Запись файла md с ключом ‘футбол’ представляющая меню «футбол» 43

В первом поле записи стоит код меню «me», во втором – внешнее название меню, которое представлено строкой «Ф У Т Б О Л Ь Н Ы Й

Ч Е М П И О Н А Т».

Опции меню формируются, начиная с 3-го поля записи, которые являются многозначными и имеют три значения: 1) название опции; 2) комментарий к опции; 3) текст операции, выполняемой при выборе опции.

3.4.

Лабораторная работа 4. Демонстрация работы многопользовательской системы

Выдача по опции 1 («Список игр чемпионата») меню (рис. 3.11) выполняется по команде ACCESS-процессора: :list Play by t1 by t2 id-supp Page

1

Список игр чемпионата

Хозяин.... Гость.....Забил Хозяин Динамо Спартак 2 Динамо Торпедо 2 Динамо Ротор 3 Локомотив Динамо 3 Локомотив Спартак 3 Локомотив Ротор 3 Спартак Динамо 3 Спартак Локомотив 3 Спартак Торпедо 2 Спартак Ротор 4 Торпедо Динамо 2 Торпедо Ротор 5 Ротор Динамо 2 Hit any key to return to the Menu

Забил Гость 0 3 2 3 2 1 1 1 0 3 3 2 1

Рис. 3.11. Выдача по опции «Список игр чемпионата»

В этой команде: list – оператор ACCESS-процессора; 44

by t1 – сортировка по возрастанию по атрибуту t1; by t2 – сортировка по возрастанию по атрибуту t2 в пределах t1; id-supp – подавление выдачи идентификаторов записей. Список выдаваемых атрибутов в команде не указан. Он берется из записи описания файла «Play». Play NEW ITEM ID_Play Хозяин Гость Забил Хозяин Забил Гость

127 Динамо Локомотив 2 3

Play '127' size 21 filed. Hit any key to return to the Menu Рис. 3.12. Выдача по опции «Очередная игра» TeamName ИгрD МячиD ОчкиD ИгрG МячиG ОчкиG ИгрW МячиW ОчкиW Динамо 3 7:5 6 4 8:10 4 7 15:15 10 * ─────────────────────────────────────────────────────────── ─ Игры дома Счет Очки Спартак 2:0 3 Торпедо 2:3 0 Ротор 3:2 3 * ─────────────────────────────────────────────────────────── ─ Игры в гостях Счет Очки Локомотив 3:3 1 Торпедо 3:2 3 Ротор 1:2 0 Спартак 1:3 0 * ─────────────────────────────────────────────────────────── ─ Team '1' size = 79 exited. Hit any key to return to the Menu Рис. 3.13. Выдача по опции («Таблицы игр для команд») 45

Выдача по опции 2 («Очередная игра») меню (рис. 3.12) выполняется по команде UPDATE-процессора: :u Play (c Фрагмент выдачи по опции 3 («Таблицы игр для команд») меню (рис. 3.13): :u Team * (c Team

'1' size = 79

Выдача по опции меню 4 (рис. 3.14): :list team by-dsnd SochAW id-supp Page

1

Таблица чемпионата -----Дома----- ---В гостях--- -В чемпионатеTeamName Игры Мячи Очки Игры Мячи Очки Игры Мячи Очки Спартак Динамо Локомотив Торпедо Ротор

4 3 3 2 2

12:5 7:5 9:6 7:5 4:4

12 6 7 3 3

2 4 1 2 3

3:4 8:10 1:3 3:4 6:10

3 4 0 3 0

6 7 4 4 5

15:9 15 15:15 10 10:9 7 10:9 6 10:14 3

[405] 5 items listed out of 5 items. Hit any key to return to the Menu

Рис. 3.14. Выдача по опции («Сводная таблица чемпионата»)

3.5. Заключение по лабораторным работам На примере выбранной вами или предложенной вам предметной области необходимо на качественном уровне указать преимущества и недостатки использования СУБД с моделью данных с многозначными атрибутами по сравнению с использованием СУБД с реляционной моделью данных для разработки информационных систем.

46

Список рекомендуемой литературы  1. Системы управления полуструктурированными данными, http://www.osp.ru/os/1999/05-06/179837/_p1.html 2. СУБД D3 для пользователей, http://www.infologic.com 3. Vaskevitch D., Two Steps Forward, One Step Back, BYTE, May 1992.

47