Практические занятия 

Тема 1. Анализ предметной области ИС. Разработка технического задания 

1. Цель работы: получить практические навыки в разработке технического задания.

2. Порядок выполнения
Для предметной области, определенной вариантом задания разработать Техническое задание в соответствии с ГОСТом ЕСПД (серия 19).

3. Пример ТЗ
Техническое задание
на разработку «Модуля автоматизированной системы оперативно-диспетчерского управления теплоснабжением корпусов Московского института»

Введение
Работа выполняется в рамках проекта «Автоматизированная система оперативно-диспетчерского управления электро-, теплоснабжением корпусов Московского института».
2. Основание для разработки
2.1.	Основанием для данной работы служит договор № 1234 от 10 марта 2003 г.
2.2.	Наименование работы:
«Модуль автоматизированной системы оперативно-диспетчерского управления теплоснабжением корпусов Московского института».
2.3.	Исполнители: ОАО «Лаборатория создания программного обеспечения».
2.4.	Соисполнители: нет.
3. Назначение разработки
Создание модуля для контроля и оперативной корректировки состояния основных параметров теплообеспечсния корпусов Московского института.
4. Технические требования
4.1. Требования к функциональным характеристикам.
4.1.1. Состав выполняемых функций. Разрабатываемое ПО должно обеспечивать:
•	сбор и анализ информации о расходовании тепла, горячей и холодной воды по данным теплосчетчиков SA-94 на всех тепловых выходах;
•	сбор и анализ информации с устройств управления системами воздушного отопления  и кондиционирования типа РТ1 и РТ2 (разработки кафедры СММЭ и ТЦ);
•	предварительный анализ информации па предмет нахождения параметров в допустимых пределах и сигнализирование при выходе параметров за пределы допуска;
•	выдачу рекомендаций по дальнейшей работе;
•	отображение текущего состояния по набору параметров - циклически   постоянно   (режим   работы   круглосуточный), при сохранении периодичности контроля прочих параметров; 
•	визуализацию информации по расходу теплоносителя:
-	текущую, аналогично показаниям счетчиков;
-	с накоплением за прошедшие сугки, неделю, месяц - в виде почасового графика для информации за сутки и неделю;
-	суточный расход — для информации за месяц.
Для устройств управления приточной вентиляцией текущая информация должна содержать номер приточной системы и все параметры, выдаваемые на собственный индикатор.
По отдельному запросу осуществляются внутренние настройки.
В конце отчетного периода система должна архивировать данные.
4.1.2. Организация входных и выходных данных.
Исходные данные в систему поступают в виде значений с датчиков, установленных в помещениях института. Эти значения отображаются на компьютере диспетчера. После анализа поступившей информации оператор диспетчерского пункта устанавливает необходимые параметры для устройств, регулирующих отопление и вентиляцию в помещениях. Возможна также автоматическая установка некоторых параметров для устройств регулирования.
Основной режим использования системы - ежедневная работа.
4.2.	Требования к надежности.
Для обеспечения надежности необходимо проверять корректность получаемых данных с датчиков.
4.3.	Условия эксплуатации и требования к составу и параметрам технических средств.
Для работы системы должен быть выделен ответственный оператор.
Требования к составу и параметрам технических средств уточняются на этапе эскизного проектирования системы.
4.4.	Требования к информационной и программной совместимости.
Программа должна работать на платформах Windows 98/ NT/2000.
4.5.	Требования к транспортировке и хранению.
Программа поставляется на лазерном носителе информации.
Программная документация поставляется в электронном и печатном виде.
4.6.	Специальные требования.
Программное обеспечение должно иметь дружественный интерфейс, рассчитанный на пользователя (в плане компьютерной грамотности) средней квалификации.
Ввиду объемности проекта задачи предполагается решать поэтапно, при этом модули ПО, созданные в разное время, должны предполагать возможность наращивания системы и быть совместимы друг с другом, поэтому документация на принятое эксплуатационное ПО должна содержать полную информацию, необходимую для работы программистов с ним.
Язык программирования — по выбору исполнителя, должен обеспечивать возможность интеграции программного обеспечения с некоторыми видами периферийного оборудования (например, счетчик SA-94 и т. п.).
5. Требования к программной документации
Основными документами, регламентирующими разработку будущих программ, должны быть документы Единой Системы Программной Документации (ЕСПД): руководство пользователя, руководство администратора, описание применения.
6. Технико-экономические показатели
Эффективность системы определяется удобством использования системы для контроля и управления основными параметрами теплообеспечсния помещений Московского института, а также экономической выгодой, полученной от внедрения аппаратно-программного комплекса.
7. Порядок контроля и приемки
После передачи Исполнителем отдельного функционального модуля программы Заказчику, последний имеет право тестировать модуль в течение 7 дней. После тестирования Заказчик должен принять работу по данному этапу или в письменном виде изложить причину отказа от принятия. В случае обоснованного отказа Исполнитель обязуется доработать модуль.
8. Календарный план работ

№ этапа 	Название этапа 	Сроки этапа 	Чем заканчивается этап 	
1 	Изучение предметной области. Проектирование системы. Разработка предложений по реализации системы 	01. 02.2008-28. 02. 2008 	Предложения по работе системы. Акт сдачи-приемки 	
2 	Разработка программного модуля по сбору и анализу информации со счетчиков и устройств управления. Внедрение системы для одного из корпусов Московского института 	01.03.2008-31.08.2008 	Программный комплекс 	
3 	Тестирование и отладка модуля. Внедрение системы во всех корпусах Московского института 	01. 09.2008-30. 12.2008 	Готовая система контроля теплообеспечения МИЭТ, установленная о диспетчерском пункте. Программная документация. Акт сдачи-приемки работ 	

Руководитель работ                                                                                                                       Сидоров А. В.

Тема 2. Использование диаграмм UML при проектировании систем

1. Цель работы: изучить и научиться использовать на практике диаграммы UML при проектировании систем.

2. Теоретические сведения и пример разработки диаграмм
Одним из способов проектирования является метод CRC-карточек (CRC - Class, Responsibilities and Collaborations). Этот метод проектирования является составляющей UML-проектирования. Метод позволяет быстро идентифицировать классы объектов, отношения между объектами и другую информацию до написания кода.
Для первоначального понимания структуры программы строится диаграмма вариантов использования: выявляются факторы (люди или системы, между которыми происходит взаимодействие), прецеденты системы (действия, выполняемые системой для реализации общения актеров). 
Рассмотрим сказанное на примере банкомата.

Диаграмма вариантов использования

На самом деле прецедентов может быть очень много. Допустим: проверить пароль, проконтролировать транзакции передачи данных, выдать информацию на экран и т. д.
Эта диаграмма помогает понять, что будет делать система, как она функционирует. Диаграмма использования бывает также очень полезна для общения с заказчиком — она позволяет показать наиболее значимые действия системы и проверить, правильно ли вы поняли заказчика и значимость отдельных функций для него.
Шаг второй. UML является объектно-ориентированным языком, кроме того, сам объектно-ориентированный подход уже давно используется — он позволяет упростить процесс программирования, сделать более понятным код.
На этом этапе необходимо выявить классы, которые необходимо будет создать в программе для реализации системы. В случае банкомата это клиент, банк, служба безопасности банка, сам банкомат и т. д.
Далее оформляются CRC-карты. Они разделены на 3 части и выглядят следующим образом:

Название класса 	
Действия, которые он выполняет (всегда начинаются с глагола) 	Классы, с которыми данный класс обменивается информацией 	
На примере того же банкомата:

Клиент	
Клиент
1. Вставляет карточку в банкомат. 
2. Вводит пароль. 
3. Указывает тип операции (снять деньги, просмотреть остаток). 
4. Вводит сумму. 
5. Получает деньги. 
6. Вынимает карточку	Банкомат	

Банкомат	
1.	Отображает информацию для клиента.
2.	Передает информацию в банк
3.	Отсчитывает купюры.
4.	Распечатывает код.	Клиент
Банк
Служба безопасности банка	

Служба безопасности банка	
1. Проверяет пароль.  
2. Проверяет подлинность карточки.  
3. Идентифицирует клиента. 
4. Следит за правильностью транзакций операций с деньгами	Банк
Банкомат	

Банк	
1. Проверяет возможность выдачи средств.    
2. Сообщает о наличии денег.                           
3. Выдает информацию об остатке. 
4. Хранит информацию о счете клиента	Банкомат
Служба безопасности банка	

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

 
Тема 3. Проектирование реляционных БД. Восходящий подход

Цель работы: изучить и научиться использовать на практике метод проектирования реляционных баз данных с помощью универсального отношения.

2. Порядок выполнения
Для предметной области, определенной вариантом задания разработать построить и нормализовать отношения.

3. Пример проектирования с использованием универсального отношения
Рассмотрим предметную область «Проектная организация». Проектная организация заключает Договоры с Заказчиками на выполнение проектов. По одному Договору может выполняться более одного проекта. Суммарная стоимость договора определяется стоимостью всех проектных работ, выполняемых для этого договора. Каждый договор имеет руководителя. Над каждым Проектом работает группа сотрудников (один из них руководит Проектом), причем это могут быть сотрудники не только одного отдела. 
Данные предметной области можно представить в виде сводной таблицы (рис. 1), ориентированной на перечень проектов, ведущихся в организации, с указанием всех их характеристик. В таблице будут следующие столбцы:
•	Проект - уникальный идентификатор проекта (например, его номер или название);
•	Дата_начало_П - дата начала работы над проектом;
•	Дата_конец_П – дата завершения работы над проектом;
•	Руководитель_П – ФИО руководителя проекта (будем считать, что это уникальная идентификация для предметной области);
•	Должность_РП – должность руководителя проекта;
•	Отдел_РП – отдел (номер или название), в котором работает руководитель проекта;
•	Стоимость_П – стоимость проекта;
•	Договор – уникальный идентификатор договора (например, его номер внутри организации), в рамках которого выполняется проект;
•	Руководитель_Д – ФИО руководителя договора (уникальная идентификация для предметной области);
•	Дата_начало_Д – дата заключения договора;
•	Дата_конец_Д – дата окончания действия договора;
•	Исполнитель_П – перечень всех исполнителей проекта (каждый исполнитель уникально характеризуется фамилией, именем и отчеством);
•	Должность_ИП – должности исполнителей проекта (соответственно для каждого исполнителя);
•	Отдел_ИП – отделы, в которых работают исполнители проекта (соответственно для каждого исполнителя).
Для того чтобы преобразовать эту таблицу в реляционное отношение, находящееся в 1НФ, необходимо в каждой строке продублировать все данные о проекте для каждого из исполнителей проекта. При этом будут повторяться и данные о договоре для каждого из проектов, исполняемых по одному договору.
Назовем полученное реляционное отношение «Работа над проектом» (рис. 2).

Проект	Дата_ начало_П	Дата_ конец_П	Руководитель_П	Должность_РП	Отдел_РП	Стоимость_П	Договор	Руководитель_Д 	Дата_ начало_Д	Дата_ конец_Д	Исполнитель_П	Должность_ИП	Отдел_ИП	
П12.1	01.02.05	20.04.05	Самойлов Ю.В.	зав. отделом	1	30000	Д12	Бирюков Р.Л.	20.01.05	01.06.05	Иванов И.И.	конструктор	1	
											Мальцев К.Н.	инженер	1	
											Петров А.К.	техник	2	

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

Проект	Дата_
начало_П	Дата_ конец_П	Руководитель_П	Должность_РП	Отдел_РП	Стоимость_П	Договор	Руководитель_Д 	Дата_ начало_Д	Дата_ конец_Д	Исполнитель_П	Должность_ИП	Отдел_ИП	
П12.1	01.02.05	20.04.05	Самойлов Ю.В.	зав. отделом	1	30000	Д12	Бирюков Р.Л.	20.01.05	01.06.05	Иванов И.И.	конструктор	1	
П12.1	01.02.05	20.04.05	Самойлов Ю.В.	зав. отделом	1	30000	Д12	Бирюков Р.Л.	20.01.05	01.06.05	Мальцев К.Н.	инженер	1	
П12.1	01.02.05	20.04.05	Самойлов Ю.В.	зав. отделом	1	30000	Д12	Бирюков Р.Л.	20.01.05	01.06.05	Петров А.К.	техник	2	

Рис.2. Реляционное отношение «Работа над проектом»

1. Выявление первичного ключа отношения. 
В качестве первичного ключа полученного реляционного отношения, очевидно, выступает совокупность атрибутов Проект (уникальная идентификация проекта) и Исполнитель_П (уникальная идентификация исполнителя проекта). Значения этих двух атрибутов являются необходимыми и достаточными для уникальной идентификации каждой строки таблицы.
Работа_над_Проектом (Проект, Дата_начало_П, Дата_конец_П,
 Руководитель_П, Должность_РП, Отдел_РП,
 Стоимость_П, Договор, 
Руководитель_Д, Дата_начало_Д, Дата_конец_Д, 
Исполнитель_П, Должность_ИП, Отдел_ИП)

2. Выявление атрибутов, функционально зависящих от части составного первичного ключа.
Все атрибуты отношения можно разделить на две группы – атрибуты, характеризующие Проект, и атрибуты, характеризующие Исполнителя. Атрибуты каждой из групп функционально зависят от части первичного ключа: атрибуты, характеризующие Проект, зависят от значения атрибута Проект, а атрибуты, характеризующие Исполнителя, зависят от значения атрибута Исполнитель_П. Таким образом, из исходного отношения необходимо выделить две проекции – отношение «Проект» с первичным ключом Проект и отношение «Исполнитель» с первичным ключом Исполнитель_П :
Проект (Проект, Дата_начало_П, Дата_конец_П, Руководитель_П, 
Должность_РП, Отдел_РП, Стоимость_П, Договор, 
Руководитель_Д, Дата_начало_Д, Дата_конец_Д)
Исполнитель (Исполнитель_П, Должность_ИП, Отдел_ИП)
Из исходного отношения при этом удаляются все атрибуты кроме атрибутов первичного ключа:
Работа_над_Проектом (Проект, Исполнитель_П)

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

Тема 4. ПОСТРОЕНИЕ ИНДЕКСНЫХ СТРУКТУР
ДЛЯ КЛЮЧЕВЫХ ХАРАКТЕРИСТИК ОБЪЕКТОВ

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

1. ЦЕЛЬ РАБОТЫ
Цель работы состоит в изучении логической организации индексов, как основных функциональных структур, оптимизирующих процессы поиска информации. 
В работе рассматриваются алгоритмы построения индексов в прямой и инвертированной форме для данных, хранящихся в виде файлов, состоящих из записей фиксированной длины. В данной работе не рассматриваются структурные аспекты эффективных индексных организаций (например, физическое хранение индексов в виде деревьев): основной акцент делается на логику формирования и возможности последующего использования в процедурах поиска.
Работа имеет теоретический характер и способствует закреплению на практике знаний, полученных в процессе изучения теории баз данных. Варианты задания составлены в форме краткого перечня атрибутов, характеризующих предметную область.

2. ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ
Рассматриваемые в контексте понятий «база данных» и «информационная система» элементы реального мира, информацию о которых необходимо сохранять и обрабатывать, будем называть объектами. Объект может быть материальным (например, «служащий», «изделие» или «населенный пункт») и нематериальным (например, «имя», «понятие», «абстрактная идея»). 
Однако во всех случаях человек, работая с информацией, имеет дело с абстракцией, представляющей интересующий его фрагмент реального мира (т. н. Предметной областью) - той совокупностью характеристических свойств (атрибутов), которые важны для решения его прикладной задачи. 
В задачах обработки информации, и в первую очередь в алгоритмизации и программировании, атрибуты именуют (обозначают) и приписывают им значения. 

2.1. Идентификация записей
В качестве ключа, обеспечивающего доступ к записи, можно использовать идентификатор – отдельный элемент данных. Ключ, который идентифицирует запись единственным образом, называется первичным (главным). Такой ключ используется для поиска информации о конкретном экземпляре объекта. Иногда в качестве идентификатора используют составной сцепленный ключ – несколько элементов данных, которые в совокупности обеспечат уникальную идентификацию каждой записи набора данных.
Если необходимо отыскать некоторую группу записей, имеющих определенное общее свойство, используется так называемый вторичный или альтернативный ключ. Вторичный (альтернативный) ключ – это ключ, идентифицирующий группу записей, обладающих общим свойством. Набор данных может иметь несколько вторичных ключей, необходимость введения которых определяется практической потребностью – оптимизацией процессов поиска записей по соответствующему ключу.
Понятие ключа является логическим и опирается на значения атрибутов. Для того чтобы реализовать выбор записей на физическом уровне, необходимо построить дополнительную структуру, называемую индексом. Таким образом, индекс - физическая реализация ключа, обеспечивающая доступ к записям, соответствующим отдельным значениям ключа. 
Один из способов использования вторичного ключа в качестве входа - организация инвертированного списка, каждый вход которого содержит значение ключа вместе со списком идентификаторов соответствующих записей. Данные в индексе располагаются в возрастающем или убывающем порядке, поэтому алгоритм поиска нужного значения довольно прост и эффективен, а после нахождения значения запись локализуется по указателю физического расположения. Недостатком индекса является то, что он занимает дополнительное пространство и его надо обновлять каждый раз, когда запись удаляется, обновляется или добавляется. На рис. 2.2 приведен инвертированный список для ключа «Должность» таблицы, представленной на рис. 2.1. 
В общем случае инвертированный список может быть построен для любого ключа, в том числе составного.
В контексте задач поиска можно сказать, что существуют два основных способа организации данных. Первый соответствует примеру, приведенному на рис. 2.1, и представляет прямую организацию массива. Второй способ является инверсией первого, он соответствует рис. 2.2. Прямая организация массива удобна для поиска по условию «Каковы свойства указанного объекта?», а инвертированная – для поиска  по условию «Какие объекты обладают указанным свойством?».

2.2. Формы организации индексов
Логически индекс есть бинарное отношение I(v,a), где v – значение атрибута, а a – список адресов элементов хранения (записей, кортежей или документов), соответствующих данному значению атрибута. Для повышения эффективности поиска отдельных значений и слияния/пересечения списков a значения v и адреса элементов в списке a хранятся в упорядоченном виде, что обеспечивает применение процедур быстрого поиска. 

№
записи	Фамилия  И.О.	Год Рожд.	Должность	Кафедра №	
1	Иванов И.И.	1948	Зав. каф.	22	
2	Сидоров С.С.	1953	Проф.	22	
3	Гиацинтова Г.Г.	1945	Проф.	22	
4	Цветкова С.С.	1960	Доцент	22	
5	Козлов К.К.	1959	Доцент	22	
6	Петров П.П.	1960	Ст.преп.	22	
7	Лютикова Л.Л.	1977	Ассистент	22	
8	Рыбин Р.Р.	1950	Зав. каф.	23	
9	Китов К.К.	1944	Проф.	23	
10	Раков В.В.	1958	Доцент	23	
11	Соловьева С.С.	1958	Доцент	23	
12	Воробьева В.В.	1959	Ст.преп.	23	
13	Орлова О.О.	1966	Ассистент	23	
14	Осетров С.С.	1976	Ассистент	23	

Рис. 2.1. Пример набора записей табличного типа

Ассистент	7, 13, 14	
Доцент	4, 5, 10, 11	
Зав. каф.	1, 8	
Проф.	2, 3, 9	
Ст. преп.	6, 12	

Рис. 2.2. Инвертированный список для ключа «Должность»

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

Индекс
		
Значение атрибута	Адрес размещения		Фамилия  И.О.	Год рожд.	Должность	Кафедра №	
1944			Иванов И.И.	1948	Зав. каф.	22	
1945			Сидоров С.С.	1953	Проф.	22	
1948			Гиацинтова Г.Г.	1945	Проф.	22	
1950			Цветкова С.С.	1960	Доцент	22	
1953			Козлов К.К.	1959	Доцент	22	
1958			Петров П.П.	1960	Ст.преп.	22	
1958			Лютикова Л.Л.	1977	Ассистент	22	
1959			Рыбин Р.Р.	1950	Зав. каф.	23	
1959			Китов К.К.	1944	Проф.	23	
1960			Раков В.В.	1958	Доцент	23	
1960			Соловьева С.С.	1958	Доцент	23	
1966			Воробьева В.В.	1959	Ст.преп.	23	
1976			Орлова О.О.	1966	Ассистент	23	
1977			Осетров С.С.	1976	Ассистент	23	

Рис. 2.3. Структура индекса с прямой адресацией
В случае, когда списки a достаточно длинные, инвертированный индекс хранится в двух разных логических файлах, связанных указателями (файл-индекс и файл пересылок на рис. 2.4). Такая организация называется хранением индекса в инвертированной форме, требует меньше памяти для хранения значений ключей и поиск в ней более эффективен.
Указатель пересылок может быть реализован несколькими способами. Например, 
-	указанием ссылки на первый и последний адреса размещения элементов для отдельного ключевого значения, как показано на рис. 2.4;
-	заданием ссылки на адрес размещения первого элемента и длиной списка адресов.

Файл-индекс		Файл пересылок
(инвертированный список)		Файл данных	
Ключевые значения	Указатель пересылок			Адрес
размещения		Ключевое поле	Прочие элементы данных	
…				…		…		
Доцент	
					Доцент	Цветкова С.С. …	
						Доцент	Козлов К.К. …	
…						…		
						…		
				…		Доцент 	Раков В.В. …	
				…		Доцент	Соловьева С.С. …	
				…		…		

Рис. 2.4. Пример реализации инвертированного индекса

2.3. Физические структуры файлов
Ввод-вывод данных осуществляется путем взаимодействия программы с внешними файлами. Файл можно определить как логически непрерывный именованный набор данных на внешнем носителе. 
Устройства, на которые осуществляется вывод данных или с которых осуществляется ввод, могут быть подразделены на следующие типы: 
- устройства передачи информации битовым потоком;
- устройства посимвольного обмена информацией;
- устройства передачи информации записями (порциями).
Фактически тип устройства определяет, каким его «видит» прикладная программа через посредство драйвера устройства и программ операционной системы, ответственных за ввод-вывод информации. Одно и то же устройство может быть представлено как генератор потока символов (потоко-ориентированное устройство) или записей (записе-ориентированное). Поэтому скорее стоит говорить о типе файлов, расположенных на том или ином устройстве.
Могут быть рассмотрены следующие классификации файлов:
- по типу записей:
•	файлы с записями фиксированной длины;
•	файлы с записями переменной или неопределенной длины;
•	файлы, образующие байтовый или битовый поток.
- по способу выборки информации
•	файлы последовательного доступа;
•	файлы прямого доступа.
Для всех этих типов файлов возникает проблема идентификации данных, размещенных на носителе (в файле). 
Рассмотрим файлы прямого доступа. Для таких файлов характерны операции чтения и записи по произвольному адресу. Такие файлы размещаются на дисках, как устройствах прямого доступа.
Простейшим (и наиболее эффективным) способом быстрого нахождения необходимой записи по ее номеру в файле является использование записей с фиксированной длиной. Тогда физический адрес легко вычисляется как некоторое смещение относительно начала файла, пропорциональное номеру выбираемой записи, например:
если в файле F размещено N записей длиной l байт, то:
-	общая длина всего файла - Length(F) = N • l байт;
-	смещение i-й записи от начала файла - Adr(i) = l • (i – 1) байт.
Пусть в файле прямого доступа, содержащем записи длиной L, необходимо поменять местами пятую и шестую записи. Порядок решения такой задачи следующий:
-	открыть файл на чтение-запись;
-	проверить, содержатся ли в файле записи с номером 5 и 6 (т.е. длина файла должна быть больше либо равна 6∙L);
-	определить позицию пятой записи и установить на нее указатель;
-	прочитать пятую запись и поместить ее в переменную Record1;
-	прочитать следующую (шестую) запись и поместить ее в переменную Record2; 
-	установить указатель в файле на пятую запись;
-	записать содержимое Record2;
-	записать содержимое Record1;
-	закрыть файл.
Файлы прямого доступа могут быть типизированы. В этом случае они представляют собой линейную последовательность однотипных компонентов. Наиболее распространенный тип компонента для типизированных файлов – запись. Тип данных запись представляет собой наиболее общий метод получения структурных типов данных. Этот метод заключается в объединении элементов произвольных типов, причем сами эти элементы могут быть в свою очередь структурными. Отдельные элементы записи принято называть полями. Каждое поле данных определено с точки зрения занимаемого им размера (в байтах), а совокупная длина записи представляет собой сумму длин всех входящих в нее полей.
Таким образом, физическая структура файла, состоящего из записей, может быть представлена описанием отдельной записи: составом полей и типами и размерами данных для каждого поля. При этом тип данных поля определяет еще и множество операций и процедур обработки, возможных для значений этого поля.
В таблице 2.1 приведено описание физической структуры файла, элементы которого представляют собой записи, содержащие информацию о результате сдачи экзамена.
Таблица 2.1. Физическая структура записи файла
Имя поля	Тип данных	Размер (в байтах)	Описание	
Family	строка	30	Фамилия	
Name	строка	15	Имя	
Patr	строка	20	Отчество	
Group	строка	5	Номер группы	
Course	целое	1	Курс	
Subject	строка	30	Название предмета	
Mark	целое	1	Оценка	
Общий размер записи =	102		

3. ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ И ОФОРМЛЕНИЯ ОТЧЕТА

3.1. Порядок выполнения работы
1.	Получить от преподавателя номер Варианта Задания.
2.	Построить и заполнить таблицу, содержащую фактические значения атрибутов в соответствии с Вариантом задания (не менее 20 строк).
3.	Описать физическую структуру файла для хранения данных (файл должен состоять из записей фиксированной длины): описать тип данных для каждого атрибута (с указанием длины в байтах), используя базовые типы данных языков программирования (см. табл. 2.1).
4.	Для указанных в Варианте задания атрибутов спроектировать индексы с прямой и инверсной адресацией. При проектировании индексов в качестве адреса размещения записи предлагается использовать ее последовательный номер внутри файла данных.
5.	Описать физическую структуру индекса с прямой адресацией.
6.	Для указанного в Варианте задания атрибута построить индекс с прямой адресацией (рис. 2.5)
7.	Описать физическую структуру индекса с инверсной адресацией.
8.	Для указанного в Варианте задания атрибута построить индекс с инверсной адресацией (рис. 2.6)
9.	Составить алгоритмы изменения каждого из индексов в следующих случаях:
a)	добавление записи в файл данных (в конец файла);
b)	удаление записи из файла данных (в алгоритмах рассмотреть случаи логического, т.е. помеченного для удаления, и физического удаления записи);
c)	модификация значения ключевого атрибута записи.

Номер записи   Значение атрибута 
1	а/м ВАЗ 2110	…	
2	а/м ВАЗ 2121	…	
3	а/м ГАЗ 3110	…	
4	а/м ВАЗ 2110	…	
5	а/м ВАЗ 2121	…	
6	а/м ВАЗ 2101	…	
7	а/м ГАЗ 3110	…	
8	а/м ВАЗ 2110	…	
9	а/м ГАЗ 3102	…	

Файл данных

6	а/м ВАЗ 2101	
1	а/м ВАЗ 2110	
4	а/м ВАЗ 2110	
8	а/м ВАЗ 2110	
2	а/м ВАЗ 2121	
5	а/м ВАЗ 2121	
9	а/м ГАЗ 3102	
3	а/м ГАЗ 3110	
7	а/м ГАЗ 3110	

Индекс

Рис. 2.5. Структура индекса с прямой адресацией 

Значения
индекса	Кол-во вхождений	Ссылка на 1-е вхождение ключа	
а/м ВАЗ 2101	1	1	
а/м ВАЗ 2110	3	2	
а/м ВАЗ 2121	2	5	
а/м ГАЗ 3102	1	7	
а/м ГАЗ 3110	2	8	

Индекс

Файл данных

Номер записи		
1	6	
2	1	
3	4	
4	8	
5	2	
6	5	
7	9	
8	3	
9	7	
Инверсный
файл

Номер	Значение
записи	атрибута 
1	а/м ВАЗ 2110	…	
2	а/м ВАЗ 2121	…	
3	а/м ГАЗ 3110	…	
4	а/м ВАЗ 2110	…	
5	а/м ВАЗ 2121	…	
6	а/м ВАЗ 2101	…	
7	а/м ГАЗ 3110	…	
8	а/м ВАЗ 2110	…	
9	а/м ГАЗ 3102	…	

Рис. 2.6. Структура индекса с инверсной организацией

3.2. Содержание отчета
В отчет необходимо включить:
-	таблицу значений;
-	описание физической структуры основного файла данных и файлов – индексов;
-	алгоритмы работы с индексами;
-	ответы на контрольные вопросы.

4. ВАРИАНТЫ ЗАДАНИЙ

№ 	Наименование	Атрибуты	Прямая адресация	Инверсная адресация	
1	Продажа компьютеров	•	наименование фирмы
•	тип компьютера
•	цена
•	тактовая частота
•	размер ОП
•	размер жесткого диска	Наименование фирмы
	Тип компьютера
	
2	Отдел кадров. Анкетные данные	•	фамилия
•	имя
•	отчество
•	год рождения
•	место рождения
•	адрес
•	семейное положение
•	количество детей	Год рождения
	Количество детей
	
3	Деканат. Сессия	•	курс
•	группа
•	фамилия и инициалы
•	оценка 
•	дисциплина	Дисциплина

	Группа
	
4	Деканат.
Личные карточки.	•	Фамилия
•	Имя
•	Отчество
•	Год рождения
•	Год поступления
•	Город – место жительства
•	Факультет	Город
	Год поступления

5	Библиотека	•	Автор(ы)
•	Название
•	Год издания
•	Издательство
•	Место издания
•	Количество страниц	Издательство
	Место издания
	
6	Отдел кадров. Основные сведения	•	Табельный номер
•	Должность
•	Оклад
•	Номер отдела	Номер отдела
	Должность
	
7	Подписка на периодические издания	•	Издание
•	Количество экземпляров
•	Фамилия подписчика
•	Адрес
•	Продолжительность	Фамилия подписчика
	Издание
	
8	Склад	•	Наименование товара
•	Фирма-поставщик
•	Количество единиц
•	Цена за единицу товара	Наименование товара
	Фирма-поставщик
	
9	Регистрация документов	•	Тип документа
•	Вид документа
•	Дата регистрации
•	Контрольная дата
•	Ответственный исполнитель
•	Подразделение	Вид документа
	Подразделение
	
10	Преподава-тели факультета	•	Фамилия
•	Имя
•	Отчество
•	Год рождения
•	Кафедра
•	Должность	Кафедра
	Должность
	
11	Зоопарк	•	Кличка животного
•	Вид животного
•	Пол
•	Дата рождения
•	Страна происхождения	Вид животного
	Страна происхож-дения
	
12	Рабочий учебный план	•	Наименование дисциплины
•	Семестр
•	Количество часов
•	ФИО преподавателя
•	Кафедра	Кафедра
	ФИО преподава-теля
	
13	Дипломная работа	•	ФИО студента
•	Тема работы
•	ФИО научного руководителя
•	Кафедра
•	Оценка за преддипломную практику	ФИО научного руководителя
	Кафедра
	
14	Торговый флот	•	Тип судна
•	Название
•	Порт приписки
•	Грузоподъемность	Тип судна
	Порт приписки
	
15	Продажа автомашин	•	Марка машины
•	Цвет
•	Тип кузова	Цвет
	Марка машины
	
16	Наличие лекарств	•	Номер аптеки
•	Наименование препарата
•	Фирма-производитель
•	Цена	Фирма-производитель
	Наименование препарата
	
17	Музыкальный магазин	•	Исполнитель
•	Название альбома
•	Жанр
•	Носитель
•	Продолжительность звучания
•	Цена	Исполнитель
	Жанр
	
18	Жилой фонд	•	Район
•	Улица
•	Номер дома
•	Ближайшая станция метро
•	Количество квартир
•	Количество этажей	Район
	Улица
	
19	Квартира	•	Улица
•	Номер дома
•	Этаж
•	Количество комнат
•	Площадь	Этаж
	Количество комнат
	
20	Заказ	•	Номер заказа
•	Дата заказа
•	Наименование товара
•	Количество единиц
•	Цена за единицу
•	ФИО ответственного исполнителя	Наименование товара
	ФИО исполнителя

Тема 5. Реинжиниринг информационных систем

1. Цель работы
Целью работы является изучение и закрепление следующих базовых операций при проведении реинжиниринга информационных систем:
–	общий анализ ситуации реинжиниринга информационной системы;
–	выбор наиболее рационального пути реинжиниринга информационной системы;
–	генерация альтернатив реинжиниринга информационной системы.

2. Порядок выполнения работы
1.	Студент самостоятельно выбирает информационную систему. Это должна быть хорошо знакомая ему информационная система, требующая реинжиниринга. Лучший вариант – информационная система, разработанная (или разрабатываемая) в рамках учебно-исследовательской работы.
2.	Студент проводит анализ и дает характеристику ситуации реинжиниринга ИС в следующем составе:
2.1.	Краткое описание назначения ИС.
2.2.	Функциональная модель ИС в составе контекстной диаграммы и диаграммы декомпозиции первого уровня (3-7 функциональных блоков).
2.3.	Основные причины (5-7), приведшие к ситуации реинжиниринга.
2.4.	Основные риски (5-7) и факторы успеха (5-7) проекта реинжиниринга.
2.5.	Идея убеждения руководства предприятия в необходимости реинжиниринга информационной системы.
3.	Студент проводит выбор пути реинжиниринга ИС и приводит обоснование выбора. Для этого приводятся анализ достоинств и недостатков основных путей реинжиниринга в конкретной ситуации (реинжиниринг ИС, выбранной студентом в выбранной им же ситуации).
4.	Студент генерирует альтернативы реинжиниринга информационной системы. Для этого приводятся:
4.1.	Основные требования к ИС (5-7).
4.2.	Частные варианты разрешения требований (по 2-3 варианта для каждого требования).
4.3.	Функциональные компоненты ИС (на базе ее функциональной модели), требующие модификации (или создания).
4.4.	Графическое представление альтернатив реинжиниринга ИС (граф, связывающий требования, частные варианты и функциональные компоненты информационной системы).
5.	Результаты работы оформляются в виде отчета (разделы отчета соответствуют пп. 2-4).

Тема 6. Описание документов средствами различных ИПЯ

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

2. Теоретические сведения
Лингвистическое обеспечение – это совокупность языковых средств (в том числе и правила реферирования и индексирования), позволяющих более или менее подготовленному пользователю взаимодействовать с машинной системой (по крайней мере, в части отыскания нужных пользователю документов).
ЛО имеет еще и «системное», предназначение – согласование точек зрения на предметную область как для различных поставщиков и потребителей информации, так и во времени: ИПЯ имеет искусственную природу и создается в конкретных условия.
В основу методов представления смысла положена та или иная знаковая система, но при этом различают классификационный и описательный подходы. 
Классификация, как средство описания содержания документа, представляет собой процесс соотнесения содержания документов с понятиями, зафиксированными в заранее составленных систематических схемах. Классификационные методы обеспечивают систематизацию объектов в соответствии с некоторой заданной классификационной схемой. Код, присвоенный отдельному классу, обеспечивает его полную идентификацию в рамках конкретного классификатора.
Описательные методы идентификации используются, как правило, в тех случаях, когда необходимо идентифицировать конкретный объект или группу объектов путем описания произвольного набора его характеристик. Описательный метод предполагает наряду с указанием классификационных характеристик выделение дополнительных наборов свойств, углубляющих характеристику объекта и сужающих область поиска. Описательный подход в большей степени поддерживается языками дескрипторного типа. Они реализуют координатное индексирование, которое заключается в формировании описания документа как совокупности дескрипторов, выбираемых из заранее созданных словарей понятий либо из текстов документов.

Государственный рубрикатор научно-технической информации
Государственный рубрикатор научно-технической информации (ГРНТИ) представляет собой универсальную трехуровневую иерархическую классификацию областей знания, принятую для систематизации всего потока научно-технической информации.
Рубрикатор имеет многоцелевое назначение, отвечает потребностям всех информационных органов в силу универсальности охвата тематики, обеспечивает многофункциональное использование. 
Рубрикам (в качестве справочной информации) поставлены в соответствие индексы УДК и коды Номенклатуры специальностей научных работников ВАК. Это обеспечивает взаимосвязь между классификационными системами, а также возможность поиска документов в информационных массивах и базах данных, систематизированных по УДК и номенклатуре специальностей ВАК. 
Состав и структура Рубрикатора. Рубрикатор имеет 3 уровня иерархии, при этом весь универсум знаний условно разделен на 4 подкласса:
-	«Общественные науки» (значение кода первого уровня от 00 до 26); 
-	«Естественные и точные науки» (значение кода первого уровня от 27 до 43); 
-	«Технические и прикладные науки. Отрасли экономики» (значение кода первого уровня от 44 до 81); 
-	«Межотраслевые и комплексные проблемы» (значение кода первого уровня от 82 до 90). 
Каждая рубрика состоит из кода (нотации) и наименования (описание класса), а также может иметь при себе ссылки и примечания. 
На каждом уровне Рубрикатора возможно деление на 100 подклассов. Коды рубрик состоят из цепочки пар арабских цифр, разделенных точкой. В конце кода точка не ставится. 
Наименование рубрики представляет собой текст, отражающий ее смысловое содержание, например: 
37.23.31 Моделирование климата. Прогноз климата. 
Рубрикатор является иерархической классификацией и построен так, что классы одного уровня, как правило, не пересекаются, а понятия одного уровня находятся в состоянии подчинения к понятию более высокого уровня, например: 
73 Транспорт 
73.29 Железнодорожный транспорт 
73.31 Автомобильный транспорт 
73.34 Водный транспорт 
73.37 Воздушный транспорт 
73.39 Трубопроводный транспорт 
Признаком, по которому проведено деление класса «73 Транспорт», является признак отнесения к видам технических средств перевозки. Перечисленные виды транспорта не пересекаются, а в совокупности составляют класс "Транспорт" — обобщенное понятие более высокого уровня иерархии. 
В Рубрикаторе использовано сочетание иерархии с фасетным принципом, который проявляется в наличии совокупности рубрик, повторяющейся в разных классах в виде группы "Общие вопросы", а также в применении типовых классификационных делений в разных разделах Рубрикатора.
Для исключения дублирования разделы Рубрикатора включают тематическое «ядро» предметной области, оснащенное ссылками на связанные с ним смежные вопросы, помещенные в других тематически близких разделах Рубрикатора. 
Уровень рубрики, соответствующей определенной области знания, отражает не ее значимость, а только степень обобщения при логической группировке понятий. В пределах одного уровня располагаются примерно равнозначные по объему понятия. 
Рубрикатор обеспечивает отнесение каждого документа к минимально необходимому числу рубрик, поскольку между рубриками, имеющими логико-семантические связи, существуют разграничения аспектов, отраженных в наименованиях рубрик, примечаниях и ссылках. 

Универсальная десятичная классификация
УДК, построенная по систематическому принципу, понимается как система цифрового кодирования не содержания, а поисковых образов (признаков) документа, которые формально отделяются от его содержания. 
C 1963 г. классификация всех публикаций в области технических и естественных наук по УДК введена в качестве обязательной в научно-технических издательствах, редакциях научно-технических журналов, органах научно-технической информации.

Структура УДК. Все классы УДК сгруппированы в шесть фасетов (Общий предмет, Место, Народность, Время, Язык документа, Форма документа), каждый из которых подразделяется по иерархическому принципу на несколько уровней. Для идентификации отдельного класса на каждом уровне используются десятичные цифры, тем самым, в индексах УДК каждая последующая цифра не меняет значения предыдущих, а лишь уточняет их, обозначая частное понятие. Индекс УДК представляет собой последовательность десятичных цифр, возможно разделенных на группы знаками «точка».
Фасет «Общий предмет» (основная таблица классификации) имеет десять основных подразделений, которые называются главными классами. 
Основная таблица включает понятия и соответствующие им индексы, охватывающие классы от 0 до 9 с их дальнейшими делениями по содержанию. Главными классами фасета «Общий предмет» являются:
0 Общий отдел 
1 Философия. Психология. Логика 
3 Общественные науки 
5 Математика. Естественные науки 
6 Прикладные науки. Медицина. Техника 
7 Искусство. Декоративно-прикладное искусство. Фотография. Музыка. Игры. Спорт 
8 Языкознание. Филология. Художественная литература. Литературоведение 
9 География. Биографии. История 
Остальные фасеты УДК получили название вспомогательных таблиц, предназначенных для классификации по дополнительным признакам. Вспомогательные индексы (определители) этих таблиц бывают двух видов: общие, которые могут соединяться с любыми индексами основной таблицы УДК, и специальные, присоединяемые только к понятиям текущеого раздела.
Кроме общей фасетной формулы в УДК применяется также субформула для построения сложных предметных индексов. В этом случае предметный индекс УДК состоит из нескольких простых индексов, соединяемых друг с другом знаками присоединения, распространения, объединения или отношения. 

Международная патентная классификация
Международная патентная классификация (МПК) обеспечивает достаточно полное индексирование предмета патентования с помощью ограниченного числа рубрик за счет ориентации последних на аспекты, важные с точки зрения патентного права, такие как характеристика вещества или устройства, его функции, применение, получение. Классификация представляет собой специальную, имеющую технико-прикладной характер, линейную систему иерархического типа, предназначенную для ручного индексирования. Согласно основным принципам применения Международной патентной классификации, указывающим, что изобретение, подлежащее классификации, не может рассматриваться как чистая идея в отрыве от ее технического воплощения в устройстве, способе или веществе, выделяют следующие предметы (объекты) изобретения:
1) вещество или материал;
2) устройство, прибор, конструкция;
3) процесс, способ, метод;
Правила классифицирования. Основным назначением МПК является облегчение поиска аналогичных технических решений. В связи с этим МПК разработана и должна использоваться таким образом, чтобы одинаковые технические решения классифицировались одинаково, и, следовательно, могли быть найдены в одном и том же месте системы классификации. Методика классифицирования опирается на выявление технической сущности изобретения. Техническую сущность изобретения может представлять собой способ, продукт или устройство (или способ их использования или применения), причем эти термины используются в МПК в самом широком смысле. Например:
способ – полимеризация, ферментация, разделение, формование, транспортирование, обработка текстиля, передача и преобразование энергии, строительство, методы работы на машинах, способы работы машин, обработка и передача информации;
продукт - химическое соединение, состав, ткань;
устройство - установка для проведений химических или физических процессов, инструмент, орудие, машина, устройство для выполнения технологических операций.

Структура МПК. МПК охватывает все области знаний, которые могут подлежать защите охранными документами и имеет иерархическую 4-х уровневую структуру. 
1. Раздел. Обозначается латинской заглавной буквой от А до Н и снабжен заголовком, укрупнено отражающим его содержание. 
МПК включает следующие 8 разделов:
А - удовлетворение жизненных потребностей человека;
B - различные технологические процессы, транспортирование;
C - химия, металлургия;
D - текстиль, бумага;
Е - строительство, горное дело;
F - механика, освещение, отопление, двигатели и насосы, оружие, боеприпасы, взрывные работы;
G - физика;
H - электричество.
2. Класс. Каждый раздел делится на классы, обозначаемые двузначным числом. Содержание класса отражает заголовок класса. Некоторые классы снабжаются кратким перечнем относящейся к ним тематики - указателем класса.
3. Подкласс. Каждый класс содержит один или более подклассов, обозначаемых заглавной буквой латинского алфавита. Содержание подкласса определяет заголовок подкласса. Некоторые подклассы снабжаются кратким перечнем относящейся к ним тематики - указателем содержания подкласса.
4. Группа, подгруппа. Каждый подкласс разбит на подразделения, которые в дальнейшем именуются «дробными рубриками». Среди дробных рубрик различают основные группы и подгруппы. 
Дробная рубрика обозначается двумя числами, разделенными наклонной чертой. Первое (максимум трехзначное, обычно нечетное) число индексирует основную группу, второе (минимум 2 цифры, обычно четное) – подгруппу. Для основной группы код подгруппы имеет значение 00. Каждую третью или четвертую цифру после наклонной черты следует понимать как дальнейшее десятичное деление предыдущей цифры. Отсюда следует, что подгруппа с индексом 5/417 должна стоять после подгруппы 5/41, но перед подгруппой 4/42.
Текст основной группы определяет область, которая считается целесообразной для проведения поиска. Текст и индексы основных групп выделены жирным шрифтом.
Текст подгруппы понимается всегда в пределах объема ее основной группы и определяет тематическую область, в которой считается целесообразным проведение поиска. Перед текстом подгруппы ставится одна или более точек, которые определяют степень ее подчиненности, т.е. указывают на то, что подгруппа является рубрикой, подчиненной ближайшей вышестоящей рубрике, напечатанной с меньшим сдвигом, т.е. имеющей на одну точку меньше. 

Анализ содержания текста документа
Сначала анализируется заголовок, затем реферат, оглавление и полный текст документа.
Из заголовка, реферата, оглавления и текста документа выбираются понятия (ключевые слова), наиболее полно отражающие содержание документа. 
При анализе содержания документа следует выбирать только полезную информацию. Критерием, которым следует руководствоваться при этом выборе, является то, что полезная информация наиболее информативна и интересна с точки зрения пользователя системы. Документ может быть адекватно определен одним, двумя и, возможно, тремя наиболее важными аспектами, которые обычно являются основанием для опубликования этого документа. В процессе подготовки поискового образа необходимо представить каждый из этих аспектов одним или несколькими понятиями и затем согласовать эти группы для отражения содержания рассматриваемого документа. 
При индексировании публикаций предметными рубриками ГРНТИ или УДК необходимо выделить основной предмет исследований публикации в контексте тематики предметной области. Основной задачей является определение первой рубрики (с точки зрения важности для предметной области, например ядерной науки и технологии). Первая рубрика должна отвечать основной теме исследований, результаты которых рассматриваются в данной конкретной публикации. Если в публикации приведена информация, относящаяся к другим тематическим направлениям, правила рубрикации позволяют приписать ей одну или несколько второстепенных предметных рубрик. Теоретически число второстепенных рубрик не ограничено, однако их число обычно не должно превышать одной или двух.
При выборе ключевых слов следует помнить, что следует использовать только те ключевые слова, которые действительно отражают понятия, рассматриваемые в документе, т.е. каждое выбранное ключевое слово должно нести достаточную информативную нагрузку.

3. Порядок выполнения работы
3.1. Провести содержательный анализ документа – варианта индивидуального задания. Определить основной предмет и аспекты. 
3.2. Построить систему (дерево) основных понятий. 
3.3. Сформировать поисковые образы документа для каждого аспекта с использованием ГРНТИ, УДК и/или МПК, ключевых слов.

Тема 7. Язык определения данных документальной ИПС

1. Цель работы
Целью работы является изучение лингвистических средств представления записей в документальной БД.
Работа имеет практический характер и способствует пониманию роли языков определения данных в контексте эффективности представления и использования материала документальной ИПС. 
Варианты заданий представлены в форме наборов элементов данных библиографических описаний отдельного вида публикаций.

2. Теоретические сведения
Различные практические цели использования документальной информации (например, составление библиографического списка цитированной литературы, тематический поиск или анализ виртуальных авторских коллективов) предопределяют необходимость управление формой представления документов и/или списков документов. В документальных АИС, где разнообразие информации достаточно ограниченно, для определения формата представления обычно используются так называемые схемы документов (или схемы БД), позволяющие оперативное изменить форму и наполнение отображения документа.

3. Порядок выполнения работы
Для заданной формы библиографического описания вида издания (руководствуясь правилами составления библиографического описания: см. Общие правила оформления библиографического списка и ссылок. –М.: МИФИ, 2007 ) сформировать схему документа, определив элементы описания и команды управления выводом (Приложение 1).

Приложение 1
Описание полей схемы документа АИС IRBIS

Описатель	Значение	Комментарий	
имя поля

#имя_базы_данных

*IDN

FILLER,
TRAILER

INDEX

LINKUP,
LINKDOWN

&псевдоним

$FCOMMENT

	строка до 11 прописных символов	Алфавитно-цифровое значение, начинающееся всегда с буквы, котоpое используется в формулировках запроса или для выбора словаря для просмотра. 
Имя поля, равное '#имя_базы_данных', специфицирует подстановку текста документов, найденных в указанной базе данных по запросу-подстановке, имя файла которого приведено в описателе заголовка поля. Текст будет сформатирован по схеме, имя которой приведено в описателе управления выводом. 
Имя поля, равное '*IDN', специфицирует вывод внутреннего идентификатора документа.
Для расширения возможностей отображения документов могут использоваться вспомогательные поля-заполнители: FILLER и TRAILER. Если в качестве имени поля указывается значение FILLER, то будет выводиться только текст заголовка в соответствии с командами управления выводом. Если в имени поля используется значение TRAILER, то обработка аналогична FILLER-полю, но только при условии, что поле документа, непосредственно предшествующее в описании TRAILER-полю, было непустое. Если значение метки поля-заполнителя не равно 0, то вывод заголовка будет производиться в том случае, если поле документа с меткой поля, равной специфицированной, будет не пустое.
Если в имени поля используется значение INDEX, то при вызове функции F6 просмотра словаря значение этого поля будет выводиться только для первого документа списка документов, содержащих слово, на которое указывает маркер. 
Имя поля, равное 'LINKUP' ('LINKDOWN'), для поля ссылочного типа используется для физической связи с предыдущим (последующим) физическим документом, переход к которому происходит при двойном нажатии клавиши перемещения маркера вверх (вниз), если последний уже находится в первой (последней) строке документа. Значения этих полей должны быть сформированы при загрузке документов в базу данных. 
Имя поля равное '&псевдоним' при загрузке схемы будет заменено на фактическое значение имени, заданное в файле конфигурации БД в строке определения псевдонима: 
&псевдоним = факт.имя_поля; 
Имя поля равное $FCOMMENT определяет Наименование этого поля в списке поисковых полей вместо заголовка.	
заголовок поля	строка до 19 символов	Текст, предшествующий при отображении матеpиалу поля. 
Знак '\' в заголовке вызывает размещение текста, следующего за этим знаком, с новой строки.	
метка сегмента	1<=число<=127	Десятичное число, идентифицирующее материал поля в базе данных.	
флаг загрузки	Y/N	Символьное значение, разрешающее или запрещающее загрузку в базу данных. Материал поля, для которого флаг имеет значение 'Y', при загрузке помещается в базу данных; если же флаг имеет значение 'N', материал поля игнорируется в момент загрузки.	
формат	A/N/E/B/H/R/
D/J/I/S/P/T	Символьное значение, задающее способ представления материала. Материал поля может быть представлен: 
- в символьном формате ('A'); 
- в цифровом формате ('N'); 
- в числовом формате с плавающей точкой ('E'); 
- битовой последовательностью ('B'); 
- байтовой последовательностью в шестнадцатеричном представлении ('H'); 
- в виде ссылки на документ ('R'); 
- в виде даты в формате YYMMDD ('D'); 
- в виде даты в формате DD month YYYY ('J'); 
- в виде даты в формате DD.MM.YY ('I'); 
- в виде даты в формате MM-DD-YY ('S'); 
- графическом файлом в формате PCX ('P'), или в формате TIFF ('T'). 
Если поле представлено в цифровом формате ('N'), то соответствующее значение в словаре будет дополнено до указанной длины лидирующими нулями, а при поиске сравнение будет проводиться по правилам сравнения целых чисел.	
длина поля	0/число	Число, задающее для поля фиксированной длины количество позиций, резервируемых для размещения материала. 
Для полей неограниченной длины необходимо задать нулевое значение. 
Для цифровых полей каждое значение в словаре будет дополнено до заданной длины нулями слева.	
ключ	N/K/D/A	Символьное значение, задающее характер использования справочных структур. 
Для полей со значением ключа 'N' справочные поисковые структуры не создаются. 
Для полей со значениями ключа 'K' и 'D' строятся справочные поисковые структуры, причем имя поля, имеющего значение ключа 'D', при открытии базы данных будет установлено как текущее и, если оно не изменяется другими средствами, будет использоваться в любом запросе, требующем имя поля по умолчанию. 
Для полей со значением ключа 'A' при поиске используются справочные структуры, построенные по материалу возможно нескольких полей. 	
метка ключа	1<=число<=127	Десятичное число, идентифицирующее при загрузке любое поле, материал которого использовался для построения словаря, а при поиске задающее внутренний идентификатор словаря, по которому будет проводиться отбор документов по критерию, использующему это поле.	
строчный
регистр	Y/N	Символьное значение, определяющее характер использования строчного регистра в дескрипторах словаря. 
Значение 'Y' разрешает использование строчных букв. Если задано значение 'N', то строчные буквы в дескрипторах словаря и ключевых словах запроса преобразуются в прописные.	
разделители
предложений	список до
11 символов	Список символов, рассматриваемых в качестве ограничителей предложений при выделении слов на этапе построения словарей, а также при поиске и отображении материала.
Для спецификации разделителей с кодами меньше 32 необходимо использовать двухсимвольную конструкцию, в которой код разделителя получается путем вычитания кода символа '@' (шестнадцатеричное 40) из кода второго символа. 
Двойной символ '@@' дает значение разделителя '@'.	
разделители
слов	список до
11 символов	Список символов, рассматриваемых в качестве ограничителей при выделении слов на этапе построения словарей, а также при поиске и отображении материала. 
Для спецификации разделителей с кодами меньше 32 необходимо использовать двухсимвольную конструкцию, в которой код разделителя получается путем вычитания кода символа '@' (шестнадцатеричное 40) из кода второго символа. 
Двойной символ '@@' дает значение разделителя '@'.	
максимальная длина слова	0<=число<=32	Числовое значение, ограничивающее длину слова, помещаемого в словарь. Длинные слова усекаются до максимально разрешенной длины.	
минимальная длина слова	0<=число<=32	Числовое значение, ограничивающее длину слова, помещаемого в словарь. Слова, имеющие длину менее минимальной, в словарь не включаются.	
управление
выводом

Формат

Горизонталь-ная позиция

Вертикаль-
ная позиция

С новой
 строки

Непосредст-венное следование

Абзац

Обратный отступ

Центрирова-ние
Выравнива-ние влево
Выравнива-ние вправо
Повторение заголовка

Группа

Сортировка

Исключающая сортировка

Вывод пустого поля

Подавление вывода

Избиратель-ный вывод сегментов

Вывод разделителей

Подавление вывода

	строка до 
19 символов

Fчисло

Хчисло 

Yчисло

N

G

Aчисло

Iчисло

C

L

R

Oчисло

Hчисло

Uчисло
Dчисло
0<число<7

U8
D8

Eчисло

'.'

''

число

'#'

'!'

S

'-'
-число

''
	Строка команд, управляющих разщением материала при отображении документов на экране, распечатке или выводе в файл для последующей обработки. 
Команды и, если необходимо, их числовые параметры записываются подряд без каких-либо разделителей:

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

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

задает позицию первой строки материала поля;

вызывает размещение материала поля с новой строки. Размещение материала полей, для которых не задано команды "новая строка", начинается со строки, в которой начинался материал последнего поля, имеющего команду 'N' в списке команд управления выводом; 

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

задает величину абзацного отступа в символах; 

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

центрирует текст поля по формату; 

выравнивает текст поля влево по формату; 

выравнивает текст поля вправо по формату; 

текст заголовка поля выводится подряд указанное число раз; 

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

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

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

специфицирует для пустого поля вывод на экран заголовка и специального знака (код '08'). Параметр задает вертикальный размер окна для ввода значения поля и используется обычно при редактировании полей документа; 

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

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

специфицирует вывод списка разделителей предложений перед выводом поля. Если символ '#' приведен в определении поля-начала документа, то соответствующий список разделителей предложений будет выведен перед началом документа; 
специфицирует вывод списка разделителей предложений после вывода поля. Если символ '!' приведен в определении поля-начала документа, то соответствующий список разделителей предложений будет выведен после конца документа; 

подавляет вывод подполя, имеющего пробельное значение; 
для поля-заполнителя подавляет его вывод, если перед ним выводился заполнитель с командой "-"; 
подавляет вывод информационного поля, если поле с указанной меткой (число) имеет в документе не пустое значение;
отменяет подавление вывода условного заполнителя (FILLER, TRAILER, значение метки поля которого указывает на ведущеее поле) в последнем экземпляре группы или (в режиме вывода в IRBIS-формате) специфицирует вывод поля со значением метки, приведенной в заголовке этого поля.	
Файл специальной обработки	имя файла	специфицирует имя текстового файла, находящегося в текущей директории. 
Файл с расширением 'STP' содержит слова, которые не должны включаться в словарь поля.
Файл с расширением 'PLS' содержит слова, которые должны включаться в словарь поля. Такие слова записываются в файл отдельными текстовыми строками и должны быть упорядочены по кодам алфавита. 
Файл удаляемых символов имеет расширение 'PRG'. При загрузке документов символы (байты), приведенные в единственной строке файла, будут удаляться из этого поля. 	

Тема 8. Коммуникативные форматs и языки

Введение
Кроме развитого информационного обмена в библиотечных сетях, сегодня существует большая и быстрорастущая группа программного обеспечения, работающего со слабоструктурированными данными, как, например, банковские системы, системы управления документооборотом предприятия, электронные издания. Одной из важных функций таких приложений являются те, которые относятся к категории обмена электронной информацией. 
Такая информация требует применения технологий обработки и описания на уровне семантики, а не только синтаксиса (форматирования) документов Теги наиболее широко распространенного HTML описывают визуальное представление документа, ссылки между документами и т.д., но не несут в явной форме информации о семантической структуре документа, что крайне осложняет их использование при обработке запросов. Именно стремление обеспечить возможность представления семантической структуры документов в Интернете явилось одной из главных причин разработки и внедрения XML.
Слабоструктурированными называются данные, обладающие определенной структурой, но эта структура может оказаться непостоянной или определенной не полностью. Коллекции таких документов иногда называют не имеющими схемы, (schema-less) или самоопределенными (self-describing). Характерной особенностью слабоструктурированных данных является то, что описательная информация, которая обычно выделяется в отдельную схему, в той или иной форме присутствует в самих данных. В некоторых формах представления слабоструктурированных данных не предусмотрено применение отдельной схемы, а в других она существует, но налагает на представленные в ней данные очень слабые ограничения. 
В отличие от этого, для реляционных СУБД требуется заранее определенная схема, позволяющая распределить данные по таблицам, а все данные, управляемые этой системой, должны соответствовать такой структуре. Объектно-ориентированные СУБД допускают создание более гибкой структуры по сравнению с реляционными СУБД, но также требуют, чтобы все данные укладывались в заранее заданную схему. 
Схема слабоструктурированных данных может быть как предписывающей, так и описывающей.
Примером предписывающей схемы слабоструктурированных данных является Document Type Definition (DTD), которая описывает структуру XML-документов, а XML-процессоры используют это описание при разборе. Если разбираемый документ не соответствует DTD, процессор прекращает его разбор и сигнализирует об ошибке. Таким образом, предписывающая схема накладывает ограничения на структуру данных. Другими примерами описывающей схемы данных являются XML-схемы.

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

2. Теоретические сведения

2.1. Коммуникативный формат МЕКОФ
Стандарт для коммуникативного формата МЕКОФ устанавливает структуру записи и ее наполнения для обмена библиографическими или другими данными на машиночитаемых носителях. 

БИБЛИОГРАФИЧЕСКАЯ ЗАПИСЬ В КОММУНИКАТИВНОМ ФОРМАТЕ - это совокупность полей, включая маркер записи, справочник и поля данных, описывающая одну или несколько библиографических единиц, рассматриваемых как единое целое. Допускается установление связи между отдельными библиографическими записями и разделение библиографической записи на подзаписи. 
ПОДЗАПИСЬ - группа полей в пределах одной записи, воспринимаемая как единое целое. 
СТРУКТУРА ЗАПИСИ - схема расположения компонентов, составляющих библиографическую запись. 
Структура записи включает: 
- маркер записи;
- справочник; 
- поля данных; 
- разделитель записи. 
МАРКЕР ЗАПИСИ - структурный компонент, находящийся в начале каждой записи и содержащий параметры для ее обработки. 
СПРАВОЧНИК - состоящий из нескольких статей указатель местонахождения полей данных в записи.
ПЛАН СПРАВОЧНИКА - набор параметров, определяющих структуру статей справочника. 
ПОЛЕ ДАННЫХ (ПОЛЕ) - часть библиографической записи, имеющая переменную длину, следующая за справочником и связанная с одной из его статей. Поле данных может содержать одно или несколько ПОДПОЛЕЙ. 
ИДЕНТИФИКАТОР - элемент, состоящий из одного или нескольких символов, непосредственно предшествующий подполю и идентифицирующий его. 
ИНДИКАТОР - элемент, расположенный, если он имеется, в начале поля и несущий дополнительную информацию о содержании поля, взаимосвязи между этим полем и другими полями в записи или об операциях, требуемых при определенной обработке данных. 
МЕТКА - три символа, связанные с полем и однозначно идентифицирующие его наполнение. 
РАЗДЕЛИТЕЛЬ - управляющий символ, предназначенный для разделения данных в логическом, а иногда в иерархическом смысле. 
Справочник и поля данных заканчиваются РАЗДЕЛИТЕЛЕМ ПОЛЯ (ASCII-код 1Еh). Запись заканчивается РАЗДЕЛИТЕЛЕМ ЗАПИСИ (ASCII-код 1Dh). 

Маркер записи имеет фиксированную длину и состоит из следующих компонентов: 
длина записи (позиции 0-4) - количество символов в записи, включая маркер и разделитель записи, выражается десятичным числом, выравниваемым вправо и дополняемым слева до пяти символов нулями; 
статус записи  (позиция 5) - один символ, который должен быть определен в нормативно-технических документах по применению данной структуры записи, например, "новая" или "изменяющая" запись; 
коды применения (позиции 6-9) - коды, которые могут быть определены в нормативно-технических документах по применению данной структуры; 
длина идентификатора (позиция 10) - десятичная цифра, определяющая количество символов индикатора. Если индикатор не используется, длина индикатора принимает значение равное нулю;
длина индикатора (позиция 11) - десятичная цифра, определяющая количество символов идентификатора. Первым или единственным символом идентификатора должен быть ASCII-код 1Fh. Если идентификатор не используется, длина идентификатора принимает значение равное нулю;
базовый адрес данных  (позиции 12-16) - десятичное число, выравниваемое вправо и дополняемое до пяти символов нулями, указывающее общую длину в символах маркера записи и справочника, включая разделитель поля в конце справочника; 
набор кодов  (позиции 17) - символ, определяющий набор кодов и используемый для представления данных в записи, включая маркер записи, справочник, метки, индикаторы, идентификаторы, разделители и поля данных. Значения данного символа должны быть определены в документах по применению данной структуры записи;
зарезервировано (позиции 18, 19) - определяются пользователем;
план справочника  (позиции 20-23): 
позиция 20 - десятичная цифра, указывающая длину в символах компонента "длина поля данных" каждой статьи справочника; 
позиция 21 - десятичная цифра, указывающая длину в символах компонента "позиция начального символа" каждой статьи справочника; 
позиция 22 - десятичная цифра, указывающая длину в символах компонента "часть, определяемая при применении" (ЧОП) каждой статьи справочника; 
позиция 23 - зарезервирована. 

Справочник состоит из переменного числа статей, каждая из которых идентифицирует соответствующее поле данных (идентификатор записи, резервные и библиографические поля). Все статьи справочника имеют одинаковую структуру.
Статья справочника  содержит в приведенном порядке следующие компоненты:
метка  (определение метки см. выше);
длина поля данных  - определяется: 
1) общим количеством символов (включая индикатор и разделитель поля) в поле данных, идентифицируемом данной меткой, или 
2) нулем, обозначающим, что данная статья справочника относится к полю данных, общая длина которого превышает наибольшее допустимое десятичное число (n), которое может содержаться в компоненте "длина поля данных" статьи справочника. В таком случае поле данных рассматривается как разделенное на несколько частей, длина каждой из которых, за исключением последней, равна n. Каждая часть имеет свою статью справочника, содержащую "метку", и "часть, определяемую при применении" поля данных, а также "позицию начального символа" той части, к которой относится эта статья справочника. Нулевое значение длины поля данных означает, что данная статья адресуется к той части поля данных, которая не является последней, а ее длина равна n; или 
3) количеством символов (включая разделитель поля) в последней части поля данных, описанного в п.2. 
В случаях, описанных в пп. 2 и 3, все статьи справочника, относящиеся к частям одного и того же поля данных, должны следовать друг за другом в той же последовательности, что и сами части поля данных;
позиция начального символа - десятичное число, определяющее позицию первого символа поля данных, идентифицируемого предшествующей меткой, относительно базового адреса данных (позиция начального символа первого поля данных, следующего непосредственно за справочником, равна нулю); 
часть, определяемая при применении (ЧОП) - предназначена для представления дополнительной информации, относящейся к полю данных, идентифицируемому этой статьей справочника. 

Поля данных должны заканчиваться разделителем поля. Имеются три типа полей данных, для которых фиксированы диапазоны значений меток: 
поле идентификатора записи  (метка 001) - поле данных, характеризующее запись и задаваемое организацией, создающей библиографическую запись (внимание! Поле идентификатора записи не содержит индикатора или идентификатора); 
резервные поля данных  (метки 002-009, 00А-00Z);
библиографические поля  (метки 010-999, 0АА-ZZZ). Каждое библиографическое поле состоит из индикатора (необязательно), одного или нескольких идентификаторов (необязательно), данных и разделителя поля. Наличие и длина индикатора или идентификаторов определяются соответствующими компонентами маркера записи (длина индикатора или длина идентификатора) и распространяются на все поля в записи.
Каждое поле в записи должно быть построено по одному из следующих вариантов: 
- данные (длина индикатора и идентификатора в маркере записи равна нулю); 
- идентификатор и данные (длина индикатора в маркере записи равна нулю, а идентификатора - больше либо равна 1); 
- индикатор и данные (длина идентификатора в маркере записи равна нулю, а длина индикатора - больше либо равна 1); 
- индикатор, идентификатор и данные (длина индикатора и идентификатора в маркере записи больше либо равна 1). 

Краткий перечень библиографических элементов данных биб. записи
Элементы блока идентификационных данных 
001 - Идентификатор подзаписи 
002 - Указатель подзаписей 
004 - Обозначение внешней базы данных 
005 - Обозначение заимствованной записи 010 - ISBN 
Индикатор: 0 - правильный ISBN 
1 - ошибочный ISBN 
Идентификатор: А - ISBN 
011 - ISSN 
Индикатор: 0 - правильный ISBN 
1 - ошибочный ISBN 
Идентификатор: А - ISBN 

Элементы блока кодирования информации
100 - Системные данные 
Индикатор: е 
Идентификатор: А - вид документа 
В - место издания (страна) 
С - дата составления записи 
Е - признак ограничения распространения 
М - дополнительные данные о виде
       патентного документа 
N - страна патентования 
101 - Язык документа 
Индикатор: е 
Идентификатор: А - язык основного текста 
D - язык вспомогательного текста 
Е - язык реферата (аннотации) 
102 - Физическая форма документа 
Индикатор: е 
Идентификатор: А - физическая форма документа 

Элементы блока библиографического описания
200 - Заглавие и сведения об авторстве 
Индикатор: е 
Идентификатор: А - основное заглавие 
Е - сведения, относящиеся к заглавию 
F - сведения об ответственности 
I - заглавие части и секции документа 
K - язык основного заглавия 
201 - Параллельное заглавие 
Индикатор: е 
Идентификатор: А - параллельное заглавие 
С - язык параллельного заглавия 
206 - Нумерация и дата сериального издания 
Индикатор: 0 - цифровая (только для подполей "А", "В" и "С") 
I - буквенно-цифровая (только для подполя "Е") 
Идентификатор: А - номер тома 
В - номер выпуска 
С - дата 
Е - нумерация 
210 - Выходные данные 
Индикатор: е 
Идентификатор: А - место издания (город) 
С - издательство 
D - дата издания 
E - место печати (город) 
M - владелец авторского права 

Элементы блока поискового образа документа 
600 - УДК 
Индикатор: е 
Идентификатор: А - индекс 
610 - МКИ 
Индикатор: е 
Идентификатор: А - индекс 
620 - Рубрикатор 
Индикатор: е 
Идентификатор: А - код рубрики 
N - наименование 
630 - Тезаурус 
Индикатор: е 
Идентификатор: А - наименование 
С - дескриптор 
Е - код дескриптора 
640 - Ключевое слово 
Индикатор: е 
Идентификатор: А - ключевое слово 
С - язык ключевого слова 
650 - Текст документа 
Индикатор: е 
Идентификатор: А - текст документа 
660 - Реферат (аннотация) 
Индикатор: е 
Идентификатор: А - реферат (аннотация) 
670 - Предметная рубрика 
Индикатор: е 
Идентификатор: В - предметная рубрика 

Элементы блока интеллектуальной ответственности
700 - Лицо с первичной интеллектуальной ответственностью 
Индикатор: е 
Идентификатор: А - индивидуальный автор 
В - место работы (наименование) 
С - место работы (город) 
D - место работы (страна) 
Е - другая форма имени 

Элементы блока по приобретению и хранению документа
905 - Хранение документа 
Индикатор: 0 - организация-хранитель документа 
9 - организация-хранитель перевода документа 
      (только для подполя "А" ) 
Идентификатор: А - организация-хранитель документа 
С - шифр хранения 
Е - страна хранения 

2.2. Основы XML
XML (Extensible Markup Language) - это язык разметки, описывающий целый класс объектов данных, называемых XML- документами. Этот язык используется в качестве средства для описания грамматики других языков и контроля  за правильностью составления документов. Т.е. сам по себе XML не содержит никаких тэгов, предназначенных для разметки, он просто определяет порядок их создания.
Для описания данных XML использует DTD (Document Type Definition - Определение типа документа) или схему документа. 
Cинтаксис XML 
Тело документа XML состоит из элементов разметки и непосредственно содержимого документа - данных. XML-тэги предназначены для определения элементов документа, их атрибутов и других конструкций языка. 
Любой XML- документ должен всегда начинаться с инструкции <?xml?>, внутри которой также можно задавать номер версии языка, номер кодовой страницы и другие параметры, необходимые программе-анализатору в процессе разбора документа.
Конструкции языка
Содержимое XML- документа представляет собой набор элементов, секций CDATA, директив анализатора, комментариев, спецсимволов, текстовых данных. Рассмотрим каждый из них подробней. 
Элементы данных
Элемент - это структурная единица XML- документа. Заключая слово rose в в тэги, мы определяем непустой элемент, называемый <flower>, содержимым которого является rose. В общем случае в качестве содержимого элементов могут выступать как просто какой-то текст, так и другие, вложенные, элементы документа, секции CDATA, инструкции по обработке, комментарии, - т.е. практически любые части XML- документа. 
Любой непустой элемент должен состоять из начального, конечного тэгов и данных, между ними заключенных: <flower> rose </flower>.
Атрибуты
Если при определении элементов необходимо задать какие-либо параметры, уточняющие его характеристики, то имеется возможность использовать атрибуты эдлемента. Атрибут - это пара "название" = "значение", которую надо задавать при определении элемента в начальном тэге. Пример: 
<color RGB="true">#ff08ff</color>
<color RGB="false">white</color>
Сущности и специальные символы
Для того, чтобы включить в документ символ, используемый для определения каких-либо конструкций языка (например, символ угловой скобки) и не вызвать при этом ошибок в процессе разбора такого документа, нужно использовать его специальный символьный либо числовой идентификатор. Например, &lt; , &gt; &quot; или &#036;(десятичная форма записи), &#x1a (шестнадцатеричная) и т.д. 
Если вы поместите внутрь XML-элемента символ "<", это вызовет ошибку, потому что парсер проинтерпретирует его как начало нового элемента. Поэтому писать вот так нельзя: 
<message>if salary < 1000 then</message>
Чтобы избежать ошибки парсера, нужно заменить символ "<" ссылкой на сущность вот так: 
<message>if salary &lt; 1000 then</message>
В XML есть пять изначально заданных сущностей: 
ссылка на сущность	символ	
&lt;	< - меньше, чем	
&gt;	> - больше, чем	
&amp;	& - амперсанд	
&apos;	` - апостроф	
&quot;	" - двойная кавычка	
Ссылки на сущности всегда начинаются с амперсанда "&" и заканчиваются точкой с запятой: ";". 
Обратите внимание: только символы "<" и "&" строго неприемлемы в XML. Апострофы, кавычки и символы "больше, чем" приемлемы, но лучше их все же заменять ссылками на сущности. 
Комментарии
Комментариями является любая область данных, заключенная между последовательностями символов 
<!--    -->
 Комментарии пропускаются анализатором и поэтому при разборе структуры документа в качестве значащей информации не рассматриваются. 
Директивы анализатора
Инструкции, предназначенные для анализаторов языка, описываются в XML документе при помощи специальных тэгов - <? и ?>;. Программа клиента использует эти инструкции для управления процессом разбора документа. Наиболее часто инструкции используются при определении типа документа (например, <? Xml version=”1.0”?>) или создании пространства имен. 
CDATA 
Чтобы задать область документа, которую при разборе анализатор будет рассматривать как простой текст, игнорируя любые инструкции и специальные символы, но, в отличии от комментариев, иметь возможность использовать их в приложении, необходимо использовать тэги <![CDATA] и ]]>. Внутри этого блока можно помещать любую информацию, которая может понадобится программе- клиенту для выполнения каких-либо действий (в область CDATA, можно помещать, например, инструкции JavaScript). Естественно, надо следить за тем, чтобы в области, ограниченной этими тэгами не было последовательности символов ]]. 
Правила создания XML-документа
1) В XML все элементы должны иметь закрывающий тэг 
В XML не разрешается опускать конечные тэги элементов.
В HTML некоторые элементы могут не иметь закрывающего тэга, например так: 
<p>Параграф 1
В XML все элементы обязательно должны иметь закрывающий тэг: 
<p>Параграф 1</p>
2) В тэгах XML учитывается регистр 
В отличие от HTML, в XML-тэгах учитывается регистр 
В XML тэг <Book> отличается от тэга <book>. 
Таким образом, начальные и конечные тэги должны писаться в одном регистре: 
<Book>Вот так неправильно</book>
<book>Вот так правильно</book>
3) Элементы XML должны быть правильно вложены друг в друга 
Неверное вложение элементов считается в XML неправильным 
В HTML некоторые элементы могут быть вложены друг в друга неправильно, например: 
<b><i>Этот текст пишется полужирным курсивом</b></i>
В XML все элементы должны быть правильно вложены друг в друга, например: 
<b><i>Этот текст пишется полужирным курсивом</i></b>
4) XML-документы должны иметь единственный корневой элемент 
Первый тэг XML-документа является корневым тэгом 
Все XML-документы должны иметь единственную пару тэгов, задающую корневой элемент. Все остальные элементы должны быть вложены в корневой элемент. 
Все элементы могут иметь под-элементы (дочерние элементы). Под-элементы должны быть правильно вложены внутри родительского элемента. 
<root>
  <child>
    <subchild>.....</subchild>
  </child>
</root>

5) Значения атрибутов всегда должны быть заключены в кавычки 
В XML не разрешается опускать кавычки вокруг значения атрибутов 
В XML элементы могут обладать атрибутами в парах имя атрибута/его значение, также, как HTML. Но в XML значения атрибутов всегда должны быть заключены в кавычки. 
<?xml version="1.0"?>
<message  date="21/02/02">
<theme>Тема сообщения</theme>
<body>Тело сообщения</body>
</message>
Атрибут date в элементе message должен быть заключен в кавычки. 
6) В XML пробелы сохраняются 
В XML пробелы в вашем документе не будут устраняться. Этим XML отличается от HTML. 
Если XML-документ не нарушает приведенные правила, то он называется формально-правильным и все анализаторы, предназначенные для разбора XML- документов, смогут работать с ним корректно. 
Однако кроме проверки на формальное соответствие грамматике языка, в документе могут присутствовать средства контроля над содержанием документа, за соблюдением правил, определяющих необходимые соотношений между элементами и формирующих структуру документа. 
Для того, чтобы обеспечить проверку корректности XML- документов, необходимо использовать анализаторы, производящие такую проверку и называемые верифицирующими. 
На сегодняшний день существует два способа контроля правильности XML- документа: DTD-определения(Document Type Definition) и схемы данных (Semantic Schema). Более подробно об использовании DTD и схемах мы поговорим в следующих разделах. В отличие от SGML, определение DTD- правил в XML не является необходимостью, и это обстоятельство позволяет нам создавать любые XML- документы, не ломая пока голову над весьма непростым синтаксисом DTD. 

DTD – описания
В XML-документах DTD определяет набор действительных элементов, идентифицирует элементы, которые могут находиться в других элементах, и определяет действительные атрибуты для каждого из них. 
Для того, чтобы использовать DTD в нашем документе, мы можем или описать его во внешнем файле и при описании DTD просто указать ссылку на этот файл или же непосредственно внутри самого документа выделить область, в которой определить нужные правила. В первом случае в документе указывается имя файла, содержащего DTD-описания: 
<?xml version="1.0" standalone="yes" ?>
<! DOCTYPE journal SYSTEM "journal.dtd">
...
Внутри же документа DTD- декларации включаются следующим образом: 
...
<! DOCTYPE journal [
<!ELEMENT journal (contacts, issues, authors)>
...
]>
...
В том случае, если используются одновременно внутренние и внешние описания, то программой-анализатором будут сначала рассматриваться внутренние, т.е. их приоритет выше. При проверке документа XML- процессор в первую очередь ищет DTD внутри документа. Если правила внутри документа не определены и не задан атрибут standalone ="yes" , то программа загрузит указанный внешний файл и правила, находящиеся в нем, будут считаны оттуда. Если же атрибут standalone имеет значение "yes", то использование внешних DTD описаний будет запрещено. 
Определение элемента 
Элемент в DTD определяется с помощью дескриптора !ELEMENT, в котором указывается название элемента и структура его содержимого. 
Например, для элемента <flower> можно определить следующее правило: 
<!ELEMENT flower  PCDATA>
Ключевое слово ELEMENT указывает, что данной инструкцией будет описываться элемент XML. Внутри этой инструкции задается название элемента (flower) и тип его содержимого. 
В определении элемента мы указываем сначала название элемента (flower), а затем его модель содержимого - определяем, какие другие элементы или типы данных могут встречаться внутри него. В данном случае содержимое элемента flower будет определяться при помощи специального маркера PCDATA (что означает parseable character data - любая информация, с которой может работать программа-анализатор). Существует еще две инструкции, определяющие тип содержимого: EMPTY,ANY. Первая указывает на то, что элемент должен быть пустым (например, <red/>), вторая - на то, что содержимое элемента специально не описывается. 
Последовательность дочерних для текущего элемента объектов задается в виде списка разделенных запятыми названий элементов. При этом для того, чтобы указать количество повторений включений этих элементов могут использоваться символы +,*, ? : 
•	"+" означает, что соответствующий элемент может встречаться один или более раз;
•	"?" означает, что может быть не более одного элемента, или же элемент может отсутствовать вообще;
•	"*" означает, что элемент может отсутствовать или появляться один или более раз.
<!ELEMENT issue (title, author+, table-of-contents?)>
В этом примере указывается, что внутри элемента <issue> должны быть определены элементы title, author и table-of-contents, причем элемент title является обязательным элементом и может встречаться лишь однажды, элемент author может встречаться несколько раз, а элемент table-of-contents является опциональным, т.е. может отсутствовать. В том случае, если существует несколько возможных вариантов содержимого определяемого элемента, их следует разделять при помощи символа "|" : 
<!ELEMENT flower (PCDATA | title )*>
Символ * в этом примере указывает на то, что определяемая последовательность внутренних элементов может быть повторена несколько раз или же совсем не использоваться. 
Определение атрибутов
Списки атрибутов элемента определяются с помощью ключевого слова !ATTLIST. Внутри него задаются названия атрибутов, типы их значений и дополнительные параметры. Например, для элемента <article> могут быть определены следующие атрибуты: 
<!ATTLIST article
id ID #REQUIRED
about CDATA #IMPLIED
type (actual | review | teach )  'actual' ''
>
В данном примере для элемента article определяются три атрибута: id, about и type, которые имеют типы ID (идентификатор), CDATA и список возможных значений соответственно. Всего существует шесть возможных типов значений атрибута: 
•	CDATA - содержимым документа могут быть любые символьные данные 
•	ID - определяет уникальный идентификатор элемента в документе 
•	IDREF( IDREFS )- указывает, что значением атрибута должно выступать название(или несколько таких названий, разделенных пробелами во втором случае) уникального идентификатора определенного в этом документе элемента 
•	ENTITY( ENTITIES) - значение атрибута должно быть названием(или списком названий, если используется ENTITIES) компонента (макроопределения), определенного в документе 
•	NMTOKEN (NMTOKENS) - содержимым элемента может быть только одно отдельное слово(т.е. этот параметр является ограниченным вариантом CDATA) 
•	Список допустимых значений - определяется список значений, которые может иметь данный атрибут. 
Также в определении атрибута можно использовать следующие параметры: 
•	#REQUIRED - определяет обязательный атрибут, который должен быть задан во всех элементах данного типа 
•	#IMPLIED - атрибут не является обязательным 
•	#FIXED "значение" - указывает, что атрибут должен иметь только указанное значение, однако само определение атрибута не является обязательным, но в процессе разбора его значение в любом случае будет передано программе-анализатору 
•	Значение - задает значение атрибута по умолчанию 
Определение сущностей
Сущность (entity) представляет собой определения, содержимое которых может быть повторно использовано в документе. В других языках программирования подобные элементы называются макроопределениями. Создаются DTD-сущности при помощи инструкции !ENTITY: 
<!ENTITY hello ' Мы рады приветствовать Вас!' >
Программа-анализатор, просматривая в первую очередь содержимое области DTD- определений, обработает эту инструкцию и при дальнейшем разборе документа будет использовать содержимое DTD-сущности в том месте, где будет встречаться его название. Т.е. теперь в документе мы можем использовать выражение &hello;, которое будет заменено на строчку "Мы рады приветствовать Вас" 
В общем случае, внутри DTD можно задать три типа сущностей: 
Внутренние сущности - предназначены для определения строковой константы, с их помощью можно организовывать ссылки на часто изменяемую информацию, делая документ более читабельным. Внутренние компоненты включаются в документ при помощи амперсанта & .
Внешние сущности - указывают на содержимое внешнего файла, причем этим содержимым могут быть как текстовые, так и двоичные данные. В первом случае в месте использования макроса будут вставлены текстовые строки, во втором - бинарные данные, которые анализатором не рассматриваются и используются внешними программами 
<!ENTITY logotype SYSTEM "/image.gif" NDATA GIF87A>
Макроопределения правил - макроопределения параметров могут использоваться только внутри области DTD и обозначаются специальным символом %, вставляемым перед названием макроса. При этом содержимое компонента будет помещено непосредственно в текст DTD- правила 

Пример описания документов в формате DocBook
Статья
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
         <article class="whitepaper" id="using -docbook" lang="pt-br">
<artheader>
        <title>Como-Fazer DocBook</title>
        <author>
          <firstname>Jorge</firstname>
          <othername>Luiz</othername>
          <surname>Godoy</surname>
          <othername>Filho</othername>
          <affiliation>
            <orgname>
          <ulink url="http://www.conectiva.com"> Conectiva S.A. 
          </ulink>
            </orgname>
            <orgdiv>Publishing Departmentt;/orgdiv>
            <address><email>godoy@conectiva.com</email></address>
          </affiliation>
        </author>
        <revhistory>
          <revision>
            <revnumber>1.0</revnumber>
            <date>27 de janeiro de 2000</date>
            <authorinitials>godoy</authorinitials>
            <revremark>Versão inicial.</revremark>
          </revision>
        </revhistory>
   <legalnotice>
     <para>This document can be freely translated and distributed.
            It's released under the LDP License.</para>
    </legalnotice>
    <keywordset>
          <keyword>SGML</keyword>
          <keyword>DocBook</keyword>
          <keyword>DTD</keyword>
          <keyword>Conectiva</keyword>
          <keyword>HOWTO</keyword>
        </keywordset>
    </artheader>

3. Порядок выполнения работы:
1)	Для заданного варианта файла документа в формате МЕКОФ поэлементно разобрать запись, внося параметры (тип поля, метка поля, ЧОП, индикатор, идентификатор адрес, длина и значение поля) элементов данных в таблицу;
2)	Определить (по косвенным признакам) вид документа;
3)	Создать XML-документ, используя элементы данных из построенной таблицы.
4)	Cоздать DTD для данного вида документов.
5)	Создать пример XML-документа в соответствии DTD.

Тема 9. Документирование процессов проектирования и разработки ИС

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

Задание;
1. В ходе практического занятия должны быть разработаны следующие документы:
–	поэтапный план работ;
–	технический проект.
Основой служит составленное ранее техническое задание. Уровень детализации документов – небольшой. Цель – уяснение назначения документа, его структуры и содержания, порядка составления.

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

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

Тема  10. Разработка комплекта эксплуатационной документации ИС

Цель работы: освоение на практике основных приемов составления ЭД.

Порядок выполнения:
1. Задание выполняется на примере каких-либо информационных систем, хорошо известных студентам. В качестве таких ИС могут выступать:
–	веб-браузер (Microsoft Internet Explorer, Opera, Mozilla Firefox);
–	веб-сайт (Яndex, Mail.ru, Rambler.ru и т.п.);
–	почтовый клиент (Microsoft Outlook, The Bat и т.п.);
–	персональная информационная система, установленная на сотовом телефоне студента;
–	другая распространенная информационная система.

2. Основой эксплуатационной документации служит руководство пользователя ИС. В нем должны присутствовать следующие разделы:
–	общие сведения об информационной системе;
–	базовые приемы работы;
–	базовые элементы пользовательского интерфейса;
–	общая структура пользовательского интерфейса;
–	описание основных функций информационной системы.

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