БАЗЫ ДАННЫХ Рабочая - ict.edu.ruict.edu.ru/ft/005410/nwpi232.pdf · Рабочая программа ... Направление и специальность подготовки

Министерство образования Российской Федерации

Государственное образовательное учреждение высшего профессионального образования

Северо-Западный государственный заочный технический университет

Кафедра компьютерных технологий и программного обеспечения

БАЗЫ ДАННЫХ

Рабочая программа

Методические указания к изучению дисциплины Задания на контрольные работы

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

Факультет информатики и систем управления Направление и специальность подготовки дипломированного специалиста: 654600 – информатика и вычислительная техника 220100 - вычислительные машины, комплексы, системы и сети Направление подготовки бакалавра 552800 - информатика и вычислительная техника

Санкт-Петербург 2004

Утверждено редакционно-издательским советом университета

УДК 681.3.06

Базы данных: Рабочая программа, методические указания к изучению дисциплины, задания на контрольные работы, методические указания к выполнению лабораторных работ. – СПб.: СЗТУ, 2004. - 101 с.

Рабочая программа соответствует государственным

образовательным стандартам высшего профессионального образования по направлению подготовки дипломированного специалиста 654600 –«Информатика и вычислительная техника» (специальность 220100 –«Вычислительные машины, комплексы, системы и сети») и направлению подготовки бакалавра 552800.

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

В рабочей программе рассмотрены основы архитектуры банков данных и методы их проектирования и эксплуатации.

Рассмотрено на заседании кафедры компьютерных технологий и

программного обеспечения 5 ноября 2003 г., одобрено методической комиссией факультета информатики и систем управления 17 ноября 2003 г.

Рецензенты: Г.И.Анкудинов, д-р техн. наук, проф. кафедры компьютерных систем и программного обеспечения СЗТУ; E. Д. Соложенцев, д-р техн. наук, зав. лабораторией ИПМаш РАН. Составители: М.В. Копейкин, канд. техн. наук, доц.

В.В. Спиридонов, канд. техн. наук, доц. Е.O. Шумова, доц.

© Северо-Западный государственный заочный технический университет, 2004

I. ПРЕДИСЛОВИЕ

Дисциплина «Базы данных» представляет собой специальную отрасль

научных знаний. Ее предметом является изучение информационных систем,

принципов их построения, закономерностей и особенностей функционирования.

При этом основополагающее значение имеет категориальный анализ

информации, подлежащей отображению и хранению в структурах данных

информационных систем. Важнейшей проблемой является и достижение

соответствия между традиционными структурами данных и информационными

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

конструированию структур данных и управления ими. Базовыми дисциплинами

для изучения этого курса являются «Программирование на языке высокого

уровня», «Системное программное обеспечение», «Дискретная математика»,

«Математическая логика и теория алгоритмов», «Теория автоматов» и многие

другие дисциплины специальности. Изучение основополагающих вопросов

данного курса служит введением в другие дисциплины: «Проектирование

информационных систем», «Системотехника и системное проектирование»,

«Экспертные системы» и используется в дипломном проектировании. В

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

информационное обеспечение создаваемых систем, основанное на современных

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

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

II. 1. СОДЕРЖАНИЕ ДИСЦИПЛИНЫ

1.1. Содержание дисциплины по ГОС

Назначение и основные компоненты системы баз данных; обзор

современных систем управления базами данных (СУБД); уровни представления

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

и реляционная модели данных; схема отношения; язык манипулирования

данными для реляционной модели; реляционная алгебра и язык SQL;

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

декомпозиция отношений, транзитивные зависимости, проектирование с

использованием метода сущность - связь; изучение одной из современных СУБД

по выбору; создание и модификация базы данных; поиск, сортировка,

индексирование базы данных, создание форм и отчетов; физическая организация

базы данных; хешированные, индексированные файлы; защита баз данных;

целостность и сохранность баз данных.

1.2. РАБОЧАЯ ПРОГРАММА (объем 154 часа)

Введение (4 часа)

[1], с. 38...63, [6]

Предмет и содержание курса. Основные понятия. Принципы организации

систем обработки данных. Информационная система предприятия и ее

характеристики. Виды информационных систем. Системы оперативной

обработки, системы общего назначения, интегрированные системы обработки

данных. Состав вычислительной системы. Общая структура комплекса

технических средств.

1. 1.2.1. Среда базы данных (14 часов)

[1], с. 73...103

Основные отличия файловых систем от баз данных. Уровни абстракций в

концепции баз данных. Внешний уровень, концептуальный уровень, внутренний

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

типах и структурах данных. Типы данных: целый, вещественный, символьный,

логический, указательный. Форматы данных. Операции, присущие каждому

типу данных. Структуры данных. Преобразование логических структур в

физические структуры. Проблема независимости данных. Языки баз данных.

Язык определения данных – DDL. Язык управления данными – DML. Модели

данных и концептуальное моделирование. Объектные модели данных.

Физические модели данных. Функции систем управления баз данных (СУБД).

Компоненты СУБД. Архитектура многопользовательских СУБД. Файловый

сервер. Технология "клиент/сервер".

2. 1.2.2. Методы организации данных на внешних запоминающих устройствах (12 часов)

[1], с. 1010...1056; [2], с. 140...164; [3], с. 99…123

Типы и характеристики устройств внешней памяти. Уровни памяти

вычислительной системы. Основные технические характеристики устройств

внешней памяти - емкость, время доступа, скорость передачи данных и форма

доступа. Форматы записей. Основные понятия об организации файлов на

устройствах внешней памяти. Логические структуры и способы обработки

файлов. Типы файлов. Методы доступа. Режимы передачи данных - режим

передачи с очередями и базисный режим передачи. Последовательные файлы на

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

Файлы прямого доступа. Индексно-последовательные файлы. Критерии,

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

моделей данных в памяти ЭВМ. Первичные методы доступа: последовательная

обработка и произвольная обработка. Поиск при физически последовательной

организации данных и поиск при связной организации данных. Деревья поиска и

произвольная обработка. Деревья бинарного поиска. В-деревья. Поиск по

нескольким ключам. Вторичные методы поиска. Мультисписковая и

инвертированная организация индексов. Способы организации

инвертированного индекса. Разделение данных и связей. Кортежная и доменная

организация данных. Анализ кортежной и доменной организации без

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

индексирования. Оценка быстродействия используемых индексов.

3. 1.2.3. Основы построения банков данных (10 часов)

[1], с. 145...176

Основная терминология. Банк данных как автоматизированная система.

Классификация СУБД. Информация и данные. Жизненный цикл

информационной системы. Планирование разработки базы данных.

Определение требований к системе. Этапы проектирования баз данных.

Инфологическое, концептуальное, внутреннее и внешнее проектирование баз

данных. Моделирование данных: понятие модели данных, структуры данных,

основные операции над данными, ограничения целостности. Типы моделей

данных. Сетевая, иерархическая, реляционная и фреймовая модели данных.

Эквивалентность моделей данных. Языки описания данных и языки

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

физическая независимость. Достоинства и недостатки иерархических, сетевых и

реляционных баз данных. Проектирование приложения. Понятие транзакций.

Использование CASE-инструментов. Критерии оценки СУБД. Выбор СУБД.

Администрирование базы данных.

4. 1.2.4. Теоретические основы реляционной модели данных (10 часов) [1], 222…257; [2], с. 114...138

Моделирование информационных объектов посредством отношений.

Реляционная алгебра: операции реляционной алгебры. Теоретико-

множественные операции: объединение, пересечение, декартово произведение,

разность, проекция. Специальные операции реляционной алгебры: частное,

соединение, селекция, эквисоединение. Использование отношений для

представления данных. Схема отношения. Функциональные и многозначные

зависимости. Правила вывода функциональных зависимостей. Нормализация

отношений: ключи отношений, нормальные формы схем отношений. Синтез

схем, отношений. Алгоритмы методов теории нормализации. Приведение

отношений в первую, вторую, третью, третью - усиленную и четвертую

нормальную формы. Зависимости соединения и пятая нормальная форма.

5. 1.2.5. Языки баз данных (20 часов) [1], с. 420...470; [5]

Назначение языка SQL и QBE. Терминология и диалекты SQL. Стандарты

SQL и синтаксис языка. Манипулирование данными. Связь SQL и реляционной

алгебры. Создание баз данных. Создание и удаление таблиц. Виртуальные и

хранимые таблицы. Определение данных. Указание ограничений поддержки

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

процедуры и триггера. Создание индексов. Простые запросы. Сортировка

результатов. Использование обобщающих функций языка SQL. Агрегатные

функции. Группирование результатов. Подзапросы. Многотабличные запросы.

Комбинирование хранимых таблиц. Изменение содержимого базы данных.

Создание и удаление представлений. Понятие интерактивного и вложенного

SQL. Понятие курсора. Сравнение языков SQL и QBE.

6. 1.2.6. Объектно-реляционный подход к проектированию баз данных (16 часов)

[3], с. 7...30; [1], c. 847…884

Проблемы теории нормализации и нормальных форм отношений.

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

данных. Проблема адекватности отображения предметных областей в модели

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

статичности реляционной модели данных. Реорганизация модели данных и

идентификация объектов в базе данных. Объектно-реляционный подход к

проектированию моделей баз данных. Предпосылки и достоинства подхода.

Средства идентификации объектов в модели и средства моделирования. Этапы

проектирования объектно-реляционной модели. Обеспечение защиты данных в

базе. Обеспечение целостности данных. Запланированные и незапланированные

запросы. Оптимизация запросов в базе данных.

7. 1.2.7. Концепции распределенных СУБД (8 часов) [1], с. 686...768

Основные понятия и определения. Локальные сети. Функции

распределенных СУБД. Расписание доступа. Внутренняя (локальная) и внешняя

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

Классификация и анализ методов и алгоритмов параллельного управления.

Классы алгоритмов синхронизации: по степени участия узлов в управлении, по

способу решения конфликтов, по наличию предварительного анализа

конфликтности транзакций, по способу борьбы с тупиковыми ситуациями.

Централизованное управление. Алгоритмы блокировки. Целостность и

восстановление баз данных.

8. 1.2.8. Промышленные системы управления базами данных (7 часов) [9 - 15]; [1], с. 847...885

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

сохранность данных в СУБД. Язык описания базы данных. Физические и

логические базы данных. Логические структуры данных и структуры данных

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

последовательная выборки. Методы доступа: иерархический, последовательный,

иерархически прямой, иерархический индексно-последовательный. Системы

управления базами данных типа dBASE. Архитектура систем. Системы RBASE,

PARADOX, FOXBASE, ORD, ALASKA, ACCESS. Системы управления базами

данных типа ORACLE, INFORMIX. Создание баз данных и программирование в

среде СУБД для ПЭВМ.

Заключение (1 час) [1], с. 888...1000

Перспективы развития баз данных. Экспериментальные системы. Базы

знаний.

B. 1.3. Тематический план лекций для студентов очно-заочной формы обучения

(24 часа) Темы лекций Объем, ч

1. Требования, методы и средства проектирования

информационного обеспечения систем. Назначение и основные

компоненты системы баз данных

2. Этапы проектирования информационного обеспечения.

Уровни представления баз данных

3. Архитектура банка данных. Стандарт ANSI\SPARC. Модели

данных: иерархическая, сетевая, реляционная, фреймовая

4. Организация данных на внешних запоминающих устройствах

5. Языки баз данных. Языки описания данных и языки

манипулирования данными

6. Реляционная алгебра и язык SQL (QBE)

7. Концептуальная модель реляционной модели. Теория

нормализации. Целостность и сохранность баз данных

8. Инфологическая модель. Проектирование модели с помощью

метода сущность-связь и фреймового метода

9. Основы объектно-реляционного метода проектирования баз

данных

10. Организация информационного фонда в распределенных

базах данных. Эксплуатация и сопровождение

2

2

2

2

2

4

4

2

2

2

C. 1.4. Тема практического занятия (4 часа)

Использование методов нормализации при декомпозиции отношений.

D. 1.5. Темы лабораторных работ (24 часа)

Темы лабораторных работ Объем, ч

1. Ознакомление с особенностями интегрированной среды СУБД 2. Построение формы, содержащей К-связь 3. Построение формы, содержащей Q-связь 4. Построение формы, использующей Н-связь 5. Построение формы с изменяемой структурой 6. Построение формы, содержащей блок "V-H-V"

4 4 4 4 4 4

E. 1.6. Тематика курсового проекта

Тематика курсового проекта определяется в соответствии с материалом,

изложенным в [17]. Основная особенность курсового проекта заключается в том,

что в ее рамках решаются задачи, близкие к производственной деятельности

студента. Поэтому содержательная часть проектируемой информационной

системы не регламентируется и выбирается студентом самостоятельно.

III. 2. Библиографический список

Основной:

1. Конноли Т., Бегг К., Страчан A. Базы данных: проектирование,

реализация и сопровождение. Теория и практика. 2-е издание. – М.:

Издательский дом "Вильямс", 2000. – 1120 c.

2. Дейт К. Введение в системы баз данных. – Киев-Москва: Диалектика,

1998. – 781 с.

3. Воронин Г.П., Копейкин М.В., Осмоловский Л.Г., Петухов О.А.

Проектирование объектно-реляционных баз данных. / Под ред. О. А. Петухова. –

Л.: Судостроение, 1986. – 180 c.

Дополнительный:

4. Мальцев М.Г., Хомоненко А.Д., Цыганков В.М. Базы данных: Учеб. пособие. – СПб.: Изд-во Корона принт, 2002. – 672 с.

5. Копейкин М. В., Спиридонов В. В., Шумова Е. О. Базы данных. Основы SQL реляционных баз данных: Учеб. пособие. – СПб.: СЗТУ, 2004. – 177 c.

6. Копейкин М. В., Спиридонов В. В., Шумова Е. О. Базы данных. Концепция баз данных: Учеб. пособие. – СПб.: СЗТУ, 2004. – 117 c.

7. Копейкин М.В., Спиридонов В.В., Шумова Е.О. Базы данных. Инфологические модели баз данных: Учеб. пособие. – СПб.: СЗТУ, 2004. – 190 c.

8. Мейер М. Теория реляционных баз данных. – М.: Мир, 1987. – 608 с.

9. Хансен Г., Хансен Д. Базы данных: разработка и управление. – M.: ЗАО Издательский дом БИНОМ, 1999. – 704 c.

10. Копейкин М.В., Спиридонов В.В., Шумова Е.О. Базы данных. Объектно-реляционный подход: Учеб. пособие. – СПб.: СЗПИ, 1998. – 96 c.

11. Архангельский А.Я. Программирование в Delpfi 5. – М.: Бином, 2000. – 1070 с.

12. Тихомиров Ю. SQL Server 7.0. – СПб.: БХВ-Петербург, 2001. – 720 с. 13. СУБД Cache. Объектно-ориентированная разработка приложений:

Учебный курс / В. Кирстен, М. Ирингер, Б. Рериг, П. Шульте. – СПб.: Изд-во Питер, 2001. – 384 c.

14. Кайт Т. Oracle для профессионалов. Книга 1. Архитектура и основные особенности. – СПб.: Изд-во ООО ДиаСофтЮП, 2003. – 672 с.

15. Грачев А.Ю. Введение в СУБД Informix. – М.: Диалог МИФИ, 2000. – 272 с.

16. Защита информации в компьютерных системах и сетях /Под ред. В.Ф. Шаньгина. – М.: Радио и связь, 1999. – 328 с.

17. Базы данных: Метод. указ. к курсовому проектированию. / Сост.: М.В. Копейкин, В.В. Спиридонов, Е.О. Шумова – СПб.: СЗТУ, 2004. - 172 c.

18. Вагнер Г. Основы исследования операций. Том 2. – М.: Мир, 1973. – 488 c.

19. Дженнингс Р. Access 97 в подлиннике. – СПб.: BHV – Санкт-Петербург, 1999. – 1268 c. IV. 3. Задания на контрольные работы и методические указания к их

выполнению

Студент выполняет две контрольные работы. Требования к оформлению

контрольных работ следующие: на титульном листе следует указать фамилию,

имя, отчество студента, шифр студента, название дисциплины и фамилию

преподавателя. В конце работ приводится список использованной литературы по

ГОСТ 7.1-84.

Поощряется выполнение контрольных работ, связанных с решением

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

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

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

A. 3.1. Контрольная работа № 1

Контрольная работа заключается в изучении и реализации методик

построения традиционной (основанной на теории нормализации) реляционной

модели или объектно-реляционной модели базы данных.

Согласно методологии проектирования традиционной реляционной

модели базы данных [3, 4, 10], предметная область должна быть описана единым

отношением, содержащим описание всех объектов и связей между ними. Под

объектом здесь понимается понятие, семантический смысл которого

сохраняется, если его можно рассматривать вне связи с другими объектами. Под

свойством объекта понимается понятие, семантический смысл которого

раскрывается только в связи с данным объектом. Под связью понимается

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

более объектов. Свойство связи - это понятие предметной области, имеющее

семантический смысл только по отношению к данной связи и теряющее его вне

этой связи.

Класс объектов (связей) - это множество объектов (связей между

объектами), характеризующихся одним и тем же набором свойств (речь идет о

самих свойствах, а не об их численных значениях).

Приведенные понятия не являются строгими, но позволяют на этапе

инфологического проектирования провести классификацию предметной области

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

едином отношении, описывающем предметную область. При этом важно учесть,

что данное отношение должно быть непротиворечивым, т.е. каждая проекция на

любую совокупность атрибутов исходного отношения должна адекватно

(семантически верно с точки зрения администратора базы) отражать

предметную область.

Пусть база данных должна содержать информацию о фрагменте

предметной области, описываемом следующим отношением: R (Имя отдела -

Х0, № служащего - Х1, Дата выполнения работы - Х2, № работы - Х3, № отдела

- Х4, № проекта - Х5, № помещения отдела - Х6, Площадь помещения - Х7, №

телефона - Х8, Стоимость проекта - Х9, № ставки - Х10, Фонд заработной платы

отдела - Х11, № руководителя отдела - Х12, Должность служащего - Х13, Оклад

служащего - Х14).

После инфологического этапа администратор выделил следующие классы

объектов и связей между ними: Q={Q1, ..., Q10}, Q1=(X4, X11, X12); Q2=(X1,

X10, X13, X14); Q3=(X5, X9); Q4=(X6, X7, X8); Q5=(X10, X13, X14); Q6=(X1,

X4); Q7=(X4, X5); Q8=(X4, X6); Q9=(X1, X2, X3); Q10=(X0, X4, X11, X12).

На уровне формальных значений атрибутов фрагмент состояния

отношения R представлен в табл. 1.

Элемент 0 (NULL значение) в отношении R указывает на отсутствие

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

атрибута Х12 (№ руководителя отдела) проставить для каждого служащего (Х1),

то проекция на атрибуты Х12, Х13, Х14 может нести семантически неверную

информацию.

Таблица 1

R X0 X1 X2 X3 X4 X5 X6 X7 X8 X9 X10 X11 X12 X13 X14 1 1 1 1 1 1 1 1 1 1 1 0 0 1 1 1 1 2 2 1 1 1 1 1 1 1 0 0 1 1 1 1 3 2 1 1 1 1 1 1 1 0 0 1 1 1 2 1 3 1 2 2 2 3 1 1 0 0 2 1 2 3 1 4 2 3 3 2 4 2 3 0 0 3 2 1 4 1 1 1 1 2 2 3 1 4 0 0 1 1 1 0 0 0 1 0 0 0 0 0 0 2 5 0 0 2 0 0 0 2 0 0 0 0 0 0 3 6 0 0 1 2 2 3 1 2 2 2 3 1 2 0 0 2 1 1 2 3 3 1 2 2 2 3 1 2 0 0 2 1 2 3 3 4 2 3 3 2 4 2 3 0 0 3 2 2 3 2 4 2 3 3 2 4 2 3 0 0 3 2 1 4 2 1 1 1 2 2 3 1 4 0 0 1 1

Перед студентом ставится следующая задача. Предложить способ

создания информационной модели (рассмотренной предметной области R) с

минимальной избыточностью для заданной совокупности объектов и связей

{Q}.

Для решения этой задачи могут быть использованы: теория нормализации

[1, 2, 4, 6], полный перебор вариантов или эвристические методы, один из

которых рассмотрен в [3]. Цель метода состоит в следующем: исходное

отношение R необходимо разбить на совокупность проекций F, суммарная

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

F позволяла бы восстанавливать исходное отношение R с помощью операции

эквисоединения [5 стр. 18] реляционной алгебры.

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

Последняя цифра шифра студента определяет число объектов из заданного

множества Q = {Q1, ...,Q10} предметной области R, представленной табл. 1.

Предпоследняя цифра шифра указывает на атрибут, который следует удалить из

отношения R (и, следовательно, в объектах из Q). Если последняя цифра шифра

0 или 1, то число объектов из Q определяется ближайшим большим среднего

значения суммы всех цифр шифра студента. Например, шифр студента 84-1000.

Тогда число объектов из Q будет равно Y=(8+4+1+0+0+0):6=13:6=2,1, т.е. Y=3.

Пример. Пусть шифр студента 1109. По последней цифре определяем, что

Q = {Q1, Q2, ..., Q9} - атрибут, не подлежащий учету, равен Х0. Далее,

используя методику [3], построим модель, удовлетворяющую перечисленным

ранее требованиям.

Этап 1. Выбор исходной информации.

Q = {Q1, ..., Q9} R=R(X1, X2, ..., X14).

Этап 2. Внесение уникальных идентификаторов и выделение объектов Qi,

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

которые пересекаются с другими объектами только по одному атрибуту:

Q1 = (α1, X4, X11, X12); Q2 = (α2, X1, X10, X13, X14); Q3 = (α3, X5, X9); Q4 =

(α4, X6, X7, X8); Q5 = (α5, X10, X13, X14); Q6 = (α6, X1, X4); Q7 = (α7, X4, X5);

Q8 = (α8, X4, X6); Q9 = (α9, X1, X2, X3).

Qi = {Q5} - объект Q5 является проекцией объекта Q2.

Qj = {Q1, Q2, (Q5), Q3, Q4}.

Q1 - пересекается только по атрибуту X4 с оставшимися объектами из Q.

Q2 - пересекается по X1 (без учета Q5).

Q3 - пересекается по X5.

Q4 - пересекается по X6.

Заметим, что объект Q9 также пересекается только по одному атрибуту

Х1, однако этот атрибут в объекте Q9 = (α9, X1 ,X2 ,X3) не имеет взаимно-

однозначного соответствия с внесенным уникальным идентификатором α9,

поэтому объект Q9 не попал в множество Qj.

Отметим, что каждый уникальный идентификатор по определению

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

отношение R из выделенных проекций, если эквисоединение производить по

уникальным идентификаторам. Кроме того, проекции Q1, Q2, Q3, Q4 обладают

минимальной мощностью (они находятся в третьей нормальной форме), поэтому

уже на этом этапе их можно включить в результирующую схему модели.

Этап 3. Для объектов, не попавших в Qj, строится отношение взаимосвязи

MQ по уникальным идентификаторам, которое представлено в табл. 2, и

матрица весов ребер полного графа G, соединяющего объекты MQ, Q6, Q7, Q8,

Q9 (табл. 3).

Построение табл. 3 происходит следующим образом: строки исходного

отношения нумеруются по порядку, и формируется пустая таблица, в которой

именам столбцов будут соответствовать имена уникальных идентификаторов

объектов, не попавших в Qj. Значения этих столбцов будут заполняться

значениями уникальных идентификаторов объектов, представленных в MQ.

Полученная матрица будет ничем иным, как отношением взаимосвязи объектов

по внесенным реляционным ключам.

Теперь, если представить взаимосвязь этих объектов в виде полного графа

(рис. 1) и дугам этого графа присвоить соответствующие веса, то решить эту

задачу можно с помощью методов динамического программирования [18, стр. 8]

(задача о дилижансах), один из таких методов (задача Прима) и рассмотрен в [3,

стр. 81].

При определении веса ребра полного графа, соединяющего объекты,

приведенные в табл. 3, определяется рациональность по-парного объединения

объектов, что отмечается рассчитанным значением в табл. 3. Так, например,

совместное хранение объекта MQ (табл. 2) и объекта Q6 дает выигрыш в одну

условную единицу.

Расчет веса (P) дуги графа между двумя вершинами Qm и Qn

производится по следующей формуле (общий случай рассмотрен в [3, стр.

79]): P = VQm+VQn – (A-1)*RMQ +K ,

где VQi – объем (мощность) отношения Qm и Qn соответственно;

A – число уникальных атрибутов в склеиваемых отношениях;

RMQ - число кортежей в проекции на отношение MQ для склеиваемых

отношений.

K = 0, если одно из склеиваемых отношений MQ, иначе K = RMQ

Таблица 2 Таблица 3

Рис. 1. Полный граф с весами дуг для табл. 3

Например, вес дуги между вершинами Q7 и Q8 будет 9+9-(5-1)*4+11=13.

В результате склеивания объектов Q7 и Q8 получится новый объект

Q78(α78, X4, X5, X6), и в отношении MQ уникальные идентификаторы α7 и α8

заменятся на один идентификатор α78.

Следующие этапы сводятся к известному алгоритму поиска

экстремального дерева [18] на заданном графе с критерием минимального веса

полученного пути.

В нашем случае это будет выделение групп объектов, которые

рациональнее хранить в виде отдельных отношений (проекций) F из R, при этом

восстановимость исходного отношения R из полученных проекций F

гарантируется этапом 2 и введением отношения MQ, устанавливающим связь

между объектами хранения на основе уникальных идентификаторов.

В результате применения методики [3] получаем следующую

конфигурацию модели F = {F1, ..., F6}:

F1 (α1, X4, X11, X12) - содержит объект Q1 – Отдел (№ отд, Фз, № рук); F2 (α2, X1, X10, X13, X14) –содержит связь объектов Q2 – Служащий (№ сл, № ст, Дол, Окл) и Q6 – Ставка (№ ст, Дол, Окл),; F3 (α3, X5, X9) - содержит объект Q3 – Проект (№ пр, Сп);

F4 (α4, X6, X7, X8) - содержит объект Q4 – Помещение (№ пом, Пл, № тел ); F5 (αMQ, αk,X1(α2), X2, X3) - содержит связь Служащего с объектом Q5 – Виды работ (№ сл, № раб, Дата,); F6 (αk, X1(α2) ,X4(α1), X5(α3), X6(α4)) - содержат связь служащего с отделом (Q7 – Отдел_Служ (№ отд, № сл)), проекта с отделом (Q8 – Проект_Отдел (№ пр, № отд) и отдела с помещением Q9 – Отдел_Помещение (№ отд, № пом), где выполняются проекты.

Отметим, что мощность (число элементов) исходного отношения R (табл.

1 с учетом шифра студента 1109) с 182 условных единиц уменьшается до 128

единиц (чтобы в этом убедиться, просчитайте число элементов в R и в {F}).

Полученная конфигурация модели приведена на рис. 2.

Рис. 2. Состав отношений модели для табл. 1

Уникальный идентификатор "αi" в скобках, например, Х1(α2) указывает о

логической согласованности атрибутов по внесенным уникальным

идентификаторам, что в графе информационно-логической модели

подразумевает наличие связи через "K", "Q" или "H" классификаторы [7] или

присутствие в нормализованной схеме модели описания первичных и внешних

ключей [1, 2].

Если воспользоваться методами теории нормализации, то для

рассмотренного отношения (табл. 1) может быть получена следующая

реляционная модель, каждое отношение Ri (рис. 3) которого находится в

четвертой нормальной форме [6]. Данный пример подробно рассмотрен в [2].

R1 (№ отд, Фз, № рук) R2 (№ сл, № ставки)

R3 (№ ставки, Дол, Окл) R4 (№ сл, Дата, № отд)

R5 (№ пр, Сп, № отд) R6 (№ пом, Пл, № отд)

R7 (№ сл, № пр, № тел) R8 (№ тел, № пом)

R9 (№ раб, № пр, Оп)

Рис. 3. Состав нормализованных отношений модели для табл. 1

Полученная конфигурация классической реляционной модели получена

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

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

ни один отдел не имеет одновременно более чем одного руководителя;

ни один служащий не работает одновременно более чем в одном отделе;

ни один служащий не работает более чем над одним проектом и одной

работой этого проекта;

ни один служащий не имеет больше одной ставки;

ни один служащий не имеет более одного телефона;

каждый проект выполняется только одним отделом;

ни одно помещение не предназначено более чем для одного отдела;

выполняемая служащим работа относится к определенному проекту;

в один день служащий не работает более чем над одной работой.

Реляционные ключи в отношениях подчеркнуты и должны быть описаны

ключевым словом PRIMARY в описании схемы модели [1, 2, 4, 6].

Если воспользоваться методами проектирования, изложенными в [6, 7,

17], то конфигурация модели может быть представлена рис. 4, на котором

представлены, пять фреймов: Служащий (S(№ сл,<характеристики

служащего>)) - рис 4 (а); Ставка(S(№ ставки, Дол, Оклад) – рис. 4 (б);

Помещения(S(№ пом, Пл, V(№ тел), Q(№ отдела)) – рис. 4 (в); Отдел(S(№ отд,

Фз, № рук-Q(№ сл), V(Сотрудники(H(Служащий), K(Ставка))) – рис. 4 (г);

Проект(S(№ пр, Сп, V(Исполнители(Q(Сотрудники), Дата, № раб, Описание

работы)))) – рис. 4 (д).

Рис. 4. Состав инфологической модели для табл. 1

На рис. 4 не показана прямая связь между понятиями СЛУЖАЩИЙ,

СОТРУДНИК и ИСПОЛНИТЕЛЬ, но статус частей, в которых она используется,

подразумевает наличие такой Q-связи. Кроме того, наличие "H" связи в форме

рис. 4 (г) позволяет наследовать все свойства объекта СЛУЖАЩИЙ, когда он

становится сотрудником какого-либо отдела. На рис. 4, также не показаны

правила для установления ограничений по Q-H связям, и правила по

ограничениям мощности структурных связей внутри форм [7].

B. 3.2. Контрольная работа № 2

Контрольная работа 2 заключается в построении (отображении)

полученной конфигурации F модели предметной области в среде любой

доступной студенту СУБД (важно, чтобы реализованная контрольная работа

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

институтом).

В работе должны присутствовать:

- краткие характеристики используемой СУБД;

- описание процесса построения баз данных из контрольной №1 с

указанием и описанием команд конкретной СУБД;

- описание схемы модели на языке SQL или на другом DDL;

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

отношений из конфигурации.

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

операции:

- добавить (INSERT);

- удалить (DELETE);

- изменить (UPDATE).

V. 4. Методические указания к выполнению лабораторных работ

Лабораторные работы по дисциплине «Базы данных» составлены в

инструментальной среде "ORD"(ORD – Object-Relational Dynamic Data-Frame Structures

– объектно-реляционные динамические фреймовые структуры), позволяющей

автоматизировать процесс создания информационной модели как совокупности

взаимосвязанных документов (понятий) предметной области.

Выбор указанной системы для проведения лабораторных работ

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

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

реляционного типа. Поэтому полученные навыки и построенные модели могут

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

принципов реляционного отображения данных, например таких, как INGRES,

MS SQL, ORACLE, INFORMIX, ACCESS и т.д.

Система ORD включает большое количество утилит, облегчающих

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

В любой момент студенту доступен HELP системы (вызывается по

нажатию клавиши "F12") и контекстная помощь (вызывается по клавише "F1").

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

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

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

Использование методологии ORD позволяет создавать единую интегрированную информационную модель любой предметной области, сохраняя (при небольших затратах) разработанное прикладное программное обеспечение при ее развитии.

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

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

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

- возможность получения ответа на запрос (по любому сочетанию атрибутов) с помощью высокоуровневого языка запросов (QBE), контролирующего степень достоверности ответа;

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

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

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

Система может функционировать как на одной машине, так и на сети ЭВМ, причем в последнем случае, она обладает рядом уникальных возможностей, например:

- возможностью параллельной работы одной и той же информационной подсистемы (АРМ) в различных узлах сети, без нарушения целостности и достоверности хранимых данных;

- возможностью работать как в односерверном, так и многосерверном варианте, используя при этом в качестве серверов любые ЭВМ сети;

- выход из строя любой ЭВМ сети, как и аварийное завершение любой программы, не приводят к "краху" всей системы и не требуют выполнения трудоемких процедур по её восстановлению. При этом ORD всегда контролирует выход в операционную систему при аварийных ситуациях, что позволяет блокировать возможность появления в приложении "сбойной" информации;

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

- возможностью контролировать процесс освобождения буферов ОС при записи информации на диск, тем самым предотвращается спонтанность процесса актуализации данных и все проблемы сопутствующие данному процессу;

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

- встроенными средствами, обеспечивающими поддержку режима "разорванного" времени для географически разнесенных филиалов предприятия.

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

Все лабораторные работы содержат раздел «ОСНОВНЫЕ

ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ», в котором приведены сведения,

необходимые студентам для создания объектов модели (в системе они носят

название формы или документа) в "ручном" режиме. Наряду с "ручным"

режимом создания документа (принятым в некоторых системах) система

предоставляет и полуавтоматический режим.

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

первую лабораторную работу для ознакомления с системой распределенной

обработки данных и уяснить основные архитектурные особенности СУБД,

которые соответствуют стандарту ANSI\SPARC [2]. Все следующие работы

касаются вопросов инфологического, концептуального, внешнего и физического

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

Студентам на первой стадии освоения системы ORD рекомендуется

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

понять процесс функционирования системы ORD.

A. 4.1. Работа 1. Ознакомление с особенностями интегрированной среды СУБД

I. ЦЕЛЬ РАБОТЫ

Изучить основные принципы формирования моделей в инструментальной

среде ORD.

П. ОСНОВНЫЕ ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ

Любая предметная область разбивается на ряд информационных

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

модели системы, студенту предложена информационная модель реального предприятия, в котором представлены, например, следующие подсистемы: основные средства (SUBO); материальные ценности (SUBM); учет труда и начисление заработной платы (SUBT); учет финансово-расчетных операций (SUBF); учет затрат на производство (SUBJ); учет и реализация готовой продукции (SUBG); баланс предприятия (SUBB) и любые другие необходимые в данной предметной области подсистемы.

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

модуль ORD.exe (или T.exe) из папки указанных подсистем.

В любой СУБД существует набор специальных справочников, в которых

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

данные. К таким справочникам в системе относится таблица с именем SIORD. В

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

и набор таблиц: SIIM, SIUEK, SIAGF, SIAOF, совокупность которых

рассматриваетс я как средство описания модели предметной области (см. [17],

Приложение 2).

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

документов (понятий) доступных подсистеме. Таблица SIUEK содержит

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

документа, SIAOF.DBF - список файлов документа.

Кроме информационных подсистем, в системе присутствуют еще две

папки SUBS и SUBU. В первой папке хранятся исходные тексты программ и

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

функционирования системы.

Так как на основе данной лабораторной работы осуществляется первое

практическое знакомство студентов с системой, то начнем это знакомство с

создания простейшего документа, состоящего из одной части и включающего в

свой состав только один файл (таблицу).

Пусть нам требуется создать документ в информационной подсистеме, с

именем "T" в папке ORD "SUBT". Замечание. В качестве примера воспользуемся инфологической моделью (ILM) Ставка

(№ ставки, Должность, Оклад) – рис. 4 (б). Отметим, что создаваемая таблица (файл) относится к категории справочников, в которых будут зафиксированы все разрешенные на данном предприятии тарифные ставки. Фактически это константа для данного предприятия.

Запустите в работу инструментальную оболочку Db.exe (командный файл

D.bat находится в папке - <диск>:\ORD\SUBT\PRGWIN\d.bat) и система откроет

окно SIORD, установив указатель в нем на имени SIIM (на рис. 18 показано окно

SIORD для подсистемы "L"). Примечание. В зависимости от версии системы окно справочника SIORD может иметь

вид, показанный на рис. 15 или рис. 18.

Процесс создания документа в ручном режиме состоит из следующих

шагов:

1. Открыть ("F11 – Ред.БД") и добавить (F3) запись в таблицу SIIM.

Заполнить ее. Нажать "F5 – Создать документ" и система предложит таблицу

структуры модели.

2. Модифицировать структуру модели документа в предложенной таблице

и выйти с сохранением (F2).

3. Модифицировать предложенный экранный образ документа под Ваши

условия и выйти из модификации с сохранением (F2).

4. Указать пункт меню, где должна обрабатываться созданная форма.

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

Шаг 1.

Для создания любого документа в системе ему необходимо присвоить

системный номер (глобальная переменная в системе с именем TDOK) и указать

его смысловое название.

Пусть системный номер создаваемого документа будет TDOK = 00TC, а

его название - "Тарифные ставки". Войдем в область файла SIIM (клавиша "F11

– РедБД", рис. 18), добавим в SIIM новую запись и занесем в нее указанную

информацию (рис.5).

Столбец Номер (рис. 5) содержит тип документа, столбец Имя документа

- название документа, остальные поля на данном этапе "означивать" не

обязательно.

Далее надо нажать клавишу "F5 – Создать", и система предложит указать,

сколько частей (в нашем случае одна часть) содержит новый документ, и

перейти к шагу 2.

Шаг 2.

Описать структуру (подчиненность и направленность дуг графа,

обязательность наличия вершин в графе и т.п.) модели документа в

предложенной таблице (рис. 6).

Рис.5. Описание файла SIIM для документа TDOK= 00TС в подсистеме "T"

Рис. 6. Описание таблицы структуры для документа TDOK = 00TC

Так как создаваемый документ состоит из одной части, то в предложенной

таблице изменим только статус части "O" на статус части "S", тем самым

прикажем системе оповещать пользователя (в момент создания нового

документа) о существующем списке экземпляров документа подобного типа.

Если из данного режима выйти с сохранением (F2 – рис. 6), то система

перейдет к шагу 3 и предложит модифицировать шаблонный образ формы под

конкретные условия.

Шаг 3.

В представленной пустой форме (рис. 7) необходимо заменить шаблонное

имя атрибута и поля, например, на N ставки (тип поля символьный, длина 5).

Для этого надо выбрать пункт меню "Поле" и система предложит в качестве

базового понятия использовать одно из множества ей известных (рис. 8).

Рис. 7. Экранный образ пустого фрейма для документа TDOK = 00TC

В реальной практике формируемая модель наверняка уже использована в

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

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

системы ("F2 – Выйти и сохранить"), а нажмем клавишу Esc или F10 “Выход без

сохранения ”(рис. 8).

Рис. 8. Список понятий (моделей), известных системе

Система среагирует на Ваше решение и предоставит окно (рис. 9), в котором необходимо указать характеристики поля (N ставки).

Рис. 9. Формирование свойств (статуса) поля

Примечание. Переход из одного поля окна (рис. 9) на другое осуществляется клавишами стрелка "вниз" и "вверх". Раскрытие поля на модификацию его содержимого производится клавишей Enter. Имена файлов и полей файлов система генерирует автоматически (уникальность обеспечивается), но их в случае необходимости можно модифицировать. Все файлы (таблицы), использованные в документе, будут зафиксированы в системной таблице SIAOF (рис.14), а их характеристики - в таблице SIORD (рис. 15).

Назначение и типы статусов полей достаточно подробно рассмотрены в [6,

17], здесь же только отметим, что для нашего примера это будет обычное GET

поле (статуса "G"), куда пользователь будет вводить информацию. Ручной ввод

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

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

После заполнения указанных полей окна на рис. 9 и выхода с сохранением

(F2) система отобразит введенную информацию в координатах экрана (рис. 10),

которые можно модифицировать с помощью первой левой кнопки, показанной

на рис. 10.

Далее, используя кнопку "F6 – Добавить поле" (рис. 10), формируется

отображение полей Должность и Оклад (рис. 11) путем ввода данных в окно,

показанное на рис. 9. В результате получим, например, экранный образ (рис. 11).

Рис. 10. Меню визуальной формы после ввода информации

Рис. 11. Экранный образ документа TDOK = 00TC

Если больше полей нет, для вставки их в экранный образ и не надо

вводить заголовок формы, то следует нажать кнопку "F2 – Выйти и сохранить"

(рис. 11).

Если файлы, использованные в документе, новые для системы, то они

будут созданы и их описание будет сохранено в таблице SIORD (рис. 15). Если

файл уже существует в системе и его структура модифицировалась в процессе

создания документа, то модификация будет осуществлена как над физическим

файлом, так и в описателе SIORD.

Система сформирует все необходимые модели для данной формы и

сохранит их в таблицах SIUEK (рис. 12), SIAGF (рис. 13), SIAOF (рис. 14) и

SIORD (рис. 15). В процессе формирования концептуальной, внешней и

внутренней моделей система уточнит, в каком пункте меню должен находиться

сформированный документ, и возможна ли обработка данного документа в

географически разнесенных локальных сетях.

Отметьте, что в таблице SIAGF автоматически фиксируется логическая

структура формы, т. е. фактически это описание структуры графа

инфологической модели отображаемого понятия. При этом внешняя модель

(таблица SIUEK) связана с таблицей SIAGF начальной и конечной строкой

документа (столбцы "Начало" и "Конец на рис". 13).

Рис. 12. Таблица SIUEK. TDOK = 00TC

Рис. 13. Таблица SIAGF. TDOK = 00TC

Отметим, что основной постулат, на котором построена традиционная

реляционная модель, опирается на концепцию универсального отношения [8, c.

396], рассматриваемая же методология опирается на предположение, что любая

ситуация в предметной области, подлежащая отображению в системе, может

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

65]. Именно для хранения общей структуры такого графа и служит таблица

SIAGF.

На уровне экземпляра хранимого объекта (документа) информация о

динамической структуре графа фиксируется в специальном поле "Маршрут

документа", имя которого система формирует автоматически и прописывает его

в основном (головном) файле документа. На рис. 15 имя такого поля S0TC в

файле с именем TTA0.

Рис. 14. Таблица SIAOF. TDOK = 00TC

Рис. 15. Таблица SIORD. Файл TTA0

Кроме служебного поля "Маршрута док.", каждый головной файл имеет

еще поле с именем SSSM, в котором фиксируется информация о типе документа

(TDOK), создавшем конкретный экземпляр данного типа документа. Примечание. Понятие ФОРМА (документ) - это не обязательно таблица или термин таких

СУБД, как ACCESS, FOXBASE, ALASKA, PARADOX и т.д., - это, прежде всего, иерархически упорядоченное отображенное множество объектов (связей и т.д.), хотя в некоторых случаях эти

понятия можно воспринимать как эквивалентные, как, например, в рассмотренном нами примере. Прежде чем представим результат проделанной нами работы (см. рис. 16),

остановимся на понятии статуса файла, использованного на рис. 6.

Понятие статуса файла определяет причинно-событийные правила

появления информации в структуре документа. Само понятие файл определяется

стандартно, как поименованная структура данных – это типовое определение,

принятое в языках программирования.

Каждому типу TDOK документа соответствует множество Ψ (TDOK)

файлов (рис. 14), содержащих информацию всех экземпляров документа

данного типа.

Если файл F принадлежит множеству Ψ (TDOK), то будем говорить, что F

является файлом документа типа TDOK.

По роли файла в структурно-функциональной модели документа,

называемой далее статусом файла, файлы подразделяют на основные,

внутренние, внешние и классификаторы.

Каждый файл F, используемый в системе, имеет в своей структуре поле

(первое по порядку) с уникальным для системы именем A, играющее роль

объектного идентификатора для записей этого и только этого файла F. Это поле

называется СОБСТВЕННЫМ ЯКОРЕМ (СЯ) файла F (рис. 15, первая строка

описания файла ТТA0 имя поля tTA0 (семантический код для поля равен 20)).

Поле с тем же именем A, имеющееся в другом файле G, но не являющееся

в его структуре первым по порядку называется в системе ВНЕСЕННЫМ

ЯКОРЕМ (ВЯ) файла G.

Определение. Файл F, принадлежащий Ψ (TDOK), называется

ОСНОВНЫМ файлом документа типа TDOK, если объектный идентификатор

экземпляра (собственный якорь) документа типа TDOK является собственным

якорем файла F.

Из определения следует, что:

1) каждому экземпляру документа (NDOK) в основном файле

соответствует одна и только одна запись;

2) во множестве Ψ(TDOK) имеется один и только один основной файл.

Основной файл документа обозначается в системе символом "O", "S", "X"

или "x" и содержит системное поле МАРШРУТА (поле с именем "S" +

right(TDOK,3)), где хранится маршрут экземпляра документа – информация,

указывающая, какая часть фрейма [17] означена в данном экземпляре документа.

Содержимое поля маршрута автоматически формируется и контролируется

системой.

Назначение полей таблицы SIORD рассмотрено в [17], приложение 2,

здесь рассмотрим некоторые значения поля с именем "Сем. код – семантический

код" (рис. 15):

20 - обозначает, что данное поле является якорным;

21 - поле содержит внесенный якорь;

1 - поле заполняется ручным способом и является собственным свойством

данной части документа;

6 - значение поля вычисляется.

Для выполнения лабораторных работ вполне достаточно понимание

приведенных значений семантического кода. Кроме того, можно провести

некоторую ассоциацию между понятиями PRIMARY KEY и FOREIGN KEY [1,

2, 4, 6] и понятиями собственного и внесенного якорей соответственно [7].

Подчеркнем, что подключение нового документа в меню подсистемы

фиксируется автоматически в системной таблице с именем SIMN и для

рассмотренного примера документ TDOK = 00TC представлен в группе

"Справочники" (рис. 16).

Модификация любой из рассмотренных моделей (рис. 12 - 15) требует

проведения процесса создания эталона документа (кнопка "F7 – Эталон", рис.

15), иначе эти модификации будут не отражаться в поведении документа,

представленного на рис. 16.

Ш. ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ

1. Ознакомиться с теоретическими положениями.

2. Загрузить утилиту db.exe интересующей Вас подсистемы.

3. Заполнить системную таблицу с именем SIIM.

4. Сформировать эталон документа.

5. Запустить программу ORD.exe (t.exe) и заполнить (создать) экземпляр

документа. Ознакомиться с режимом редактирования и просмотра документа.

Рис. 16. Экран формы после запуска ORD.exe IY. СОДЕРЖАНИЕ ОТЧЕТА

1. Краткое описание принципов построения информационных объектов

(документов) в среде ORD.

2. Описание содержимого таблиц SIIM, SIORD, SIUEK, SIAGF для

разрабатываемого документа (аналогично приведенному примеру).

B. 4.2. Работа 2. Построение формы, содержащей К-связь


Освоить практические приемы создания новых информационных

подсистем и использовать К-классификаторов в формах.


Определение. Файл (таблица, список) F, принадлежащий Ψ (TDOK),

называется КЛАССИФИКАТОРОМ документа типа TDOK, если его записи

могут создаваться вне связи с процессом заполнения экземпляров документа.

При заполнении экземпляров документа классификатор документа обычно

используется в режиме "прокрутки", так как только пользователь может

определить, какую запись, из имеющихся в классификаторе, следует внести в

документ. Раскрытие К-классификатора, для выбора из него значения,

осуществляется нажатием Enter или двойным щелчком мышки.

Классификаторы часто применяются для хранения информации, которая

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

экземпляр документа пользователем в процессе просмотра хранящихся в нем

записей. Иногда классификаторы используются для повышения скорости и

достоверности ввода данных, но основное функциональное назначение их

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

какой-то элемент системы. При этом разрешено использование рекурсивного

вызова при многоуровневом вложении классификатора в классификатор.

Механизм классификатора построен на ссылочной связи между файлами,

при которой системный номер выбранной из классификатора записи заносится в

поле A некоторого файла F документа TDOK, причем имя этого поля должно

совпадать с именем собственного якоря классификатора, а семантический код в

SIORD равен 21.

Этот механизм похож на связь типа SET RELATION используемый в

некоторых СУБД реляционного типа, но имеет существенное отличие,

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

Кроме того, он позволяет фиксировать (выделять) отношения типа: "целое-

часть", "подчиненность", "включение" и другие, возникающие между объектами

(связями) одного и того же или разных типов объектов.

В системе ORD имеются классификаторы трех типов:

1) простой классификатор (K) - файл, содержащий только два поля.

Первое поле используется для хранения СЯ, второе - для хранения данных,

подлежащих прокрутке. Имя второго поля в простом классификаторе

стандартно для всей системы - "NNN2". Система следит за уникальностью

значений в данном поле, т.е. это поле является реляционным ключом в файле

типа "K".

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

значений какого-либо атрибута предметной области;

2) сложный классификатор (Q) - файл, содержащий произвольное число

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

поле, которое носит название поля "прокрутки".

В процессе выбора записи из Q-классификатора высвечивается набор

полей файла Q, задаваемый при создании образа классификатора. Порядок

следования полей (атрибутов) в окне прокрутки файла Q определяется полем

"Поиск". Если в этом поле все значения одинаковы, то поля в окне прокрутки

показываются в порядке их записи в образе, а полем "прокрутки" считается

первое из них. Если же для какого-то из атрибутов в поле "Поиск" записана

единица, то статус поля "прокрутки" получает поле, соответствующее этому

атрибуту.

Информация из поля "прокрутки" файла Q копируется в созданное

системой специальное поле в файле, в котором используется Q- классификатор,

и само это поле может не быть реляционным ключом в файле Q.

ORD допускает любой уровень вложенности Q (т.е. поле Q в свою очередь

также может быть Q или K и т.д.);

3) модельный классификатор (H) - файл (группа файлов), содержащий

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

экране.

Модельный классификатор (H) может быть документом, что позволяет

поддерживать в системе структуры объектов любой сложности.

Связь модельного классификатора с другим документом может

"ограничиваться" специальным семантическим кодом (поддерживаемым

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

при связывании различных объектов предметной области и совместимости

данных, хранимых в документах системы.

Любые свойства объектов, представляемые классификаторами типа Q и H,

могут быть скопированы в объект, с которым они связываются, если в этих

классификаторах указаны правила копирования (см. [7], приложение 1 и [17],

параграф 2.2).

С точки зрения моделей баз данных, наличие таких классификаторов

позволяет использовать возможности иерархического, сетевого и реляционного

отображений данных и строить фреймовые структуры данных любой

сложности.

Классификаторы документа обозначаются в системных таблицах SIAOF,

SIUEK и SIAGF символами "K", "k", "Q", "q", "H", "h".

В лабораторной работе N1 был рассмотрен пример простейшего

документа. Проанализировав этот пример, видно, что информация о должностях

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

той же информации (и избежания ошибок ввода) можно создать файл, в котором

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

дальнейшем использовать его как К-классификатор (K-связь).

Прежде чем знакомиться, как создаются и прописываются К-связи в

моделях, рассмотрим один из способов создания новой информационной

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

моделями.

Число информационных подсистем, которые могут обслуживаться СУБД,

практически не ограничено, но степень их взаимосвязи по используемой

информации может быть существенно разной. Поэтому, экспериментируя с

какой-либо действующей подсистемой, мы можем неявно нарушить не только ее

целостность, но целостность и безопасность связанных с ней подсистем.

Для выполнения лабораторных работ рекомендуется создать

информационную подсистему с именем SUBL (имя этой подсистемы

зарезервировано в ORD под учебную подсистему), а другими подсистемами

пользоваться как базой знаний. Чтобы создать любую другую систему следует

указать при запуске Db.exe соответствующий код.

Один из способов создания SUBL рассмотрен в [17] (параграф 4.2, рис. 5).

Здесь же для создания учебной подсистемы воспользуемся системной таблицей

SISOA (список подсистем, к которым разрешен доступ из текущей подсистемы и

распределение подсистем по машинам сети).

На рис. 17 представлена таблица SISOA (которая естественно описана в

описателе SIORD), раскрытая на редактирование кнопкой "F11 – Ред. БД", когда

маркер курсора находился на имени файла SISOA в таблице SIORD (рис. 15 или

18).

Если в таблицу (рис. 17) добавить новую запись и в ней указать новое

значение имени подсистемы (в столбце "Подсистема"), то система уточнит

смысловое имя создаваемой подсистемы и создаст новую папку с именем SUBL.

Будут созданы и соответствующие поддиректории (согласно рис. 37, пункт 4.5.3

из [17]), в которых будет находиться вся информация, необходимая для

функционирования новой подсистемы.

Рис. 17. Состав таблицы SISOA с добавленной записью

Примечание. Символ "P" в столбце синхронность указывает, что подсистема SUBF

(или ее подмножество) может синхронно использоваться на других машинах локальной сети.

При нажатии кнопки "F10 – Выход" (рис. 17) система обеспечит доступ к

тем подсистемам, которые указаны в таблице SISOA. После создания

подсистемы с именем SUBL и сообщения системы о создании новой

информационной подсистемы система закроет таблицу SISOA и вернется в

окно SIORD (рис. 15), ожидая Вашего следующего шага.

Нажатие F10 (рис. 15) позволит перейти на вновь созданную подсистему, в

которой в таблице SIIM уже будут находиться два стандартных документа:

TDOK = 0P00 - "Генератор печатных образов" и TDOK = 0717 -

"Информационный запрос". Первый предназначен для создания печатных

документов, а второй для генератора незапланированных запросов (QBE).

Если будет произведена попытка запуска исполняемого модуля T.exe

(ORD.exe), то система предоставит экран, подобный показанному на рис. 16, но

естественно документов в меню подсистемы Вы не увидите. Однако все

сервисные услуги в созданной подсистеме будут присутствовать (см. кнопки

“Сервис” и “Связь” на рис. 16).

Для того чтобы Ваши труды (при исполнении первой лабораторной

работы) не пропали, можно скопировать документ TDOK = 00TC (как и любой

другой) в подсистему с литерой "L".

Для этого необходимо перейти в подсистему SUBL и нажать клавишу "F3

– Добавить", тогда система откроет вам следующее меню (рис. 18).

Рис. 18. Вспомогательное меню по кнопке "F3 - Добавить"

После подтверждения пункта меню "F3 – Добавить Чужой документ" в

подсистему "L" система задаст ряд уточняющих запросов, чтобы определить из

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

будет (рис. 19).

Рис. 19. Вспомогательное меню по кнопке "F3 - Добавить"

Если принять первый вариант, то права доступа к скопированному

документу (как и его правила обработки) будет определять подсистема его

"родившая", поэтому логичнее будет воспользоваться вторым вариантом.

Помните, что в любой ситуации нажатие клавиш F1 или

F12 позволяет получить контекстную помощь по любому

вопросу.

Если будет принят второй вариант решения, система предоставит

возможность переименовать имена старых таблиц и их столбцов к

необходимому Вам виду или по Вашему желанию выполнит эту работу сама.

В результате проведенной работы может быть получено сообщение вида

(рис. 20).

Рис. 20. Сообщение о результатах копирования

После нажатия любой клавиши система предоставит вам таблицу SIUEK

для редактирования. Описательная ее часть будет полностью идентична рис. 12,

но имя файла, имена полей будут естественно другими (рис. 21).

Соответствующим образом изменятся и все другие модели, но их суть не

изменится, если не считать, что автоматически модифицируется имя

маршрутного поля документа (рис. 22).

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

исполняемом модуле (рис. 16 только для подсистемы "L"), необходимо создать

его эталон (см. первую работу).

Рис. 21. Состав таблицы SIUEK поле копирования

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

классификаторов в модели документа.

Существует несколько способов встраивания К-связи в форму, например,

один из способов подразумевает следующие шаги:

1. Описать и создать файл простого классификатора в SIORD.

2. Модифицировать описание файла, в котором будет использоваться

классификационное поле в SIORD.

3. Модифицировать экранный образ документа в SIUEK.

4. Модифицировать в случае необходимости таблицу SIAGF.

5. Создать эталон документа.

Шаг 1.

Пусть в качестве файла, в котором будем хранить список должностей

существующих на предприятии, выберем имя файла LJAJ и опишем его в

справочнике SIORD.

Пусть описание файла LJAJ в SIORD представлено на рис. 22.

Добавление записей в SIORD происходит по "F3 – Добавить" (логическая

структура таблицы), а создание физического файла по клавише "F2 – Создать".

Именно вновь созданный файл с именем LJAJ должен быть использован в файле

LLAF в качестве K-классификатора.

Рис. 22. Описание состава полей простого классификатора

Шаг 2.

Модификация существующего файла LLAF осуществляется по нажатию

клавиши "F9-Модификация (Моди. Стр.)" из окна таблицы SIORD.

Войдя в режим модификации, Вам следует удалить поле LAAH и добавить

поле LAAJ, указав при этом семантический код равный 21.

Соответственно описание файла LLAF будет следующим (рис. 23).

Рис. 23. Измененная структура основного файла LLAF

Примечание. При создании эталона документа система добавит в файл LLAF поле с именем ZLAJ, в которое будет заноситься вид должности в момент создания документа TDOK = 0006.

Шаг 3.

Перейти в область файла SIUEK и заменить поле LLAH на LJAJ.

Описание таблицы SIUEK будет таким (рис. 24).

Система

N образа Имя атрибута на экране Упр Коор Y

Коор X

Файл Поле Y поля

X поля

Поиск

Тип Длина

Точность

SI75 SI52 SI65 SI70 SI66 SI67 SI20 SI26 SI68 SI69 SI72 SI56 SI57 SI769700 UL006001 Ся Ставки M 0 0 LLAF LLAF 0 0 0 C 2 0 9702 UL006001 N ставки G 5 15 LLAF LLAG 5 22 1 C 5 0 9704 UL006001 Должность 1 K 11 25 LLAF LJAJ 11 54 0 C 15 0 9724 UA006001 Оклад G 21 25 LLAF LLAI 21 54 0 N 5

Рис. 24. Описание документа TDOK = 0006 в SIUEK

Поясним строку SIUEK (рис. 24) с адресом "9704": при использовании в

документе К-классификаторов в поле SI26 указывается имя файла простого

классификатора, а в последнем разряде поля SI65 указывается длина якоря

классификатора (для нашего документа это длина поля LJAJ в файле LLAF).

Значения полей SI56, SI57, SI76 характеризуют поле "прокрутки" простого

классификатора (т.е. поле NNN2 в файле LAAJ).

Шаг 4.

Заполнение таблицы SIAGF.

При модификации таблицы SIUEK не было добавлено ни одной записи,

следовательно, адреса части документа в таблице SIAGF остались без изменений

(см. лабораторную работу N1).

Шаг 5.

Создание эталона документа осуществляется при нажатии клавиши F7 из

области SIORD (рис. 23).

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

SIAOF строку с именем файла К-классификатора.

Описание таблицы SIAOF будет следующим (рис. 25, а):

Рис. 25. Описание документа TDOK =0006 в SIAOF (а) и ILM формы (б)

Другой способ встраивания K-связи в образ документа состоит в

следующем. Необходимо перейти на окно SIIM, например, если Вы находитесь в

таблице SIUEK (рис. 21), то переход осуществляется кнопкой "F9 – SIIM", и

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

внешняя модель для модификации (рис. 9) ее в визуальном режиме (рис. 11).

Установив маркер курсора на интересующее нас поле (Должность), нажмем

кнопку "Статус поля" (рис. 11) и заменим статус поля "G" на "K" (рис. 26).

Далее следует выбрать имя понятия (файла) или указать новое для

создаваемой K-связи (рис. 26) и указать характеристики для поля с именем

"NNN2" (наличие этого поля обязательно для файла K-классификатора).

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

модифицированы все модели документа TDOK = 0006 - "Тарифные ставки" и

документ будет зафиксирован в меню подсистемы.

Рис. 26. Замена GET поля на К-связь

Практически любое информационное поле может быть оформлено в виде

К-классификатора (если в этом есть смысл) и его изображение на экране

совпадает с изображением Q-связи (см. рис. 37, атрибут Фамилия рук.).


1. Ознакомиться с теоретическими положениями

2. Загрузить утилиту db.exe

3. Заполнить управляющие системные файлы

4. Сформировать эталон документа

5. Запустить программу Т.exe и заполнить (создать) экземпляр документа.

Ознакомиться с режимом редактирования и просмотра документа.

IY. СОДЕРЖАНИЕ ОТЧЕТА


(документов) в среде СУБД.

2. Описание содержимого файлов SIIM, SIORD, SIUEK, SIAGF для

разрабатываемого документа, содержащего К-связь.

C. 4.3. Работа 3. Построение формы, содержащей Q-связь


Освоить использование Q-классификаторов в документах.


Сложный классификатор (Q) – файл (таблица), содержащий произвольное

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

одно поле (в процессе выбора или создания записи высвечивается любой набор

полей).

Как правило, Q-классификатор представляет собой самостоятельный

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

либо другом документе.

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

объектов инфологического уровня в качестве Q-связи. В качестве примера

поясним использование объекта СЛУЖАЩИЙ (рис 4, а или рис. 27, б), как Q

связь в документе, ILM которого показана на рис. 4, г, упростив его до

следующего вида (рис. 27, а).

Рис. 27. ILM упрощенного понятия Отдел и Служащий

Для того чтобы использовать объект как Q-связь, необходимо, чтобы этот

объект уже существовал в системе. Поэтому либо скопируем объект

СЛУЖАЩИЙ из другой подсистемы (см. описание процесса в предыдущей

лабораторной работе), либо создадим его способом, аналогичным как создается

К-связь (рис. 26, только вместо статуса "K" укажем статус "Q"), либо создадим

его способом, рассмотренным в первой работе.

В результате проведенной работы может быть получен объект

СЛУЖАЩИЙ, экранный образ которого представлен на рис. 28 (один из

вариантов формы можно увидеть в [17], пункт 4.3, рис. 2).

Рис. 28. Упрощенная форма для объекта СЛУЖАЩИЙ

Далее создадим форму для ILM, представленной на рис. 27 (а), для чего

добавим в таблицу SIIM (рис. 29) новую строку со следующей информацией:

TDOK = 000K, имя документа ОТДЕЛ.

Далее, используя кнопку "F5-Создать" (рис. 29), следует перейти в режим

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

работы N2, оформить экранный образ документа.

Пусть в качестве головного файла используется таблица с именем LADH.

В момент, когда в образ документа ОТДЕЛ потребуется вносить информацию об

его руководителе, в поле статуса необходимо указать символ "Q" , и система

предоставит список понятий, доступных системе (рис. 30).

Рис. 29. Состав таблицы SIIM после добавления информации о новом объекте

Действуя аналогично, как и при установлении К-связи, следует найти

(подключен поиск по индексу) или добавить новый документ, значения

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

в объекте-инициаторе связи [7].

Р

ис. 30. Режим визуального построения образа документа TDOK = 000K

Рис. 31. Режим визуального построения образа документа TDOK = 000K

На рис. 30 показана ситуация, когда проектировщик решил

воспользоваться информацией из документа TDOK = 007A (рис. 29) с головным

файлом LAAJ. Нажатие клавиши F2 приведет к появлению на экране окна,

содержащего атрибуты формы СЛУЖАЩИЙ (рис. 31).

Так как в качестве поля "прокрутки" (наследуемого поля) нас интересует

Фамилия служащего, в табл. 31 изменим значения в столбце "Порядок".

Напротив Фамилии установим 1, а напротив Табельного номера укажем 2.

После окончания визуальной модификации образа и выхода с

сохранением система сгенерирует все необходимые модели и уточнит пункт

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

Результат работы (после запуска модуля T.exe) можно увидеть на экране

(рис. 32). Раскрытие Q-связи для выбора из него значения производится

клавишей Enter или двойным щелчком мыши.

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

объекта Q-связи, проведенное нами выше, при построении образа документа.

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

мы тем самым свяжем два объекта, отображенных в системе (см. рис. 37).

Рассмотрим внешнею модель формы TDOK = 000K, приведенную на рис.

33. Логическая и внутренняя модели приведены на рис. 34 и 35 соответственно.

Рис. 32. Режим визуального построения экземпляра документа TDOK = 000K

Описание состава полей файлов фиксируется в справочнике SIORD и приведено

на рис. 36.

Система


Коор X


X поля

Поиск

Тип Длина

Точность

SI75 SI52 SI65 SI70 SI66 SI67 SI20 SI26 SI68 SI69 SI72 SI56 SI57 SI765700 UL00K001 Ся Отдела M 0 0 LADH LADH 0 0 0 C 1 0 5702 UL00K001 Название отдела G 8 30 LADH LADI 8 46 1 C 15 0 5704 UL00K001 Фамилия рук. Q 11 33 LADH LAAJ 11 46 2 C 2 0 5724 UL00K001 UL00K031 LAAJ LABI ZABI X 0 0 0 0 0 5730 UL00K001 Отдел Z 5 30 5740 UL00K031 Служащий Q M 0 0 LAAJ LAAJ 0 0 C 2 5741 UL00K031 Фамилия S 0 0 LAAJ LABI C 20 5742 UL00K031 Табельный номер S 0 0 LAAJ LABO N 4 5743 UL00K031 Имя S 0 0 LAAJ LABJ C 15 5744 UL00K031 Отчество S 0 0 LAAJ LABK C 20 5745 UL00K031 Дата приема на работу S 0 0 LAAJ LABP D 8 5746 UL00K031 Дата отсчета полного стажа S 0 0 LAAJ LABB D 8

Рис. 33. Таблица SIUEK, TDOK = 000K

Приведем некоторые пояснения к строке 5724 таблицы SIUEK (рис. 33). В

столбце SI65 указывается имя Q образа UL00K031 (U – служебный символ, L -

имя подсистемы, 00K - последние три цифры из типа документа, 031 - номер Q-

части), LLAJ - имя файла Q-классификатора, LABI - имя поля "прокрутки" из

образа Q-классификатора (т.е. имя поля, информация из которого будет

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

номера начиная с 31. Если в документе используется более одного Q-классификатора, то номера их частей будут соответственно 31, 32, 33 и т.д. Описание непосредственно самой Q-связи начинается со строки, содержащей поле СЯ файла с символом управления "M". Далее следуют строки с полями Q-классификатора, информацию из которых пользователь будет видеть в процессе выбора записей из Q. Эти строки должны иметь символ управления "S" и хотя бы в одной строке в поле SI72 ("Поиск") должна быть проставлена цифра "9".

Процесс добавления к существующему документу Q-классификатора

(помимо способа рассмотренного выше) может состоять из следующих шагов:

1. Описать и создать файл Q-классификатора в SIORD.

2. Модифицировать описание файла, в котором будет использоваться

классификационное поле в SIORD.

3. Модифицировать экранный образ документа в SIUEK.

4. При необходимости модифицировать описание документа в SIAGF.

5. Модифицировать системный файл SIAOF.


Этапы прохождения указанных шагов подробно рассмотрены в

лабораторной работе N 1, при встраивании в документ простого

классификатора, и поэтому здесь не приводятся. Только отметим, что система

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

создания новых документов. Например, если воспользоваться утилитой

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

текущей (в этом случае необходимо присвоить копируемому документу новый

системный номер). Режим "Копирование" вызывается также из области SIUEK

по нажатию клавиши "F5" (рис. 21).

N Часть На- чало

Ко- нец

Пере- ход

От- каз

Вер-шиСта-тус

Эк- ран

Спец 1 Спец 2 Название части

SIIM SC60 SI75 SC75 SC61 SC62 SC63 SI59 SC70 SC50 SC51 SI51 000K 1 5700 5730 98 99 0 S 1 Отдел 000K 31 5740 5746 0 0 0 Q 1 Руководитель отдела

Рис. 34. Таблица SIAGF, TDOK=000K

Рис. 35. Таблица SIA0F (а), TDOK = 000K и ILM документа (б)

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

документа, кроме части типа "E" (текстовая часть).

Отметим, что K и Q-связь очень похожи, но если K-связь может допускать

расширение списка своих значений внутри объекта, в котором она используется,

то для Q-связи это запрещено по определению. Кроме того, список значений для

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

его не удалит администратор. В Q-связи, если изменится значение поля

прокрутки, то объекты, использовавшие Q-связь на данном поле прокрутки,

будут оповещены по мере их актуализации (если не установлены специфические

правила перенаследования. Данный вопрос рассмотрен в [17]).

Файл Содержимое поля Поле файла Тип Длина Точн. Код

SI20 SI25 SI26 SI56 SI76 SI57 SI58 LADH СЯ Отдела lADH C 1 0 20 LADH Название отдела LADI C 15 0 1 LADH Ся руководителя LaAJ C 2 0 21 LADH Фамилия руководителя ZABI C 20 0 6 LADH Маршрут документа S00K C 4 0 6 LADH Кто рождает экземпляр SSSM C 4 0 6

0 LAAJ СЯ сотрудника. lAAJ C 2 0 20 LAAJ Табельный номер LABO N 4 0 1 LAAJ Фамилия. LABI C 20 0 1 LAAJ Имя. LABJ C 15 0 1 LAAJ Отчество. LABK C 20 1 LAAJ Дата приема на работу. LABP D 8 1 LAAJ Дата отсчета полного стажа. LABR D 8 1 LAAJ Маршрут док-та 007А. S07A C 6 6 LAAJ Страховой номер. LABM C 9 1 LAAJ Кто породил экземпляр. SSSM C 4 6 Рис. 36. Описание файлов документа TDOK = 000K в SIORD

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

системы создание индексного файла по данному полю.






5. Запустить программу T.exe и заполнить (создать) экземпляр документа.




(документов) в концептуальной модели СУБД.

2. Описание содержимого файлов SIIM, SIORD, SIUEK, SIAGF для

разрабатываемого документа, содержащего Q-классификатор.

D. 4.4. Работа 4. Построение формы, использующей Н-связь


Освоить использование Н-классификаторов в документах.


Модельный классификатор (H) - файл (группа файлов), содержащий

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

экране. Модельный классификатор должен быть самостоятельным документом,

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

Учитывая, что модельный классификатор всегда является самостоятельным

объектом данной предметной области, ему всегда приписываются правила

поведения по отношению к документу, в котором он используется.

Следует сразу подчеркнуть, что H-связь, в отличие от Q и K-связи в ILM,

всегда представляется в виде вершины графа, то есть является самостоятельной

частью формы. Более подробно на понятии части ее типах и видах остановимся

в следующей лабораторной работе.

Для освоения Н-классификатора (или, как говорят, H-связи) давайте

рассмотрим пример из лабораторной работы N 3, реализация которого в

концептах системы позволила получить отображение ILM в виде следующего

экранного образа (рис. 37).

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

возможным изменениям в предметной области.

Как видно из рис. 37, в объекте ОТДЕЛ зафиксировано два атрибута,

характеризующие понятие инфологического уровня. При этом первое свойство

Название отдела относится к “чисто” собственным свойствам объекта [7]

(атрибут имеет семантический код, равный 1), а второй атрибут Фамилия рук.

(значения которого вносятся (рис. 35 (б) и рис. 32) из другого объекта

СЛУЖАЩИЙ (рис. 28)) имеет семантический код, равный 21 (рис. 36).

Рис. 37. Закрепление за отделом руководителя с помощью Q-связи

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

режимах просмотра и редактирования более подробную информацию о

руководителе (как это было с Q-связью в момент выбора из объекта

СЛУЖАЩИЙ экземпляра в качестве руководителя отдела).

Решается эта проблема с помощью Н-связи, если упрощенную ILM

понятия ОТДЕЛ представить в виде следующего рис. 38.

Рис. 38. Закрепление за отделом руководителя с помощью H-связи

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

системы, необходимо войти в режим модификации документа TDOK = 000K

(рис. 29, кнопка "F9 – Модификация документа"), удалить поле Q-связи

Фамилия рук. (рис. 39). Для этого надо установить на него маркер курсора и

нажать клавишу "F8 – Удалить поле" (рис. 39).

Далее необходимо сохранить проведенную модификацию (клавиша "F2 –

Выйти и сохранить" (рис. 39)). На экране останется только атрибут Название

отдела и принадлежащее ему поле (рис. 40).

Рис. 39. Визуальный режим модификации документа TDOK = 000K


После проведенных операций необходимо добавить в структуру

документа новую часть (рис. 40, клавиша "F6 – Добавить часть"), которая

должна использовать в качестве своей базы документ TDOK = 007A с головным

файлом LAAJ (Служащий).

На рис. 41 приведен промежуточный этап формирования структуры

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


После замены статуса второй части ("V") на статус "H" и уточнения

названия части (в нашем случае новое название части "Руководитель отдела"), и

выхода с сохранением система предложит выбрать в качестве основы второй

части какое-то отображенное в системе понятие предметной области (см. рис. 8

в первой лабораторной работе).

Выбрав документ TDOK = 007A – СЛУЖАЩИЙ (головной файл LAAJ) из

предложенного списка документов (или в дальнейшем указав, что часть

базируется на файле LAAJ), получим следующий экран для его модификации

(рис. 42) (см. рис. 9 и примечание к нему).

Рис. 42. Формирование образа новой части на экране

При переходе на GET поле "Имя поля в файле" (рис. 42) система откроет

окно со списком полей файла LAAJ (документ "Служащий" TDOK = 007A),

выбор из строк которого (рис. 43) определит образ H-части в форме документа

TDOK = 000K.

Рис. 43. Формирование образа новой части на экране

Пусть, например, в образе H-части необходим вывод информации

следующих атрибутов (рис. 44) (выбор из окна на рис. 43 произведен либо F2,

либо с помощью мышки – зависит от версии системы).

Рис. 44. Образ модифицированного документа Отдел

Примечание. Модификация будет принята системой, если из режима вышли с сохранением (рис. 42, 43) и система создаст эталон документа. Следует отметить, что существовавшие до модификации экземпляры документа “Отдел” будут иметь форму, представленную на рис. 37.

Открытие H-классификатора для выбора из него значения осуществляется кнопкой "Открыть H-классификатор" или клавишей F7, если фокус находится на H-части.

После создания эталона для вновь добавленной H-связи надо, используя визуальные средства системы, установить правила его поведения и существования в объекте, в котором он используется.

После установления новых правил или изменения новых правил следует исполнить режим согласования статусов (запускается из открытого окна SIAOF, кнопка F8 – " Согласов. стат. (Согласование статусов)").

Часть типа "H" всегда должна быть самостоятельным документом. Единственным исключением является случай, когда часть типа "H", точнее, ее таблицы (файлы) порождаются в части другого документа, обладая в этом документе статусом ВНУТРЕННЕГО - КЛАССИФИКАЦИОННОГО файла (см. [17], пункт 2.1.1 и [7], приложение 1).

Основное назначение части типа "H" является обеспечение всевозможных связей (отношений) между различными документами системы на текущий момент времени. Так как "H" является самостоятельным понятием (документом) в системе, то изменения, происходящие с "H", по умолчанию наследуются другими документами.

Однако принцип умолчания может быть отменен или изменен с помощью специальных правил управления частями типа "H" (см. [7], пункт 2.2. Правила связей для H-частей.). Последнее становится крайне важным, когда документ, используемый в других документах в качестве "H", удаляется из системы (не путать процесс с архивацией), так как это может привести к каскадному удалению (или искажению) документов, использующих данный "H" в качестве своей части. Учитывая, что система позволяет использовать практически любой документ как часть другого документа, процесс удаления таких документов должен регламентироваться администратором модели с помощью названных выше правил.

Процесс добавления к существующему документу Н-классификатора чаще

всего состоит из следующих шагов:

1. Описать и создать файл H-классификатора в справочнике описания

таблиц (файлов) SIORD.

2. Модифицировать экранный образ документа, вставив или добавив Н-

часть.


4. Установить правила работы с Н-объектом в объекте, его использующем.

5. Вновь создать эталон документа.

Шаг 1.

В связи с тем, что мы будем использовать уже существующий файл LAAJ

(Служащий), описывать и создавать файл в SIORD не надо.

Шаг 2.

Данный шаг подробно рассмотрен выше, если Н-связь встраивается с

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

режимом, подобным встраивания K и Q-связям.

Шаг 3.

Данный шаг исполняется всегда и только для одного документа под

контролем системы. Если документ принят разработчиком для его дальнейшего

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

после этого исполнить режим создания общего справочника (вызов из окна

SIORD, кнопка "F6 – Общ. справ." (Общий справочник), рис. 18).

После создания эталона для документа, представленного на рис. 43,

системой будут модифицированы модели документа, показанные на рис. 45 – 47.

Рис. 45. Таблица SIA0F (а), TDOK = 000K и ILM документа (б)

Пояснения к заполнению SIUEK для документа с Н-классификатором (см.

рис. 46):

1. В экранный образ документа включается строка с символом управления

"Н" (в нашем документе это строка с адресом 5704).

2. Поле SI65 этой строки содержит служебную информацию: "Z UL00K002

010 ", где Z - служебный символ; UL00K002 - имя экранного образа модельного

классификатора; 010 - код работы с классификатором, три разряда которого

(после имени экрана модельного классификатора и пробела) имеют следующее

значение:

1-я позиция: 1 - элементы модельного классификатора можно редактировать,

0 - элементы модельного классификатора редактировать запрещено;

2-я позиция: 1 - записи классификатора разрешено прокручивать, 0 - записи классификатора запрещено прокручивать;

3-я позиция: 1 - в модельный классификатор разрешено добавлять записи; 0 - в модельный классификатор запрещено добавлять записи; 2 - в модельном классификаторе разрешено редактировать только

добавленные записи.

По умолчанию все значения этого кода принимаются равными нулю. Примечание. Фактически данным кодом задается правило структурно-функциональной

связи между документами "ОТДЕЛ" и "СЛУЖАЩИЙ".

Описание SIUEK будет следующим (рис. 46):

Система


Коор X


X поля

Поиск

Тип Длина

Точность

SI75 SI52 SI65 SI70 SI66 SI67 SI20 SI26 SI68 SI69 SI72 SI56 SI57 SI765700 UL00K001 Ся Отдела M 0 0 LADH LADH 0 0 0 C 1 0 5730 UL00K001 Отдел Z 5 30 5702 UL00K001 Название отдела G 8 30 LADH LADI 8 46 1 C 15 0 5704 UL00K001 Z UL00K002 000 H 0 0 LADH LAAJ 0 0 C 2 0 5710 UL00K002 *5704 M 0 0 LAAJ LAAJ 0 0 C 2 0 5712 UL00K002 1gr R 9 5 15 70 0 5721 UL00K002 Фамилия S 10 33 LAAJ LABI 10 41 99 C 20 0 5723 UL00K002 Имя S 11 42 LAAJ LABJ 11 46 99 C 15 0 5742 UL00K002 Табельный номер S 13 8 LAAJ LABO 13 25 99 N 4 0 5745 UL00K002 Дата приема на работу S 0 0 LAAJ LABP D 8 0

Рис. 46. Описание TDOK=000K в SIUEK

3. Описание экранного образа Н-части начинается со строки 5710 (рис.46),

содержащей поле собственного якоря Н-файла, причем в поле SI65

первоначально указывается ссылка (*5704) на адрес строки с символом

управления "Н". Звездочка ("*") перед адресом обозначает ссылку.

4. Далее следует строка с символом управления "R", который указывает

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

координатами, указанными в полях SI66 и SI67 (верхний левый угол) и SI68 и

SI69 (нижний правый угол). Примечание. Множество символов управления, используемых системой для

определения правил формирования значений элементов экранного образа, рекомендуется посмотреть в [17], приложение 1.

Описание SIAGF документа представлено на рис. 47: N Часть На-

чало Ко- нец

Пере- ход

От- каз

Вер-шиСта-тус

Эк- ран

Спец 1 Спец 2 Название части

SIIM SC60 SI75 SC75 SC61 SC62 SC63 SI59 SC70 SC50 SC51 SI51 000K 1 5700 5704 2 99 0 S 1 Отдел 000K 2 5710 5745 98 98 0 H 1 Руководитель отдела

Рис. 47. Таблица SIAGF, TDOK = 000K

Логика этого документа предельно проста. После ввода информации в

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

отказаться от 2-й части (во второй строке, в столбце SC62, стоит код 98, который

для данной модели разрешает отказ от части). Напомним, что код 98 означает

конец документа, а код 99 – запрет от отказа от части. Более подробную

информацию о системных файлах можно найти в [17], приложение 2 или в Help

системы.

Таким образом, Вы неявно познакомились с понятием динамической

структуры документа [7], которое трактуется как возможность для одного и того

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

Здесь же отметим, что если экземпляр документа СЛУЖАЩИЙ

(руководитель отдела) будет удален по каким-то причинам из базы, система

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

руководителем. При этом, если у объекта ОТДЕЛ, в свою очередь, определено

правило, требующее хранения его истории, то для данного объекта информация

о его руководителе не будет потеряна. Для других же объектов, не имеющих

подобного правила, информация об удаленном сотруднике будет недоступна.

Шаг 4.

На данном шаге необходимо установить правила работы с Н-объектом в

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

модификации документа TDOK = 000K, перейти на часть 2 и из пункта меню

Правила (рис. 48) выбрать необходимое правило (рис. 49).

Рис. 48. Вспомогательное меню для H-части

Рис. 49. Набор правил для Н-связи

Выбрав необходимое правило, система зафиксирует его код в таблице

SIUEK в строке 5074 (рис. 46).

Для рассматриваемой ситуации выбранное правило должно ограничить

(или нет) список служащих, которые могут занимать место руководителя отдела.

Практически в любой предметной области существуют свои нюансы,

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

д.), поэтому для простоты остановимся на правиле 3 (см. рис. 49).

Отметим, чтобы установить ограничение, что ни один служащий не может

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

помощью системной функции с именем FUNIQ [17]. Некоторые особенности

использования функции для определения реляционных ключей и уникальности

значений атрибутов рассмотрены в приложении 1.

Шаг 5.

Данный шаг следует исполнять, если установление правила проводилось

непосредственно в окне (таблице) SIUEK (рис. 46, строка 5704).






5. Запустить программу Т.exe и заполнить (создать) экземпляр документа.




(документов) в среде ORD.

2. Описание содержимого таблиц SIIM, SIORD, SIUEK, SIAGF для

разрабатываемого документа (содержащего Н-часть) и обоснование выбранного

правила для H-связи.

E. 4.5. Работа 5. Построение формы с изменяемой структурой


Познакомиться с основными принципами построения документа с

изменяемой структурой.


В общем случае в документе используется более одного файла, связь

между которыми задается внесенными якорями. Среди этих связей имеются

основные (обязательные), необходимые для работы системы, и

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

При представлении документа на экране дисплея, поля (или записи)

одного файла документа могут чередоваться с полями (записями) других файлов

этого же документа.

Поэтому возникает необходимость дополнительного описания,

связывающего экранное представление документа с его файловой структурой и

процессом заполнения (означивания) экземпляра документа. Такое описание в

системе называется экранным образом документа (ЭОД) или внешней моделью

(по терминологии стандарта ANSI/SPARC). ЭОД хранится в системной таблице

SIUEK, в которой указывается информация о расположении полей и атрибутов

на экране дисплея и правила означивания элементов этого описания в процессе

функционирования системы документов как единого целого.

ЭОД является носителем фреймовой модели документа и базируется на

понятии "статуса части" или просто "ЧАСТИ" документа.

Понятие части документа в системе связано не только с выводом на экран,

но и с возможностью управления формированием структуры экземпляра

документа в момент его создания или редактирования. Это понятие имеет

формальное толкование, соответствующее математическому определению

понятия отношения. В любой части может присутствовать атрибут времени и

атрибуты возможности существования части и ее элементарных компонент в

структуре экземпляра документа данного типа.

Таким образом, содержимое части и ее состав может изменяться со

временем, что будет соответствовать определенному событию в отражаемой

предметной области. Этим понятие "части" отличается от понятия отношения,

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

Каждая часть группирует какие-то свойства - характеристики документа

по их смыслу, назначению, принадлежности, симметричности, многозначности

и т.д., с учетом вышеназванных атрибутов времени и возможности

существования. Понятие "статус части" и является обобщением

вышесказанного.

Количество частей, их статусы и их взаимосвязь определяются природой

появления и функционирования данного типа объекта в предметной области и

его модели (документа) в системе и фиксируются в системной таблице с именем

SIAGF (логическая структура документа).

Следует отметить, что часть документа может, в общем случае, состоять

из множества полей, принадлежащих разным файлам, но для простоты в этой

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

противоречит излагаемому материалу.

В системе разрешены (рис. 50) следующие способы связей между частями

документа (см. [17], пункт 4.3).

Рис. 50. Допустимые способы связей между частями документа

Выше, на рис. 50, приведены связи между частями (файлами),

используемые в документах системы (одинарной линией обозначены

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

чертами обозначен атрибут части, являющийся собственным якорем файла

(части)).

Согласно рис. 50 (а) внешний файл может подключаться к основному

файлу любого типа (O, S, X, x). При этом СЯ основного файла обязательно

вносится во внешний файл. Перенос СЯ внешнего файла в файл, к которому он

подключен, не обязателен.

Согласно рис. 50 (б) внутренний файл может подключаться к основному,

внутреннему и классификационному файлам (типа Н). При этом обязательно во

внутренний файл вносится СЯ того файла, к которому он подключен. Перенос

СЯ внутреннего файла в файл, к которому он подключен, не обязателен.

Согласно рис. 50 (в) классификатор может подключаться к файлу любого

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

Внесение СЯ файла, к которому подключен классификатор, в этот

классификатор не обязателен.

Все обязательные связи система ORD устанавливает автоматически,

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

отслеживаются системой. Для указания статуса файлов в таблицах SIAOF,

SIUEK и SIAGF используется следующая кодировка:

"О" - основной файл документа (экземпляр данного типа документа по

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

стороны пользователя);

"S" - основной файл документа (экземпляр данного типа документа по

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

стороны пользователя);

"X" - основной файл системного документа, записи которого создаются

только системой в момент создания другого документа (подразумевают уже

наличие в системе документа (понятия) без которого создать данный документ

нельзя);

"x" – то же, что и "X", но подразумевают автоматическое удаление

документа, при удалении документа (понятия), его породившего;

"H" - модельный классификатор (h);

"B" - внешний файл. Файл F, принадлежащий документу и являющийся

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

документом, называется ВНЕШНИМ. Из этого следует, что внешний файл

может иметь только одну запись, относящуюся к экземпляру документа, и

содержит данные из документа другого типа. Наличие внешнего файла и

позволяет автоматически создавать другой документ в процессе заполнения

документа текущего;

"V" - внутренний файл. По своей природе подразумевает наличие

нескольких записей, относящихся к вышестоящей части. Как правило, V-часть

является многослойной;

"E" - текстовый (прицепной) файл.

Приведенная кодировка используется для описания информационно-

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

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

предметной области.

Виды частей документа.

Часть является элементом структуры экранного образа документа (см.

выше) и помимо статуса обладает типом (видом).

В системе имеется три основных вида частей документа:

- базовые части;

- части-продолжения;

- служебные (или фиктивные - "L") части.

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

которых информация выводится на экран, и/или в которые информация

вводится каким-либо способом. Части могут содержать множество атрибутов,

описывающих смысловую нагрузку этих полей.

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

информация, например о процедурах пользователя или триггерах системы,

которые необходимо выполнить в документе.

(Далее, для удобства изложения, вместо словосочетания "часть указывает

поле файла" иногда будет использоваться "часть содержит поле" или "в части

имеется поле".)

Базовым частям и их связям в документе однозначно соответствуют

статусы файлов документа (исключение составляют файлы статуса "B"), т.е. имя

статуса части наследуется из имени статуса первого файла части, при этом:

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

первый (главный) файл части F по своему статусу определяет статус самой

части. Все остальные файлы (если они есть) имеют статус "B";

- в каждой базовой части (и только в ней) имеется поле собственного якоря

файла F, и если базовая часть содержит файлы статуса "B", то в ней содержатся

собственные якоря файлов статуса "B", а каждый файл такого статуса содержит

внесенный якорь файла F;

- базовой частью может быть часть (только со статусом главного файла) из

множества {O, S, X, x, H, V, v, E};

- базовая часть статуса "E" всегда состоит только из одного файла.

Каждая базовая часть может иметь одну или несколько частей-

продолжений, исключение составляет только базовая часть статуса "E".

Введение частей-продолжений обычно вызвано требованиями визуального

удобства и логического порядка представления информации на экране или для

указания динамической структуры образа документа.

Части-продолжения всегда привязываются к своим базовым частям, т.е.

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

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

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

файлов, а также их внесенных якорей, кроме внесенных якорей K- и Q-

классификаторов.

Базовые части и части-продолжения также различаются в зависимости от

вида главного файла части:

- основная часть (продолжение основной части);

- V-часть (продолжение V-части);

- H-часть (продолжение H-части);

- E-часть (продолжения не имеет).

Если в части нет полей, в которые пользователь может ввести

информацию, то такая часть называется мнимой. Мнимая часть может вообще

не содержать ни одного выводимого на экран поля и состоять только из якорных

полей файлов.

Служебная (фиктивная) "L"-часть используется в роли операторной

скобки, образуя блок из нескольких предшествующих ей частей. Началом блока

обычно является ближайшая предшествующая мнимая часть. Допускается

вложение блоков друг в друга.

Все части экранного образа документа находятся в отношении

подчиненности: любая часть Pj экранного образа документа, кроме первой,

является подчиненной какой-либо другой части Рi. Причем часть Pi в этом

случае называется головной частью для части Pj. Отношение подчиненности

между частями определяется следующими правилами:

а) все части-продолжения являются подчиненными для своей базовой

части;

б) V- и E-части считаются подчиненными части, собственный якорь

которой вносится в эти части системой;

в) H-части считаются подчиненными той части, в которую системой

заносится собственный якорь головного файла H-части (см. [17], пункт 4.3);

г) L-части считаются подчиненными той части, которая открывает блок,

закрываемый L-частью.

Каждой части документа соответствует совокупность последовательных

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

Границы части определяются указанием начальной и конечной записей части в

системной таблице SIAGF (логика документа). В этой же таблице определяется

порядок следования частей.

Примеры построения экранных образов объектов и связей предметной

области приведены в [7, 17] и рассмотрены в предыдущих лабораторных

работах.

Рис. 51. ILM формы и фрагмент ее таблицы SIAGF

На рис. 51 (а) приведена модель (граф) абстрактного документа, состоящая из пяти частей.

Первая часть имеет статус "S", что предполагает (в момент создания

такого документа) обязательный запрос у пользователя системы разрешения

создать экземпляр подобного типа объекта.

Вторая часть имеет статус "V", что предполагает наличие у подобного

типа объекта многозначных свойств, независимых от многозначных свойств,

отображаемых в части 5. Вершиной для этой части является часть 1, но из-за

того, что на этой части "висят" другие части, в поле SC63 стоит величина 31. В

поле SC63 (вершина, кому подчинена часть), к номеру части, кому подчинена

данная часть, добавляется число 30.

Третья часть имеет статус "Н", что предполагает наличие в предметной

области документа (понятия), связываемого с данным документом и имеющего

самостоятельное значение в этой предметной области и свою модель.

Четвертая часть имеет статус "V" и является частью-продолжением части

2. Ее использование может быть вызвано требованиями удобства отображения

документа на экране дисплея или логикой самого понятия (например, не все

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

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

SIAGF документа (рис. 51, б). В поле SC63 (вершина, кому подчинена часть) к

номеру части, кому подчинена данная часть, добавляется число 50.

Часть пятая имеет статус "V", что предполагает наличие у подобного типа

объекта многозначных свойств, независимых от многозначных свойств,

отображаемых в части 2.

По существу, все части, присутствующие в документе, являются

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

документа. В какой-то момент времени экземпляр документа данного типа

может состоять лишь из подмножества этих частей. Поэтому различают

статическую и динамическую модели документа (см. описание далее). Каждая

часть, в свою очередь, может состоять из множества информационных полей и

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

очередь, любое информационное поле, помимо стандартных характеристик

таких, как тип, длина и т.п., может обладать рядом специальных характеристик,

которые иначе называются "статусом поля". Например, поле может быть

классификатором типа "K" или "Q", являться процедурным, служебным и т.д.

Необходимо подчеркнуть, что порядок следования (номера) частей

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

В общем случае, любой документ в системе является графом с

динамически изменяемой структурой. Каждая вершина графа является частью

документа. Каждая часть группирует какие-то свойства - характеристики

документа по их смыслу, назначению, принадлежности и т.д.

Понятие части документа в системе связано не только с выводом на экран,

но и с возможностью управления формированием структуры экземпляра

документа в момент его создания или редактирования. Содержимое части и ее

состав может изменяться со временем.

В свою очередь группа частей также может образовывать семантически

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

конструкция структуры формы рассмотрена в следующей лабораторной работе.

На рис. 51, б (логическая структура документа) показаны правила обхода

(заполнения) частей документа. После заполнения первой части (отказ от нее

запрещен, значение столбца SC62 равно 99) необходимо перейти к заполнению

части 2 и т.д. При заполнении части 5 возможен отказ от наличия этой части в

каком-либо экземпляре документа этого типа.

В качестве примера документа с изменяемой структурой рассмотрим

фрагмент документа "Приходный кассовый ордер" (TDOK = 0240, риc. 52 - 55).

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

прихода наличных денег от служащих данной организации или от стороннних

организаций (лиц). Именно учет разнородных объектов в одном типе документа

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

без привлечения программиста.

Рис. 52. Фрагмент формы для объекта ПРИХОДНЫЙ ОРДЕР

На рис. 52 показана форма документа TDOK = 0240, которая подходит для

ситуации, когда наличные деньги фиксируются от сотрудника организации,

работающего в ней. Однако, если это не сотрудник данной фирмы, то нажатие

клавиши "F9 – Удалить" (когда маркер курсора находится на части "Работник

завода") преобразует форму к виду, показанному на рис. 53.

Рис. 53. Фрагмент формы для объекта ПРИХОДНЫЙ ОРДЕР

Примечание. Документ TDOK = 0240 скопирован из информационной подсистемы "F" с помощью механизма, рассмотренного в лабораторной работе N2 (см. рис. 18), и упрощен с помощью визуальных средств системы. Поэтому все имена файлов в рассматриваемом документе уже известны.

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

ситуаций на основании модели ILM, представленной на рис. 54.

Рис. 54. Фрагмент ILM для формы для объекта ПРИХОДНЫЙ ОРДЕР

На рис. 54 для отображения ситуации использовано 4 объекта

инфологического уровня. Для каждого типа объекта указан его идентификатор в

системе и головной файл части. Отметим, что объекты TDOK = 0734, TDOK =

0102 и TDOK = 0210 закреплены за информационной подсистемой "F", а объект

TDOK = 0305 приписан к подсистеме "T".

Процесс обхода графа ILM и возможность существования его отдельных

вершин фиксируется в таблице SIAGF документа (рис. 55).

Рис. 55. ILM объекта ПРИХОДНЫЙ ОРДЕР в SIAGF документа

На рис. 55 приведен вариант обхода вершин ILM. Если пользователь

заполняет ПРИХОДНЫЙ ОРДЕР для сотрудника своего предприятия, то

информация о части 3 не видна на экране (рис. 52).

Если будет произведен отказ от части 2 (рис. 52), то пользователь будет

вводить информацию в форму, представленную на рис. 53.

Система


Коор X


X поля

Поиск

Тип Длина

Точность

SI75 SI52 SI65 SI70 SI66 SI67 SI20 SI26 SI68 SI69 SI72 SI56 SI57 SI766700 UF240001 Ся Приходного ордера M 0 0 FKP0 FKP0 0 0 0 C 3 0 6730 UF240001 Приходный кассовый ордер Z 2 13 0 6702 UF240001 N G 2 38 FKP0 FK01 2 41 1 C 6 0 6704 UF240001 FUNIQ U 0 0 0 0 0 C 2 0 6710 UF240001 От G 2 49 FKP0 FK02 2 52 0 D 8 0 6712 UF240001 ORDDIAPZ D 0 0 0 0 0 0 6721 UF240001 Дата прохождения по кассе G 4 40 FKP0 FK25 4 68 0 D 8 0 6723 UF240001 ORDDIAPZ D 0 0 0 0 0 0 0 6742 UF240001 Оплата по Q 6 3 FKP0 FFMA 6 13 0 C 4 0 6745 UF240001 UF240032 FFMA FKNN ZKNN X 0 0 0 0 0 0 0 6749 UF240001 Сумма за товар G 9 2 FKP0 FK21 10 2 4 N 13 2 6750 UF240001 Сумма за услуги P 9 18 FKP0 FK20 10 19 0 N 13 2 6752 UF240001 F240SUM X 0 0 0 0 6755 UF240001 Сумма НДС S 9 36 FKP0 FK22 10 35 0 N 13 2 6757 UF240001 Итоговая сумма S 9 50 FKP0 FK23 10 50 0 N 13 2 6760 UF240001 Z UF240002 010 Сотрудник H 0 0 FKP0 STRP 0 0 0 C 2 0 6762 UF240001 Z UF240002 111 Сторонние H 0 0 FKP0 FKR1 0 0 0 C 4 0 6770 UF24002 *6760 Сотрудник M 0 0 STRP STRP 0 0 0 C 2 0 6771 UF24002 4gr+ R 12 2 0 0 0 0 0 6772 UF24002 Место работы 1 K 0 0 STRP ST05 0 0 0 C 20 0 6775 UF24002 Работник завода G 13 3 STRP ST25 13 19 9 C 20 0 6777 UF24002 G 0 0 STRP ST26 13 40 9 C 15 0 6778 UF24002 G 0 0 STRP ST27 13 56 9 C 20 0 6780 UF24003 *6762 Организация M 0 0 FKR1 FKR1 0 0 0 C 4 0 6781 UF24003 4gr+ R 14 1 0 0 0 0 0 6783 UF24003 *6783 TDOK INV СИСТEМА F 0 0 FKR1 SSSM 3 C 4 0 6785 UF24003 Сторонний плательщик Z 15 5 0 0 0 0 0 6786 UF24003 От организации Q 15 26 FKR1 SFOR 15 41 0 C 3 0 6787 UF24003 UF2400031 SFOR sF08 ZF08 X 0 0 0 0 0 0 0 6789 UF24003 Фио плательщика G 17 3 FKR1 FK14 17 20 4 C 45 0 6790 UF24003 Документ 2 K 19 3 FKR1 FK15 19 13 9 C 20 0 6793 UF24003 Серия G 19 3 FKR1 FK16 19 41 9 C 45 0 6794 UF24003 N G 19 52 FKR1 FK17 19 54 9 C 10 0 6795 UF24003 Дата G 19 63 FKR1 FK18 19 68 9 D 8 0 6797 UF24003 Кем выдан G 21 3 FKR1 FK19 21 13 9 C 55 0 6800 UF24031 Организация M 0 0 SFOR SFOR 0 0 0 C 0 0 6802 UF24031 Название организации G 0 0 SFOR SF08 0 0 0 C 0 0 6803 UF24031 Город 2 K 0 0 SFOR SF03 0 0 0 C 0 0 6805 UF24032 Виды наличностей M 0 0 FFMA FFMA 0 0 0 C 2 0 6807 UF24032 S 0 0 FFMA FKNN 0 0 0 C 37 0

Рис. 56. Описание TDOK = 0240 в SIUEK

На рис. 56 приведено описание внешней модели в таблице SIUEK

документа TDOK = 0240.

Для объекта типа "H" (TDOK = 0305) установлено правило – "Разрешен

только выбор" (строка SIUEK с номером 6760), а для объекта TDOK = 0210

разрешены все действия (строка SIUEK 6762, рис. 56). Т.e. можно выбрать из

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

Или добавить новый экземпляр и установить с ним связь.

В описании внешней модели установлены следующие ограничения

целостности:

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

(строка 6704 (рис. 56) содержит вызов системной функции FUNIQ – ее

назначение и описание приведено в приложении 1);

значение дат для GET полей с атрибутами от (строка 6710) и Дата

прохождения по кассе (строка 6721) проставляется автоматически, если

пользователь не вводит значение в указанные поля. В строке 6723 (рис. 56)

использована системная функция ORDDIAPZ (исходный текст находится в

папке <диск:\SUBS\PRG_WIN\WINP\orddiapz.prg>), ограничивающая область

допустимых значений в поле с именем FK25.

Для расчета значений полей Сумма за услуги, Сумма НДС и Итоговая

сумма (строки 6750, 6755, 6757 соответственно) использована пользовательская

функция типа "P" (строка 6752) с именем F240SUM, исходный текст которой

находится в программном модуле L0240.prg по адресу

<диск:\SUBS\PRG_WIN\WINP\L0240.prg>



2. Разработать модель документа, в котором необходимо динамически

изменять структуру формы.

3. Загрузить утилиту Db.exe.

4. Используя визуальные средства системы, отобразить разработанный

документ в управляющих файлах системы.


6. Запустить программу ORD.exe и заполнить (создать) экземпляр


IV. СОДЕРЖАНИЕ ОТЧЕТА


(документов) в целевой СУБД.

2. Исходные формы разрабатываемых документов и их модели в виде

графа взаимосвязи частей и их файлов.

3. Описание содержимого таблиц SIIM, SIORD, SIUEK, SIAGF документа.

4. Формы экранных образов построенных документов.

F. 4.6. Работа 6. Построение формы, содержащей блок "V-H-V"


Познакомиться с основными принципами построения документов,

которые в своей структуре содержат блок.


В данной лабораторной работе необходимо построить документ,

содержащий блок со статусами частей "V-H-V". Основные положения,

связанные с возможными структурами форм и взаимосвязей частей, их

составляющих, рассмотрены в предыдущих работах и в [7, 17].

В качестве примера реализуем модель, представленную на рис. 4 (г), с

учетом, что нам уже известны имена некоторых объектов на физическом уровне

отображения (рис. 57).

Рис. 57. Фрагмент ILM для объекта ОТДЕЛ

Заметим, что, на представленной ILM (рис. 57) отсутствует часть (см. рис.

44) с именем Руководитель отдела, а ее наличие заменено Q-связью. Это

вызвано, прежде всего, тем, что руководитель отдела – это тоже сотрудник

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

было бы оставить и Н-связь).

Введение части продолжения в модель документа в данном случае

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

логичнее сначала указать Служащего отдела, а затем указать его должность.

В то же время, использование части продолжения позволяет реализовать

простейшую конструкцию блоковой структуры изображаемой ситуации (все,

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

определению входит в блок).

Процесс создания документа с блоковой структурой состоит из

следующих шагов:

1. Добавить запись в таблицу SIIM и заполнить ее.

2. Описать структуру файлов документа в SIORD и создать данные файлы

(клавиша "F2", находясь в окне SIORD (рис. 15 или 18)).

3. Описать экранный образ документа в таблицах SIUEK, SIAGF, SIAOF.


Мы не будем описывать приведенные шаги (они рассмотрены в

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

TDOK=000K – "ОТДЕЛ" и заставим систему автоматически отобразить ILM в

форму вида (рис. 58):

Рис. 58. Экранный образ модели для ILM рис. 51

Для этого приведем форму, показанную на рис. 44, к виду, изображенному

на рис. 40 (из формы рис. 44 удалена Н-часть о руководителе отдела). Далее

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

на рис. 37 (экранный образ рис. 39). Добавим, используя кнопку "F6 - Добавить"

(рис. 59), многослойную часть (тип "V" - Сотрудники) и укажем ее атрибуты

(рис. 59). В нашем случае собственным свойством 2-й части является атрибут

Дата приема.

Рис. 59. Промежуточный этап формирования формы рис. 52

Аналогично (используя кнопку F6, рис. 59) добавим Н-часть и часть-

продолжение для части 2 (результат модификации показан на рис. 60).

Рис. 60. Промежуточный этап формирования модели рис. 58

Обратите внимание, что на экранном образе формы рамка базовой части 2

для части продолжения 4 (ее атрибут Должность) охватывает и третью и

четвертую части, тем самым как бы фиксирует части, вошедшие в блок ("V-H-

V"). Если процесс модификации будет завершен по клавише "F2 – Выйти и

сохранить", то система автоматически модифицирует описание документа в

таблицах SIUEK, SIAGF и SIAOF.

Пояснения по полям SIUEK (рис. 61) были даны в лабораторной работе

№1. Здесь остановимся только на тех элементах экранного образа, которые

встречаются впервые.

Итак, наш документ содержит блок "V-H-V". Описание V-части в

структуре имеет имя экранного образа части "UL00K002". Часть начинается (как

обычно) с описания собственного якоря файла (строка 5710, рис. 61).

Второй строкой в описании части 2 идет строка с символом управления

"N". Символ управления "N" обозначает, что в данной строке содержится поле с

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

поле SI65 данной строки указывается адрес переноса собственного якоря

головного файла. В нашем случае головной для 2-й части является 1-я часть

документа. Строка с Ся файла 1-й части имеет адрес "5700" (рис. 61),

следовательно, этот адрес с предшествующим символом "*" должен быть указан

в строке с символом управления "N" (см. рис. 61, строка 5712, столбец SI65).

Система


Коор X


X поля

Поиск

Тип Длина

Точность

SI75 SI52 SI65 SI70 SI66 SI67 SI20 SI26 SI68 SI69 SI72 SI56 SI57 SI765700 UL00K001 Ся Отдела M 0 0 LADH LADH 0 0 0 C 1 0 5701 UL00K001 Отдел Z 5 30 5702 UL00K001 Название отдела G 8 30 LADH LADI 8 46 1 C 15 0 5704 UL00K001 Фамилия рук. Q 9 33 LADH LAAJ 9 46 2 C 2 0 5707 UL00K001 UL00K031 LAAJ LABI ZABI X 0 0 0 0 0 5710 UL00K002 Ся сотрудника M 0 0 LACC LACC 0 0 0 C 2 5712 UL00K002 *5700 Вся ОТДЕЛА N 0 0 LACC LADH 0 0 0 C 1 5714 UL00K002 1gr+ R 10 3 25 78 5720 UL00K002 Сотрудник Z 10 5 5721 UL00K002 Дата приема G 12 23 LACC LADJ 12 33 D 8 5728 UL00K002 Z UL00K003 010 H 0 0 LACC LAAJ 0 0 C 2 0 5730 UL00K003 *5728 M 0 0 LAAJ LAAJ 0 0 C 2 5731 UL00K003 1gr R 9 5 15 70 5732 UL00K003 Фамилия S 10 33 LAAJ LABI 10 41 0 C 20 5733 UL00K003 Имя S 11 42 LAAJ LABJ 11 46 0 C 15 5737 UL00K003 Отчество S 12 45 LAAJ LABK 12 56 0 C 20 5742 UL00K003 Табельный номер S 13 8 LAAJ LABO 13 25 0 N 4 5747 UL00K002 Продолжение второй LACC 0 5748 UL00K002 Должность Q 17 10 LACC LAFF 17 20 0 C 1 5749 UL00K002 UL00K032 LAAF ZJAJ ZJAJ X 0 0 0 0 0 5750 UL00K031 Служащий Q M 0 0 LAAJ LAAJ 0 0 0 C 2 5751 UL00K031 Фамилия S 0 0 LAAJ LABI 0 0 0 C 20 5752 UL00K031 Табельный номер S 0 0 LAAJ LABO 0 0 0 N 4 5753 UL00K031 Имя S 0 0 LAAJ LABJ 0 0 0 C 15 5754 UL00K031 Отчество S 0 0 LAAJ LABK 0 0 0 C 20 5765 UL00K031 Дата приема на работу S 0 0 LAAJ LABP 0 0 0 D 8 5770 UL00K032 Тарифные ставки M 0 0 LAFF LAFF 0 0 0 C 2 5775 UL00K032 Должность K 0 0 LAFF LJAJ 0 0 0 C 1 5777 UL00K032 Номер ставки S 0 0 LAFF LAAG 0 0 0 C 5

Рис. 61. Состав SIUEK TDOK = 000K – ОТДЕЛ

Далее следует строка (5714, рис. 61), определяющая координаты рамки. В

системе все V-части должны иметь рамку, причем в данном случае в одной

общей рамке должен быть весь блок "V-H-V". Координаты рамки используются

для отображения V-части или блока в виде таблицы. Если маркер курсора будет

находиться на каком-либо поле V-части, то нажатие Shift\F1, или, используя

меню части (двойной клик правой кнопкой мышки приведет к появлению на

экране меню рис. 58).

Следующей идет строка (5720, рис. 61) с заголовком части и строка с GET

полем, куда вводится значение даты приема служащего в отдел. Замыкает

описание 2-й части в SIUEK строка с символом управления "H" (см. работу №4).

После Н-части в документ должны быть включены данные о

характеристиках сотрудника, которые являются свойствами связи (см. [7]). К

таким характеристикам могут быть отнесены, например, Должность, Дата

увольнения и т.д. Поэтому в структуру документа включена V-часть,

являющаяся частью-продолжением 2-й части.

Имя экранного образа части-продолжения (строка 5747) совпадает с

именем головной части (часть-продолжение V-части в структуре документа

является 4-й частью).

И завершается описание структуры документа описанием состава образов

Q-классификаторов (строки 5750 и 5770, рис. 61), использованных в документе

TDOK = 000K.

Описание таблицы SIAGF будет следующим (рис. 62).

Рис. 62. Описание структуры документа "000K" в SIAGF

Пояснений к структурам SIAGF (рис. 62) и SIAOF (рис. 63), по-видимому,

не требуется.

Рис. 63. Описание файлов документа TDOK = 000K в SIAOF

Шаг 4.

Создание эталона документа осуществляется при нажатии клавиши "F7"

из области таблицы SIORD, если изменяется физическая структура какого-либо

документа системы.



2. На примерах моделей документов, представленных в данном

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

SIORD, SIIM, SIUEK, SIAGF.

3. Построить модель заданного документа, содержащего блок "V-H-V".

4. Загрузить утилиту Db.exe. Формат команды для загрузки утилиты:

Db.exe <имя подсистемы>

5. Используя визуальные средства системы, отобразить разработанный

Вами документ в управляющих файлах системы.


7. Если при создании эталона обнаружены ошибки, то исправить их и

перейти к пункту 6.

8. Выполнить режим согласования статусов в разработанных моделях.

9. Запустить программу ORD.exe и заполнить (создать) экземпляр


IV. СОДЕРЖАНИЕ ОТЧЕТА


(документов) в целевой СУБД.

2. Исходные формы разрабатываемых документов и их модели в виде

графа взаимосвязи частей и их файлов.

3. Описание содержимого таблиц SIIM, SIORD, SIUEK, SIAGF документа.

4. Формы экранных образов построенных документов.

VI. Приложение 1

А. Ограничения целостности, поддерживаемые функцией

FUNIQ

Использование функции FUNIQ (проверка уникальности введенного

значения) определяется семантикой предметной области. Функция FUNIQ

контролирует значения, вводимые в поле (или группы полей) на уникальность

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

Пусть, например, в предметной области выделены объекты ПОСТАВЩИК

и ТОВАР, а также связь ПОСТАВКА. Атрибуты, раскрывающие суть этих

понятий в данной предметной области, следующие (рис. А.1):

Поставщик (N поставщика, Характеристики поставщика); Товар (N товара, Характеристики товара); Поставка (N поставщика, N товара, N счета фактуры)

Рис. А.1. Пример фрагмента предметной области

Пусть, например, разработчики приняли решение, что атрибуты "N

поставщика" и "N товара" должны уникально характеризовать объекты

ПОСТАВЩИК и ТОВАР соответственно. Тогда этот факт должен быть

отображен в схеме модели. Например, для "Товара":

Система


Коор X


X поля

Поиск

Тип Длина

Точность

SI75 SI52 SI65 SI70 SI66 SI67 SI20 SI26 SI68 SI69 SI72 SI56 SI57 SI767000 … … 0 0 0 0 0 0 908F1

UL00X001 N товара G 5 30 SFBN Sf11 5 39 1 C 12 0 9085 UL00X001 FUNIQ U 0 0 0 0 0 0 0

Рис. А.2. Фрагмент SIUEK объекта ТОВАР

Для "Поставщика": 902F UL00X001 N поставщика G 4 30 SFAp Sf22 4 39 0 C 12 0 9025 UL00X001 FUNIQ U 0 0 0 0 0 0 0

Рис. А.3. Фрагмент SIUEK объекта ПОСТАВЩИК

Пусть, например, для связи ПОСТАВКА устанавливается ограничение –

Поставщик должен поставлять "Товар" под определенную счет фактуру

(заметим, что "N счета фактуры" у различных поставщиков могут совпадать).

Тогда данное правило должно быть указано в схеме модели (рис. А.4). Его

наличие будет гарантировать, что в системе не может появиться "Товар" с

одинаковым "N счета фактуры".

Рис. А.4. Фрагмент таблицы SIUEK объекта ПОСТАВКА

Отметим, что описание функции FUNIQ, в таблице SIUEK, находится

после последнего поля, входящего в реляционный ключ.

В режимах работы, связанных с созданием и редактированием документа,

система будет отслеживать уникальность по указанным атрибутам. Данное

замечание останется справедливым как для одномашинного комплекса, так и

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

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

времени.

Последнее поле в реляционном ключе (за которым стоит FUNIQ), должно

иметь индекс (для нашего примера это поле SNUM файла SFAP).

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

имеет более уникальный характер.

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

FUNIQ*K <имя поля, адрес> ... <имя поля, адрес>,

где K - число полей в реляционном ключе.

Заметим, что реляционные ключи должны группироваться в той части

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

Обратим внимание, что использование функции FUNIQ на рис. А.2

(фрагмент SIUEK объекта "ТОВАР") и на рис. А.5 имеет различную смысловую

направленность.

Система


Коор X


X поля

Поиск

Тип Длина

Точность

SI75 SI52 SI65 SI70 SI66 SI67 SI20 SI26 SI68 SI69 SI72 SI56 SI57 SI767000 … … 0 0 0 0 0 0 908F1

UL00X001 N товара G 5 30 SFBN Sf11 5 39 1 C 12 0 9085 UL00X001 FUNIQ*1 SF11908F U 0 0 0 0 0 0 0

Рис. А.5. Фрагмент SIUEK объекта "ТОВАР"

Для случая, отображенного на рис. А.2, использование FUNIQ

подразумевает наличие объекта "O", в котором используется ТОВАР, но на

момент создания объекта "O" товар может быть неизвестен.

Для случая, который приведен на рис. А.5, использование FUNIQ

подразумевает наличие объекта "O", в котором также используется ТОВАР, но

на момент создания объекта "O" - товар должен быть известен. Т.е. в случае,

показанном на рис. А.5, N товара является "чистым" реляционным ключом, что

запрещает появления в его значениях неопределенных значений.

Рассмотрим фрагмент документа TDOK = 0102 - "Организация" и еще раз

поясним использование функции FUNIQ и применение реляционных ключей.

Структура фрагмента ILM документа TDOK = 0102 - "Организация" имеет

следующий вид (рис.A.6).

Рис. А.6. Графовая структура документа TDOK = 0102 - Организация

Как видно из рис. А.6, понятие "Организация" имеет ряд однозначных

характеристик, которые фиксируются в 1-й части документа (в файле SFOR). И

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

SFBC), которые в свою очередь могут иметь смысл, если организация открывает

в некотором "Банке" (часть 3 -"Банк") свой расчетный счет.

Заметим, статус части 2 - "v" (файл SFBC) указывает системе, что в

системе существует понятие, которое будет использовать документ TDOK =

0102, и что в качестве связующего элемента из TDOK = 0102 будет

использоваться его внутреннее свойство, определенное на файле SFBC.

Фактически рис. А.6 показывает, что объект ОРГАНИЗАЦИЯ вступает в

связь с объектом БАНК (см. документ TDOK = 0110 - подсистема "F") и в

качестве атрибута связи используется атрибут N счета в банке. При этом

свойство банка N счета в банке становится внутренним свойством понятия

"Организация".

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

"Организация" (полный список атрибутов данного документа можно найти в

подсистеме "F") и "Банк", необходимые для определения реляционных ключей

документа TDOK = 0102.

С обыденной точки зрения понятие "Банк" является частным случаем

понятия "Организация", так как понятие "Банк" может иметь графовую

структуру, представленную рис. А.6. Однако для удобства будем считать, что

это различные объекты.

Для любой организации присущи, например, следующие характеристики:

- название организации (sfor->sf08 – подобная запись обозначает значение поля

sf08 из файла sfor);

- местоположение организации;

- Фамилия руководителя;

- ИНН организации (индивидуальный номер налогоплательщика) (sfor->sf01);

- номер лицензии и т.п., и т.д.

Принципиально важно, что среди этих характеристик всегда найдется

атрибут (или группа атрибутов), по значению которого мы в состоянии

однозначно отличить один экземпляр объекта этого типа от другого. Если же

такой атрибут (или группа атрибутов) на данный момент установить трудно, то

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

свойством в данной предметной области.

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

и пространственных параметров исследуемой предметной области.

Нетрудно заметить, что для понятия "Организация" таким атрибутом

будет: - ИНН организации (SFOR->SF01), а для понятия "Банк" атрибут: - БИК

банк' (SFBN->SF19). Заметим, что банк как организация, имеет свой уникальный

"ИНН".

Природа значений этих атрибутов такова, что не может существовать двух

организаций с одинаковым ИНН организации, хотя бы в пределах данного

государства. И государство в меру своих возможностей должно поддерживать

данное правило.

Таким образом, у понятия "Организация" внешний реляционный ключ

"ИНН организации", а у понятия "Банк" атрибут - "БИК банка".

Документ TDOK = 0102 - "Организация", помимо указанных ключей,

имеет еще один реляционный ключ, определяющий внешнее правило, которое

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

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

клиенту предоставляет уникальный номер счета. Т.е. если клиент имеет в одном

и том же банке несколько счетов, то номера этих счетов должны быть различны

и никакой другой клиент не может получить в свое использование номер счета,

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

Последнее правило отобразиться в SIUEK документа TDOK =0102

следующим образом (рис. A.7, строка 90)D).

Рис. А.7. Фрагмент внешней модели док-та TDOK = 0102 - "Организация" Примечание. На рис. А.7, в строке с номером 90)8, использован символ управления “F” и служебное слово “INV”. Подобная конструкция используется в том случае, когда необходимо осуществить перенос из одной ячейки внешней модели в другую. Подробно всевозможные правила переноса рассмотрены в [17].

Рис. А.7 показывает использование функции FUNIQ для поддержания

целостности реляционного ключа "ИНН организации" и гарантирует, что ни

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

счетов в одном и том же банке.

Заметим, что строка 90)8 использует в качестве связующего элемента

правило переноса по "F", что в свою очередь обеспечивает независимость

понятия "Организация" от понятия "Банк" (см. [17], приложение 1).

Строка 9085 содержит вызов функции FUNIQ с указанием состава

реляционного ключа и адресов расположения этих ключей.

В заключение параграфа отметим, что внешняя модель (SIUEK)

преобразуется автоматически системой в массив SARY (см. пункт 4.5, [17]) и

имеет вид, показанный на рис. А.8.

Логически в массиве SARY появляются строки 12 и 14 (символы

управления "T" и "t" соответственно), предназначенные для хранения

первоначального значения реляционного ключа.

10-я размерность массива SARY (не показанная на рис. A.8), каждой

первой строки части, является указателем на массив части [17]. Размерность и

расположение столбцов в массиве части определяется элементами строк SARY

для каждой части. Реально SARY дублируется в SIIUEK и является ресурсом

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

что обеспечивает системе устойчивость и безопасность функционирования.

Рис. А.8. Фрагмент массива SARY для документа TDOK = 0102

Если реляционный ключ состоит из трех информационных полей, то

данный факт отображается в SIUEK следующим образом (рис. А.9).

Рис. А.9. Пример реляционного ключа состоящего из 3-х информационных полей

Функция FUNIQ также может использоваться и для проверки

уникальности введенного значения и внутри части. В этом случае после имени

функции FUNIQ должен стоять символ "T" (рис. А.10).

Система


Коор X


X поля

Поиск

Тип Длина

Точность

SI75 SI52 SI65 SI70 SI66 SI67 SI20 SI26 SI68 SI69 SI72 SI56 SI57 SI767000 … … 0 0 0 0 0 0 908F UL00X002 N товара G 5 30 SFBN Sf11 5 39 1 C 12 0 9085 UL00X002 FUNIQ*T U 0 0 0 0 0 0 0

Рис. А.10. Пример реляционного ключа локального в части

VII. Приложение 2

Б. Особенности работы с "v" частью

Цель данного приложения - раскрыть назначение частей документа

статуса "v".

Пусть имеется некоторая предметная область, учитывающая выполняемые

работы по какому-то объекту. Пусть таким объектом будет жилищный фонд

некоторых городов.

Для данной предметной области выделены сущности "Дом", "Квартира" и

"Журнал учета ремонта", предназначенный для учета ремонта, как самого дома,

так и квартир, находящихся в этом доме.

Например, "Журнал учета ремонта" может иметь вид (рис. Б.1): Город Пункт

Улица N дома Дата Вид ремонта Объект N дома или квартиры

Киев Белая 10а 01.02.04 Капитальный Дом - Киев Белая 11 01.02.04 Капитальный Дом - Киев Белая 10а 01.03.04 Сантехника Квартира 18 Псков Белая 10а 01.03.04 Сантехника Квартира 18

Рис. Б.1. Фрагмент "Журнала учета ремонта"

Например, по понятию "Дом" необходимо зафиксировать следующую

информацию (рис Б.2,a), а по понятию "Квартира дома" необходима

информация, указанная на рис. Б.2,б.

Рис. Б.2. Фрагмент списка домов и их квартир

В концептах ILM данная ситуация может быть отображена следующей

группой моделей (рис. Б.3).

Рис. Б.3. ILM документов

Поясним приведенные модели.

Документ TDOK = 001A - "Дом" представлен двумя частями со статусами

"S" и "v" соответственно.

1-я часть постоянные характеристики понятия "Дом" определены на

таблице с именем LDOM.

2-я часть содержит информацию о проводимых ремонтах дома и

определена на таблице (файле) с именем LGYR.

Документ TDOK = 001В - "Квартира" представить четырьмя частями со

статусами "S","H","V","v".

1-я часть (LKBA) – содержит постоянные характеристики понятия

"Квартира".

2-я часть (LDOM) статуса "H" наследует некоторые характеристики в

понятие "Квартира" из понятия "Дом".

3-я часть (LPOM) статуса "V" содержит информацию по помещениям

квартиры.

4-я часть (LGYR) предназначена для учета ремонта квартиры. Ее статус

определен через статус "v", который указывает, что в системе будет

существовать документ, использующий эту часть как свою собственную часть (в

системе статус "v" подразумевает использование данной части в другом понятии

как части типа ВНУТРЕННЕЙ КЛАССИФИКАЦИОННОЙ или ВНУТРЕННЕЙ

СОГЛАСОВАННОЙ [17]).

Документ TDOK=001С - "Журнал учета ремонта" представлен двумя

частями со статусами "X" и "H".

Указав для первой части документа TDOK = 001С статус "X", мы тем

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

автоматически в момент рождения какого-то другого документа (документов).

Экранные образы документов могут быть следующие:

Рис. Б.4. Экранные образы документов

Особенность данной ситуации в том, что фактически документ Tdok =

001C –"Журнал учета ремонта" является виртуальным, так как его информация

наследуется из других документов.

Отсюда становится понятно, почему статус части 2 (документа Tdok =

001A) и статус части 4 (документа Tdok = 001B) определяется через "v". A

статус части 3 Tdok = 001B определен как "V" (как собственное многозначное

свойство).

Далее на рис. Б.5 приведены внешние модели документов (файлы SIUEK и

SIAGF), в которых указаны необходимые правила для отслеживания

правильного функционирования данной ситуации.

Рис. Б.5. Состав SIUEK для моделей документов, представленных на рис. Б.4

В данном описании внешней модели зафиксированы следующие правила

поведения объектов.

1. В любом доме может производиться любое количество ремонтов.

Если ремонт будет произведен, то в объекте TDOK = 001С (Журнал

ремонтов) автоматически будет внесена запись о ремонте. При этом отработают

три правила перенаследования (см. [17], пункт A.6, приложение 1), указанные в

строках 0012, 0013, 0015 (рис. Б.6).

0012 UL01A002 *0012 TDOK INV F 0 0 LGYR SSSM 0 0 0 C 4

0013 UL01A002 *0008 LY___ INV F 0 0 LGYR LY__ 0 0 0 C 10

0015 UL01A002 *0015 MDOK INV S01C 2 F 0 0 LGYR S01C 0 0 0 C 4

Рис. Б.6. Фрагмент описания экранного образа

Правило константного переноса в строке 0012 (рис. Б.6) заставит систему

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

= 001A.

Служебное слово INV указывает системе, что информация вносится в

данную часть из другой части документа. Заметьте, что имя поля SSSM (кто

рождает данный экземпляр документа) по определению принадлежит системе и

зарезервировано системой именно для этих целей.

Правило информационного переноса (строка 0013) зафиксирует Номер

дома, в котором был произведен ремонт. Заметьте, что имена полей

указывающих "откуда" и "куда" переносится информация, могут не совпадать,

но тип этих полей должен совпадать.

Правило маршрутного переноса (строка 0015), учитывая, что статус

данной части "v" зафиксирует структуру маршрута документа типа TDOK =

001С (Журнал ремонтов), состоящего из двух частей в поле маршрута S01C

этого документа, если это режим создания.

Служебное слово MDOK указывает системе, что при появлении нового

экземпляра объекта с системным номером TDOK = 001C система должна

прописать маршрут документа TDOK = 001C, состоящего из 2-х частей (по

одному слою для каждой части).

Правило временного согласования (строка 000b, рис. Б.5) заставит систему

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

2. В любой квартире может производиться любое количество ремонтов.

Если ремонт будет произведен, то в объекте TDOK = 001С (Журнал

ремонтов) автоматически будет произведена запись о ремонте. При этом

отработают четыре правила перенаследования, указанные в строках 0042, 0043,

0045, 0047 (рис. Б.7).

0042 UL01B003 *0042 TDOK INV F 0 0 LGYR SSSM 0 0 0 C 4

0043 UL01B003 *0023 LEVO INV F 0 0 LGYR LN__ 0 0 0 C 10

0045 UL01B003 *0045 MDOK INV S01C 2 F 0 0 LGYR S01C 0 0 0 C 4

0047 UL01B003 *0025 LDOM INV F 0 0 LGYR LDOM 0 0 0 C 3

Рис. Б.7. Фрагмент описания экранного образа

Правило константного переноса в строке 0042 (рис. Б.7) заставит систему

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

= 001B.

Правило информационного переноса (строка 0043) зафиксирует Номер

квартиры, в которой был произведен ремонт.

Правило информационного переноса (строка 0047) зафиксирует адрес

квартиры, в которой был произведен ремонт.

Правило маршрутного переноса (строка 0045) учитывая, что статус данной

части "v" зафиксирует структуру маршрута документа типа TDOK = 001C

(Журнал ремонтов), состоящего из двух частей в поле маршрута S00C этого

документа, если это режим создания.

Строка 0025 (рис. Б.5) указывает правило, разрешающее только связывать

понятие КВАРТИРА c ее АДРЕСОМ, без права редактирования объекта АДРЕС

в этом документе.

3. Для документа TDOK = 001С статус головной части "X" указывает, что

документ автоматически создается или редактируется при обработке других

документов ,и если какой-либо из порождающих документов имеет статус "v"

система открывает его только для редактирования.

Причем именно наличие статуса головной части "X" в совокупности с

присутствием наличия частей 'v', его порождающих, является определяющим

для системы, что такая часть относится к категории ВНУТРЕННЕЙ -

СОГЛАСОВАННОЙ ("v") части.

СОДЕРЖАНИЕ ПРЕДИСЛОВИЕ ................................................................................................... 3 1. СОДЕРЖАНИЕ ДИСЦИПЛИНЫ............................................................ 3 1.1. Содержание дисциплины по ГОС ................................................................... 3 1.2. РАБОЧАЯ ПРОГРАММА (объем 154 часа) ................................................. 4 Введение (4 часа)........................................................................................................ 4

1.2.1. Среда базы данных (14 часов)................................................................ 4 1.2.2. Методы организации данных на внешних запоминающих устройствах (12 часов) ....................................................................................... 5 1.2.3. Основы построения банков данных (10 часов) .................................. 6 1.2.4. Теоретические основы реляционной модели данных (10 часов).... 6 1.2.5. Языки баз данных (20 часов) ................................................................. 7 1.2.6. Объектно-реляционный подход к проектированию баз данных (16 часов)..................................................................................................................... 7 1.2.7. Концепции распределенных СУБД (8 часов) ..................................... 8 1.2.8. Промышленные системы управления базами данных (7 часов) ... 8

Заключение (1 час) .................................................................................................... 9 1.3. Тематический план лекций для студентов очно-заочной формы обучения .................................................................................................... 9 1.4. Тема практического занятия................................................................. 10 1.5. Темы лабораторных работ ..................................................................... 10 1.6. Тематика курсового проекта................................................................. 10 2. Библиографический список ...................................................................... 10 3. Задания на контрольные работы и методические указания к их выполнению .......................................................................................................... 12 3.1. Контрольная работа № 1 ................................................................................ 12 3.2. Контрольная работа № 2 ................................................................................ 21 4. Методические указания к выполнению лабораторных работ .. 22 4.1. Работа 1. Ознакомление с особенностями интегрированной среды СУБД..................................................................................................................................... 25 4.2. Работа 2. Построение формы, содержащей К-связь .................................. 36 4.3. Работа 3. Построение формы, содержащей Q-связь.................................. 48 4.4. Работа 4. Построение формы, использующей Н-связь ............................. 55 4.5. Работа 5. Построение формы с изменяемой структурой .......................... 66 4.6. Работа 6. Построение формы, содержащей блок "V-H-V" ...................... 79 Приложение 1 ........................................................................................................... 87 Приложение 2 ........................................................................................................... 95

Редактор И.Н. Садчикова

Сводный темплан 2004 г.

Лицензия ЛР N 020308 от 14.02.97

Санитарно-эпидемиологическое заключение № 78.01.07.953.П.005641.11.03 от 21.11.2003 г.

Подписано в печать Формат 60х84 1/16

Б.кн.-журн. П.л. . Б.л. РТП РИО СЗТУ

Тираж Заказ ____________________________________________________________

Северо-Западный государственный заочный технический университет

РИО СЗТУ, член Издательско-полиграфической ассоциации вузов Санкт-Петербурга

191186, Санкт-Петербург, ул. Миллионная, 5

Documents

БАЗЫ ДАННЫХ Рабочая - ict.edu.ruict.edu.ru/ft/005410/nwpi232.pdf · Рабочая программа ... Направление и специальность подготовки