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

Как же отражается эта связь на структуре класса ЛИЧНОСТЬ в представлении класса средствами СУБД D3? Для этой цели в словаре определяется атрибут «Родители»:

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

а в области данных вводится поле, имеющее максимум два значения. Это поле содержит ключи записей родителей как объектов класса ЛИЧНОСТЬ.

Если родители конкретной личности представлены в базе данных, то эта личность для них является ребенком (рис. 1.3).

1	Родители	2
ЛИЧНОСТЬ		ЛИЧНОСТЬ
N	Дети	0
Рис. 1.3. Производная связь на уровне классов

Связь «Дети» – производная: как только зарегистрирована не-

которая «Личность», то у ее «Родителей» (у каждой «Лично-

сти», как матери, так и отца) ссылка на эту «Личность» автоматически должна появиться в качестве значения атрибута «Дети».

На уровне области данных файла ЛИЧНОСТЬ запись на конкретный объект будет выглядеть примерно так, как показано на рис. 1.4.

Как видно из примера (см. рис. 1.4) в поле 006, на котором определен атрибут «Родители», реально хранятся ключи записей на отца и на мать. Атрибут «Родители» может быть определен как преобразование этих ключей к виду:

Иванов И.А.]Иванова М.В.

На этом же поле 006 можно определить атрибут «Да-

та_Рождения_Родителей» и т.д.

11

ЛИЧНОСТЬ		-	запись
000	N124	-	Номер свидетельства о рождении
001	Иванов	-	(Ключ)
			Фамилия
002	Иван	-	Имя
003	Иванович	-	Отчество
004	м	-	Пол
005	10200	-	Дата Рождения
006	N089]N063	-	Ключ записи отца]Ключ записи
007		-	матери
			Детей нет

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

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

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

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

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

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

12

1	Другие связи	N
ЛИЧНОСТЬ		ЛИЧНОСТЬ
Рис. 1.5. Нестандартные связи между объектами

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

ЛИЧНОСТЬ(Nсв, ..., Дети,

ДругиеСвязи, ТипДругойСвязи)

«ДругиеСвязи» и «ТипДругойСвязи» это жестко связанные многозначные атрибуты: при удалении значения из атрибута «ДругиеСвязи» автоматически удаляется соответствующее значение из атрибута «ТипДругойСвязи».

На уровне области данных файла ЛИЧНОСТЬ запись на конкретный объект будет выглядеть примерно так, как показано на рис. 1.6.

ЛИЧНОСТЬ		-	запись
000	N124	- Номер свидетельства о рождении
001	Иванов	-	(Ключ)
			Фамилия
002	Иван	-	Имя
003	Иванович	-	Отчество
004	м	-	Пол
005	10200	-	Дата Рождения
006	N089]N063	- Ключ записи отца]Ключ записи
007		-	матери
	N145]N165]N165		Детей нет
008		-	Другие связи
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 md Team 01 Q

02 Football

03 Team

Связь словарей с конкретными файлами данных осуществляется в рамках следующего синтаксиса:

ГЛАГОЛ Q-указатель USING DICT имя_словаря список_атрибутов ОПЦИИ

Например,

LIST Материалы USING DICT КлЦенник Код Название ЕдИзм Цена (h

где «Материалы» – имя Q-указателя, определенного в MD программного счета; «КлЦенник» – имя словаря в программном сче-

те; «Код», «Название», «ЕдИзм», «Цена» – имена атрибутов,

определенных в словаре «КлЦенник».

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

19

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

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

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

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

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

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

Вкачестве обязательной составляющей любого рабочего счета должны быть меню и, возможно, макросы.

Еще раз отметим, что в этом случае вся работа пользователей осуществляется в счетах с программами.

20