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

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

Выполняемая операция	Традиционные базы данных	Реляционные базы данных
Разработка приложений	Необходимо определить, какая информация требуется различным приложениям и создать ряд общих файлов.	Необходимо определить виды хранимых данных и взаимосвязи между ними
Реализация приложений	Поступающие данные записываются в основные файлы; в каждую информационную ячейку каждого основного файла записывается один элемент данных.	Различные виды данных записываются в таблицы данных, соответствующие этим видам. В результате каждый элемент информации хранится в одном единственном месте
Модификация приложений	Требуется пересмотр структуры базы данных с последующей перезаписью основных файлов, которые затронуты вносимыми изменениями, и с переработкой всех приложений, использующих эти файлы	Достаточно найти и модифицировать таблицу, в которой должно содержаться определение нового вида данных Сами данные хранятся в других таблицах, не затрагиваемых при подобных изменениях.
Внесение частичных изменений в данные	Необходимо прочитать каждый основной файл с начала до конца, модифицируя изменяемые ячейки данных и оставляя все остальные прочитанные ячейки без изменений.	В соответствующих таблицах достаточно выделить множество строк, в которые необходимо внести изменения, и произвести эти изменения с помощью одного SQL- оператора.

Итак, основные черты реляционных баз данных:

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

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

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

Международная Классификация Изобретений (МКИ) имеет иерархическую структуру (представленную на рис.1) и состоит из следующих отделов: 1 - Раздел, 2 - Класс, 3 - Подкласс, 4 - Группа, 5 - Подгруппа. Иерархическая структура классификации МКИ представлена на рис.31.

Рис. 31. Иерархическая структура классификации МКИ - как основа АИс патентного обеспечения КТП.

Логическая модель

Переход от функциональной модели к логической осуществляется с помощью реляционных методов, при этом иерархическая структура функциональной модели реализуется с использованием отношений один - ко -многим и рекурсивных рис. 27. Реализацией данной логической модели является совокупностью таблиц, объединенных в единый модуль - патентную информационную базу данных ( PIB - Patent Information dateBase).

Ядром логической модели является таблица PIB_MKI (МКИ), связывающая таблицы PIB_PART (Раздел), PIB_CLASS (Класс), PIB_SUBCLASS (Подкласс), PIB_GROUP (Группа), PIB_SUB-GROUP (Подгруппа) в единую структуру, определяющую реализацию Международной Классификации Изобретений (МКИ) винформационной системе патентного обеспечения технологического проектирования. Таблица PIB_MKI (МКИ) в свою очередь связана с таблицей PIB_PATENT (Патент), отвечающей за связь с таблицами PIB_GRATHDOC (Графические документы) и PIB_UDK (УДК).Таблица PIB_UDK (УДК) реализует Универсальную Десятичную Классификацию (УДК). Структура таблиц модуля PIB представлена в таблице1.

Таблица 1. Информационно-логическая Структура модуля Международной Классификации Изобретений.

Имя таблицы	Имя поля	Функц. Назначение
PIB_PART	PART_NNN	Уникальный идентификатор
	PART_INDEX	Индекс раздела в МКИ
	PART_TITLE	Название раздела
PIB_CLASS	CLASS_NNN	Уникальный идентификатор
	CLASS_INDEX	Индекс класса в МКИ
	CLASS_TITLE	Название класса
PIB_SUBCLASS	SUBCLASS_NNN	Уникальный идентификатор
	SUBCLASS_INDEX	Индекс подкласса в МКИ
	SUBCLASS_TITLE	Название подкласса
PIB_GROUP	GROUP_NNN	Уникальный идентификатор
	GROUP_INDEX	Индекс группы в МКИ
	GROUP_TITLE	Название группы
PIB_SUB-GROUP	SUB-GROUP_NNN	Уникальный идентификатор
	SUB-GROUP_INDEX	Индекс подгруппы в МКИ
	SUB-GROUP_TITLE	Название подгруппы
PIB_PATENT	PATENT_NNN	Уникальный идентификатор
	PATENT_INDEX	Патентный индекс в МКИ
	PATENT_TITLE	Название патента
	PATENT_AUTHOR	Авторы патента
	PATENT_NOTES	Примечания
PIB_UDK	UDK_NNN	Уникальный идентификатор
	UDK_INDEX	Патентный индекс в УДК
	UDK_NOTES	Примечания
PIB_GRATHDOC	GRATHDOC_NNN	Уникальный идентификатор
	GRATHDOC_FILE	Имя файла
PIB_MKI	MKI_NNN	Уникальный идентификатор

Рис 32. Логическая модель

Исследование архитектур программно-технологической реализации АИС

В настоящее время существует множество архитектур, служащих для разработки информационных систем, ядром которых является СУБД. Клиент в типичной конфигурации клиент/сервер - это автоматизированное рабочее место, использующее графический интерфейс (Graphical User Interface - GUI), обычно Microsoft Windows, Macintosh.

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

Рассмотрим варианты распределения функций СУБД в клиент/серверной системы. СУБД выполняет три основные функции:

1. доступ к данным;
2. предоставление данных;
3. бизнес - функции.

Сервер СУБД может быть реализован на различных платформах, под управлением операционных систем UNIX, NetWare, Windows NT, OS/2 и др.

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

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

Программные продукты Oracle охватывают все основные компоненты архитектуры клиент/сервер, показанной на рис. 29:

1)полнофункциональный высокопроизводительный сервер RDBMS (система управления реляционной базой данных), масштабируемый от портативных ЭВМ до мэйнфреймов;

1. средства для разработки и запуска клиентских приложений, поддерживающие несколько сред GUI;
2. программный компонент для организации связи между БД на различных ЭВМ, который обеспечивает эффективную и безопасную связь с помощью широкого набора сетевых протоколов.

Рис. 33. Взаимодействие основных компонентов в архитектуре Oracle.

Oracle использует память системы (как реальную, так и виртуальную) для выполнения пользовательских процессов и самого программного обеспечения СУБД, и для кэширования объектов данных. В простой конфигурации Oracle файлы базы данных, структуры памяти, фоновые и пользовательские процессы располагаются на одной машине без использования сети. Однако, намного чаще встречается конфигурация, когда БД расположена на машине-сервере, а инструментальные средства Oracle - на другой машине (например, РС с Microsoft Windows). При такой клиент/серверной конфигурации машины связываются посредством некоторого сетевого программного обеспечения, которое позволяет двум машинам поддерживать связь. Для организации взаимодействия клиент/сервер или сервер-сервер необходимо использовать программный продукт Oracle SQL*Net, который позволяет СУБД Oracle взаимодействовать с сетевым протоколом. SQL*Net и поддерживает большинство сетевых протоколов для локальных вычислительных сетей (таких как TCP/IP, IPX/SPX) и для мэйнфреймов (например, SNA). По существу, SQL*Net является промежуточной программной прослойкой между Oracle и сетевым ПО, обеспечивающей связь между клиентской машиной Oracle (на которой работает, например, SQL*Plus) и сервером базы данных или между серверами баз данных. Опции SQL*Net позволяют одной машине работать с одним сетевым протоколом, сообщаясь с другой машиной, работающей с другим протоколом.

Рис. 34. SQL*NET как средство обеспечения взаимодействия между СУБД и сетью.

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

Продолжение статьи