CC BY
45
Заключительная логика поиска (Find) имеет в качестве параметров номер блока (строки матрицы Bl) —переменная bloc и номер позиции в строке. Первый вызов — Find(1,1).
procedure Find(blocjnd:integer); {переменные глобальные} begin
if Result then begin if P<Pbetter then begin Pbetter: = P; Sbetter: = S; end; end
else if Bl[blocjnd] = 0 then exit else if Cross(Bl[blocjnd]) then begin Include(Bl[blocjnd]);
Find(bloc+1,1); Exclude(Bl[blocjnd]); end
else if R[bloc] then Find(bloc+1,1); Find(blocjnd+1); end; {Find}
Общая логика, метода решения задачи о наименьшем разбиении:
program R_min;
const MaxN = ...; type ... var ... procedure Init; {ввод и инициализация данных} begin
end;
procedure Print; {вывод результата} begin
end;
{процедуры и функции, рассмотренные ранее} {основная логика} begin Init; Blocs;
Find(1,1); Print; end.
Таким образом, разработаны элементы программного комплекса, реализующего алгоритмы синтеза последовательности этапов полиграфического производства с учетом многовариантного состава единиц технологического оборудования на основе комбинаторного подхода.
СПИСОК ЛИТЕРАТУРЫ
1. Миронова, Г.В. Организация полиграфического производства [Текст] / Г.В. Миронова [и др.].— М.: Изд-во МГУП, 2002.— 352 с.
2. Раскин, А.Н. Технология печатных процессов [Текст] / А.Н. Раскин [и др.].— М.: Книга, 1989.— 367 с.
3. Волкова, Л.А. Издательско-полиграфическая техника и технология [Текст] / Л.А. Волкова.— М.: Изд-во МГУП, 1999.— 143 с.
4. Акулич, И.Л. Математическое программирова-
ние в примерах и задачах [Текст] / И.Л. Акулич.— М.: Высш. шк., 1986.— 319 с.
5. Назаров, А.В. Нейросетевые алгоритмы прогнозирования и оптимизации систем [Текст] / А.В. Назаров, А.И. Лоскутов.— СПб.: Наука и Техника, 2003.— 384 с.
6. Page, E.W. Algorithm development for neural networks [Текст] / E.W. Page, G.A. Tagliarini // SPIE.— 1988.— Vol. 880.— P. 11-19.
УДК 303.732.4
Ю.А. Голуб, О.А. Матенёв
ПРОЕКТИРОВАНИЕ СТРУКТУРЫ БАЗЫ ДАННЫХ ДЛЯ МОНИТОРИНГА И ОЦЕНКИ ПРОЦЕССОВ НАУКОЕМКОГО КЛАСТЕРНОГО РАЗВИТИЯ: АНАЛИЗ ПОДХОДОВ И МЕТОДОВ
Важнейшая задача проектирования струк- точниками информации. В соответствии с ре-туры любой базы данных (БД) — обеспечение альной практикой источниками и потребителя-работы с самыми разнообразными типами и ис- ми информации служат не только подразделения
данного предприятия, головная контора холдинга или аппарат министерства, но и предприятия других отраслей (возможные поставщики и потребители, государственные регламентирующие органы и др.). Принцип глобализации бизнеса диктует: источники и потребители информации будут находиться в любой географической точке, где это окажется нужно.
Отсюда следуют стратегические для структуры БД и информационной системы (ИС) в целом решения. Объединение требований к динамике и разнообразию типов информационных потоков, обрабатываемых в ИС, с учетом роста их объемов и требований к разнообразию методов обработки позволяет дать следующую обобщенную характеристику технологий, формирующих структуру БД в составе ИС:
компонентная технология проектирования и перекомплектации предметноориентирован-ных операционных БД, допускающих работу пользователей через общие, в том числе для хранилища данных (ХД), интерфейсы;
расширенная технология хранилища данных, интегрирующая исторические форматированные данные, архивные текстовые документы, звуковые и видеоархивы, а также картографические данные и включающая средства оперативной аналитической обработки данных и необходимые виды «дружественных» интерфейсов, например гипертекстовый, геоинформсистем (ГИС) и др.;
открытость БД для включения в нее и получения из нее информации с использованием принципов глобальной информационной магистрали (ГИМ);
структура открытых систем (СОС), расширенная методами и средствами компонентного формирования: на верхнем уровне это откры-
тость компонентного проектирования БД и свободного обмена с источниками информации любых внешних систем, на нижнем уровне — технологическая открытость БД на основе стандартов переносимости, интероперабельности, масштабируемости и др.
Расширенная технология интегрального хранилища (ИХ) заставляет на новой основе ставить вопрос о разработке интегрированной совокупности интерфейсов пользователя, которая создавала бы естественные условия для работы с информацией и функциями вне зависимости от того, к какому классу хранимых данных разработчик вынужден отнести сегодня его (пользователя) информацию.
Исключение избыточности данных выдвигает требование однократного ввода данных в БД для решения разных задач и защиты от возникновения противоречий (нарушение логической целостности) при актуализации хранимых данных. Однако в условиях глобального информационного пространства и компонентного проектирования контекст этих требований должен быть пересмотрен. Несомненно, в операционных БД рационально планировать «острова» нормализованных и в классическом смысле безызбыточных кластеров отношений или объектов. Эти «острова» чаще всего и будут давно известными предметными БД. Вместе с тем объединение исторических данных из ХД, БД ГИС-систем, архивов текстовых документов, потоков информации, получаемых по информационной магистрали (ИМ) и др., в общей постановке проектирования корпоративной БД приводит к отказу от повсеместного и всеобязательного принципа исключения избыточности: проектирование корпоративной БД на уровне логической схемы и на концептуальном уровне не
Рис. 1. Основные подходы к проектированию БД
опирается как на глобальный критерий на требование и процедуры исключения избыточности в данных.
Новая ситуация, включая существенный и заранее нерегламентированный поток информации из ИМ в корпоративную БД, потребует разработки или увеличения возможностей «процедур отождествления» экземпляров информационных структур, т. е. определения того, что эти экземпляры описывают один и тот же предмет реального мира.
Консервация проблем. Сам характер дисциплины проектирования, предусмотренный каскадной схемой, методами структурного проектирования, иерархическими подходами и структурами, подталкивает сейчас проектировщиков фиксировать достаточно жестко определенные модели предметной области (ПрО). Должна быть изменена CASE-технология проектирования БД таким образом, чтобы исключить консервацию существующих проблем предприятий в жестких, «цельноинтегрированных» структурах БД. Для этого может потребоваться изменение не только технологии, но и инструментов проектирования. Предполагаемые подходы:
возможность фиксировать описания атрибутов, сущностей, связей, функций и т. д. с любой степенью неполноты, производить описания на уровне недетализированных, предметно связанных совокупностей информационных структур («кластеры сущностей»);
проектирование или реконструкция моделей компонентов ИС и БД, их интеграция в общем понятийном пространстве;
проектирование упорядоченной последовательности состояний корпоративной БД как последовательности совокупностей эксплуатируемых предметных баз данных, включающих наследованные БД, структурно предопределенные БД «покупных» функциональных компонентов, спроектированные специально для данного предприятия БД и причем две последние категории постепенно заменяют наследованные, а затем и параллельно заменяют друг друга в процессе развития ИС;
открытость репозитория CASE-системы, словаря СУБД и системы 4GL, позволяющая надстраивать метаобъекты и механизмы требуемыми тезаурусными и глубинными семантиче-
скими отношениями между элементами, а также производить двухсторонний обмен метаинфор-мацией с другими системами 4GL и CASE, соединять модели разных компонентов в одну с использованием и сохранением всех необходимых семантических отношений.
Компонентная открытость и смысловая инте-роперабельность. Компонентный подход в разработке ИС требует компонентного проектирования БД. Замена некоторой функциональной компоненты ИС на подобную, но спроектированную другим разработчиком, потребует структурной замены некоторой части корпоративной БД. Такая замена должна поддерживаться как постоянный процесс перепроектирования БД. При замене компоненты БД интерфейсы имеющихся приложений и их пользователей должны получать точно ту же в смысловом отношении информацию, что и ранее.
Реальное компонентное проектирование БД может основываться на формировании и использовании общей для комплексируемых компонент понятийной модели и поддержании соответствий между моделями компонент БД (а также связанных с ними приложений) и общей понятийной моделью. В последнее время развиваются программные реализации полных формальных систем, обычно основанных на объектном подходе, которые могут приближаться к инструментальному решению этой задачи. [1]
Понятийные модели и последующие проектные работы. На последующих этапах проектирования собственно БД понятийную модель продолжают использовать, имея в виду различные цели, например:
разработку совокупности разных предметных информационных моделей с выделением общих информационных сущностей;
разработку функциональных моделей разных типов;
разработку семантически богатых средств поддержки пользователя и др.
На этапе проектирования необходимо предусмотреть все возможные действия, которые могут возникнуть на различных стадиях жизненного цикла БД.
На этапе анализа концептуальных требований и информационных потребностей решаются следующие задачи:
анализ требований пользователей к БД (концептуальные требования);
выявление имеющихся задач по обработке информации, которая должна быть представлена в БД (анализ приложений);
выявление перспективных задач (перспективные приложения);
документирование результатов анализа. Требования пользователей к разрабатываемой БД представляют собой список запросов с указанием их интенсивности и объемов данных. Эти сведения разработчики получают в диалоге с будущими пользователями БД. Здесь же выясняют требования к вводу, обновлению и корректировке информации. Требования пользователей уточняют и дополняют при анализе имеющихся и перспективных приложений.
Широко известные методы проектирования баз данных появились в процессе разработки все более сложных ИС, которые должны были рассматривать потребности не одного пользователя, но больших групп и коллективов. Одна такая интегрированная БД создавалась для решения многих задач, каждая из которых использовала только свою часть данных, обычно пересекающуюся с частями, используемыми в других задачах. Поэтому главнейшими методами проектирования стали методы исключения избыточности в данных. Эти методы связывались с другими средствами обеспечения логической целостности данных.
Было сформулировано принципиальное требование отделения программ от интегрированных данных. Этот принцип, направленный на отчуждение данных в качестве ресурса предприятия, важен также тем, что консервативные по характеру данные отделялись от прикладных программ, которые могли часто подвергаться изменениям.
Другой важной проблемой проектирования БД стало обеспечение нужных эксплуатационных параметров (объем внешней памяти, время выполнения различных операций). Известны и другие требования. Например, информация не должна потеряться не только из-за отказов оборудования, но и вследствие ошибки пользователя. Это отличается от того положения, при котором тот, кто решает некую задачу, сам и отвечает за сохранность данных для нее.
Сформировалось понимание интегрированной БД как общего информационного ресурса
предприятия. Хранимые данные стали аналогичны большому компьютеру, который одновременно используется многими пользователями с различными целями и должен быть все время работоспособен.
Классическая методология проектирования БД — это мощное и красивое течение со своей философией, способами восприятия реальности и способами существования в ней. В этом течении возникла своя прикладная математика, свое понятие «Мира», «Предметной Области» и их моделей. В отношении проектирования БД осознаны и интегрированы в стройные схемы методы выполнения таких проектных этапов:
сбора сведений о ПрО (анализ потребностей и описание ПрО с использованием так называемых «процессного», или up — «usage perspective», подхода и «непроцессного», или isp — «information structure perspective», подхода);
выбора языка представления так называемой «семантической» модели для фиксации сведений о ПрО, их последующего анализа и синтеза модели БД;
анализа собранных сведений о ПрО (классификация, формализация и интеграция структурных элементов описания ПрО; формализация как структурных, так и процедурных ограничений целостности элементов в будущей модели ПрО; определение динамики экземпляров объектов ПрО);
синтеза концептуальной модели БД (проектирование целостной концептуальной схемы БД на выбранном языке семантического моделирования);
выбора конкретной модели данных и СУБД для реализации БД; проектирования логической схемы БД для выбранной СУБД («проектирование реализации»);
разработки физической структуры БД («физическая», или «внутренняя», схема, она же — «схема размещения»), включая размещение БД по узлам;
разработки технологии и процедур начального создания и заполнения БД;
разработки технологии и процедур сопровождения БД, а также универсальных программ доступа к БД и соответствующих интерфейсов пользователей;
информационного обеспечения разработки конкретных программ обработки данных (ме-
таинформация, данные контрольных примеров и др.);
получения обратной связи от разработчиков прикладных программ и пользователей ИС о полноте и эффективности организации БД;
тестирования БД, ее развития и улучшения (настройка) ее структуры.
Требования к базе данных
Чтобы обеспечить максимальные возможности для каждого пользователя, т. е. поддержку выполнения всех бизнес-функций тем пользователем, который и получает конечный результат, со стороны ИС, БД и СУБД требуются [2, 4]:
средства доступа ко всем необходимым данным с использованием распределенных БД, средства репликаций данных, управления событиями в данных и процессах обработки транзакций;
использование архитектуры и разнообразных программных средств — хранилища данных, оперативной аналитической обработки данных (OLAP), быстрой разработки приложений (RAD) к «ИС руководителя» (EIS), поддержки принятия решений (DSS) на основе хранилища данных, OLAP и RAD/EIS;
применение средств DSS на основе анализа БД прецедентов, а также методов логического вывода, нейронных сетей и нейрокомпьютеров и др.;
единый интерфейс пользователя для работы с разными компонентами данных и приложений, использование в этом интерфейсе средств, повышающих простоту поиска информации и обращения к конкретным прикладным функциям (например, функции геоинформсистем, гипертекстовые, естественного языка, речевого ввода).
Разработка концепции и структуры корпоративной базы данных для новой ИС, реализация структуры БД предполагают снятие (существенное уменьшение) ограничений на ее развитие, в том числе при смене функций или функциональных компонентов обработки информации, за счет:
применения методов компонентного проектирования предметных БД как для операционных, так и для исторических БД, хранилищ данных, архивов документов, геоинформационных и иных данных;
разработки процедур компонентного изменения корпоративной БД при изменении бизнес-процедур, видов деятельности, применяемых приложений и географического размещения предприятия;
постоянной актуализации понятийной модели деятельности предприятия для учета новых понятий, возникающих при замене прикладных компонент на функционально сходные и при изменении видов деятельности предприятия, и построения на этой основе новых интерфейсов между компонентами ИС;
динамического администрирования и управления фрагментами распределенной корпоративной БД в случае изменения частоты их использования, при модификации структуры этих баз и изменении их размещения.
Одним из главных методов проектирования считается метод «организации запросов». Ему уделяется особое место в каждом проекте структуры БД, так как именно на основе этого метода создается основной интерфейс пользователя (ответ пользователю на запросы).
Рис. 2 иллюстрирует взаимодействие пользователя, СУБД и операционной системы (ОС) при обработке запроса на получение данных. Цифрами помечена последовательность взаимодействий [3]:
1 — пользователь посылает СУБД запрос на получение данных из БД.
2 — анализ прав пользователя и внешней модели данных, соответствующей данному пользователю, подтверждает или запрещает его доступ к запрошенным данным.
3 — в случае запрета на доступ к данным СУБД сообщает пользователю об этом (стрелка 12) и прекращает дальнейший процесс обработки данных; в противном случае СУБД определяет часть концептуальной модели, которая затрагивается запросом пользователя.
4 — СУБД получает информацию о запрошенной части концептуальной модели.
5 — СУБД запрашивает информацию о местоположении данных на физическом уровне (файлы или физические адреса).
6 — в СУБД возвращается информация о местоположении данных в терминах операционной системы.
7 — СУБД просит операционную систему предоставить необходимые данные, используя средства операционной системы.
Рис. 2. Схема прохождения запроса к БД
8 — операционная система осуществляет перекачку информации из устройств хранения и пересылает ее в системный буфер.
9 — операционная система оповещает СУБД об окончании пересылки.
10 — СУБД выбирает из доставленной информации, находящейся в системном буфере, только то, что нужно пользователю, и пересылает эти данные в рабочую область пользователя.
Проектирование и реализация проекта базы данных — достаточно длительный процесс, в течение которого могут возникнуть потребность в корректировке проекта, а также затруднения в выполнении некоторых принятых проектных решений.
Поэтому в проектировании БД существенное значение имеет создание многомерной структуры.
При проектировании БД мониторинга показателей особое место занимает распределение накопленной информации по ним в структуре БД.
Предлагаемая структура распределения показателей в процессе проектирования БД позволяет отслеживать возникающие трудности и принимать необходимые решения на этапах разработки и реализации проекта.
Представляется, что в базе данных особое место занимает проверка того, как соотносятся входящие показатели, характеризующие процессы в кластере, и непосредственно эти процессы (рис. 3).
На основании анализа задач экономического мониторинга построена модель БД, позволяющая хранить данные мониторинга в различных разрезах.
Рис. 3. Структура распределения показателей
Рис. 4. Логическая модель базы данных
Данные разделяются:
по экономическим показателям (величинам); по объектам мониторинга; по организации — источнику данных. На рис. 4 приведена схема логической модели БД «Экономический мониторинг».
Полученная логическая модель данных ложится в основу формирования структуры БД и общего проекта.
Использование типовых методов и подходов проектирования позволяет наладить процесс
создания и разработки базы данных, избежать логических ошибок в структуре, выбрать оптимальную среду разработки и заранее определить набор параметров и функций самой базы данных.
Таким образом, проведен анализ основных подходов и методов проектирования баз данных, даны краткие характеристики, а также рассмотрен пример разработки структуры базы данных с использованием выделенных методов и подходов.
СПИСОК ЛИТЕРАТУРЫ
1. Зиндер, Е.З. Критерии выбора современной СУБД как объекта инвестиций для развития предприятия [Текст] / Е.З. Зиндер // СУБД.— 1995. № 1.
2. Денисов, А.А. Основы теории систем и системного анализа [Текст]: Учебник для студентов вузов, обучающихся по специальности «Системный анализ и управление» [Текст] / А.А. Денисов.— Изд-е 2-е,
перераб. и доп.— СПб: Изд-во СПбГТУ, 2001.
3. Новиков Ю. Компьютеры, сети, Интернет, Энциклопедия [Текст] / Ю. Новиков, Д. Новиков, А. Черепанов, В. Чуркин.— СПб.: Питер, 2002.— 928 с.: ил.
4. Юрьев, В.Н. Информационные системы в экономике [Текст]: Учебник / В.Н. Юрьев, В.Н. Волкова.— СПб.: Изд-во Политехн. ун-та, 2006.— 538 с.
