Содержание к диссертации
Введение
1 Интеграция реляционных баз данных на основе репозитория схем 8
1.1 Анализ вариантов интеграции репозиториев в современных СУБД 8
1.2 Формирование требований к оптимальному репозиторию 29
1.3 Постановка задачи построения оптимального репозитория 31
1.4 Выводы 33
2 Построение и исследование реляционного репозитория схем баз данных 35
2.1 Построение схем реляционного репозитория 35
2.2 Классификация схем репозитория 39
2.3 Методика оптимизации схемы репозитория на этапе эксплуатации 43
2.4 Операции управления репозиторием 47
2.5 Выводы 51
3 Формирование подсистемы интеграции реляционных баз данных на основе оптимального репозитория схем 53
3.1 Проектирование среды управления оптимальным репозиторием 53
3.2 Проектирование и реализация универсального интерфейса пользователя генератора отчётов к репозиторию баз данных 56
3.3 Реализация редактора графического представления схем реляционных баз данных репозитория схем 76
3.4 Выводы 107
4 Применение подсистемы интеграции реляционных баз данных на основе оптимального репозитория схем 109
4.1 Реализация подсистемы интеграции в системе управления учебным процессом СПбГПУ 109
4.2 Реализация подсистемы интеграции в электронной системе мониторинга технологических компетенцией 115
4.3 Выводы 120
Заключение 121
Список литературы
- Формирование требований к оптимальному репозиторию
- Классификация схем репозитория
- Проектирование и реализация универсального интерфейса пользователя генератора отчётов к репозиторию баз данных
- Реализация подсистемы интеграции в электронной системе мониторинга технологических компетенцией
Введение к работе
Актуальность темы диссертационной работы обусловлена значимостью проблемы минимизации объёмов метаданных и времени исполнения алгоритмов интеграции независимых реляционных баз данных.
Под интеграцией подразумевается решение комплекса задач по объединению наборов данных из не связанных между собой реляционных баз. В приложении к реляционным базам данных под метаданными понимается набор имён атрибутов схем. Оптимальное управление интеграцией данных обеспечивает минимизацию объёмов служебных данных и времени формирования интегрирующих запросов к объединённым данным. На практике реализация алгоритмов управления метаданными с заранее известными временами исполнения позволяет применять их в высоконагруженных системах интеграции данных информационно-управляющих систем.
Вопросы интеграции реляционных баз данных рассматриваются в сфере управления базами данных, интеллектуального анализа и аналитической обработки данных, интеграции разнородных данных и нашли практическое применение в программных пакетах, обеспечивающих федеральную интеграцию данных и формирование открытых репозиториев метаданных. Разработками в данной области занимаются специалисты: Л. А. Калиниченко, М.Ш. Цаленко, Ю.Г. Карпов, С. А. Ступников, М. Р. Когаловский, С. Д. Кузнецов, Б. А. Новиков, Д. Мейер, М. Франклин, Г. Гарсия Молина, Д. Ульман, а также ведущие IT компании: Microsoft, Oracle, IBM.
В настоящее время основным способом интеграции данных из реляционных баз является управление данными на основе метаданных. К метаданным относятся имена БД, отношений, атрибутов, описания функциональных, в том числе и многозначных, зависимостей, которые, в совокупности, составляют схему БД.
К трём главным проблемам интеграции данных на основе репозиториев можно отнести многообразие внутренних представлений репозиториев в различных РСУБД, распространение репозитория на одну РСУБД и отсутствие возможностей достоверной оценки времени функционирования алгоритмов управления репозиторием. Выявленные ограничения приводят к высокой трудоёмкости управления крупными интеграционными проектами на основе реляционных СУБД различных производителей в условиях больших объёмов интегрируемых данных. Решением данной проблемы является применение подсистемы интеграции реляционных баз данных на основе независимого, оптимизируемого на этапе эксплуатации реляционного репозитория с полным набором операторов управления схемами независимых баз данных.
Целью работы является построение оптимального репозитория метаданных на основе алгоритмов управления схемами интегрируемых баз данных с прогнозируемым временем отклика на произвольном наборе атрибутов и отношений интегрируемых баз данных.
Для достижения цели в диссертационной работе поставлены и решены следующие задачи:
предложена классификация схем репозитория на основе анализа числа реляционных отношений и функциональных зависимостей;
разработана методика оптимизации репозитория данных на этапе эксплуатации с гарантированными оценками времени выполнения операций;
разработан функционально полный набор операций, обеспечивающий согласованную последовательность преобразований схемы репозитория;
разработаны алгоритмы управления схемами репозитория, обеспечивающие адаптацию его структуры к изменяющимся наборам структур интегрируемых данных;
разработана архитектура и реализована подсистема интеграции реляционных баз данных на основе реляционного репозитория и операторов управления схемами.
Объектом исследования являются схемы реляционных баз данных, схемы репозитория и алгоритмы управления данными в нём.
Предметом исследования является организация изменения схемы репозитория на этапе эксплуатации и алгоритмы управления атрибутами и отношениями в объединённой базе данных.
Основные методы исследования. В качестве методов исследования применялись методы теории оптимизации, использовался аппарат теории множеств, общей и реляционной алгебр, методы анализа алгоритмов.
Результаты, выносимые на защиту, и их научная новизна. Предлагаемая диссертация содержит следующие результаты:
разработана методика оптимизации реляционного репозитория метаданных отличающихся от известных совместным использованием 2 критериев оптимизации, что позволяет получить оптимальный репозиторий, в котором минимизированы объём данных и время доступа;
разработан полнофункциональный набор алгоритмов управления схемами репозитория позволяющий обрабатывать любую из существующих реализаций схем репозитория;
показано, что для произвольной схемы репозитория объём и время обработки данных линейно зависит от числа атрибутов объединяемых баз, что позволяет эффективно управлять репозиторием с произвольным набором независимых баз данных.
Теоретическая значимость работы заключается в разработке методики построения оптимального репозитория с целью интеграции реляционных баз данных на основе полнофункционального набора операций над схемами средствами реляционной алгебры. Разработанная методика управления схемами позволяет эффективно интегрировать независимые базы данных.
Практическая значимость работы состоит в разработке подсистемы интеграции, состоящей из инструментальных средств анализа схем интегрируемых баз данных, компоненты реконфигурации репозитория, графического редактора доопределения связей и универсального интерфейса доступа к данным средствами системы интеграции.
Предложенный подход позволяет сохранить неизменными данные, операторы и схемы интегрируемых БД, что позволяет реализовать операторы управления схемами независимо от интегрируемых БД и получать подсистемы интеграции с заранее известными временами отклика. В ходе практической реализации получены следующие результаты:
реализация методики обеспечивает синтез репозитория независимых баз данных для заданного времени доступа к данным в репо-зитории, что позволяет проектировать систему с известными эксплуатационными характеристиками;
разработанные алгоритмы позволяют повысить производительность подсистемы интеграции баз данных при неизменных требованиях к аппаратной компоненте;
реализованный универсальный пользовательский интерфейс, обеспечивает единую технологию доступа к независимым реляционным базам данных.
Разработанные инструментальные средства нашли применение в качестве составных частей системы интеграции независимых реляционных баз данных.
Реализация результатов работы. Разработанная информационная система внедрена в качестве подсистемы интеграции реляционных баз данных в информационной системе управления учебным процессом Санкт-Петербургского государственного политехнического университета и электронной системе мониторинга технологических компетенцией предприятий машиностроительного комплекса Северо-Западного региона.
Апробация работы. Научные результаты и основные положения работы докладывались и обсуждались на конференциях: Международной научно-методической конференции «Высокие интеллектуальные технологии и интеграция знаний в образовании и науке» (Санкт-Петербург 2005), международной научно-методической конференции «Высокие интеллектуальные технологии и инновации в образовании и науке» (Санкт-
Петербург, 2006), международной научно-практической конференции «Высокие интеллектуальные технологии в образовании и науке» (Санкт-Петербург, 2010).
Публикации. По теме диссертации автором опубликовано 14 работ, объёмом 5,81 п.л. в том числе в изданиях, рекомендованных ВАК - 2 работы, объёмом 1,05 п.л.
Личный вклад автора. Все основные результаты работы диссертации получены автором самостоятельно.
Структура и объём диссертационной работы. Диссертация состоит из введения четырёх глав и заключения, изложена на 132 страницах, включая перечень литературы из 70 наименований, 60 рисунков и 4 таблицы. К диссертации добавлено приложение на 4 листах, содержащее схемы работы предложенных и реализованных в диссертации алгоритмов.
Формирование требований к оптимальному репозиторию
Полная определённость отображения ЯЛ в Wlj. Определив a: Schj — Schi как отображение схемы баз данных fflj в схемы базы данных ЯЛ , а ф: Bj - Bt - отображение состояний баз данных ЯЛ.,- в состояния баз данных ЯЛ;, зададим соотношение функций а, ф, Msu MSJ следующей диаграммой отображения схем:
Для обеспечения полной определённости отображения необходимо, чтобы приведённая диаграмма была коммутативна, (Msi о а = ф о MSJ) и модели ЯЛ.,, ЯЛ; используют структурно подобные типы данных: если функция Id - Vj модели ЯЛ.,- выражена, как некоторое состояние Bj модели Sj определяется множеством типов данных VJ(SJ) = {vpVp ... ,Vj}, а состояние Д модели ЯЛ; — множеством типов данных Vi(si) = {v},vf, ... ,v}. Тогда простейшее отображение ф при котором Vj и Vj сконструированы так, что к = т и v j отображается в v\ при q = 1,2, ..., к).
В общем случае правильное отображение осуществляется не на первичных типах данных моделей ЯЛ,,- и ЯЯг-, а на множестве Cj(Vj) = {c),Cj, ... ,Cj}, с } С Vj, р = 1,2, ... ,г производных типов данных, которое является пересекающимся подмножествами исходного множества Vj, путём построения разбиения V{\ СІ(Ц) = {c},cf, ... ,с[}, с\ С V{. Причём составные типы данных с? выбираются так, чтобы в их состав были включены типы данных, между которыми в Sj заданы логические зависимости, определённые в модели ЯЛ , и чтобы отображение с? можно было отобразить в с\ без потери существенных данных. Тогда каждому компоненту Bj ставиться в соответствие совокупность Cj (Vj {SJ)), которая посредством ф отображается в совокупность С (Ц, (SJ)) ГДЄ Sj = cr{Sj). Критерию полной определённости отображения соответствует 3Kj и ШІ соответствует инъективное отображение ф, ставящее в соответствие состояниям базы данных Шj состояния базы данных 97tj, однако, среди состояний модели ШІ найдутся такие, у которых не окажется прообраза Ш , что недопустимо. Следовательно ф должна быть биекцией между множествами состояний 9Jtj и Ші: а диаграмма отображения коммутативна. Перечисленные свойства ф и о означают что: произвольная схема базы данных Ш отображаема в схему базы данных ШІ, произвольное состояние базы данных Ш интерпретируемо средствами ЯМД базы данных ШІ.
Интерпретируемость операторов ЯМД Ш{ при отображении Ш в ШІ. Основная цель отображения Ш в 9Я; состоит в реализации произвольной программы на ЯМД ШІ, посредством программы на ЯМД Ш . В силу различий в семантике операторов ШІ и Шj, каждому о є Oi ставиться в соответствие процедура pj = /?(OJ). Тогда, считается, что ip сохраняет операторы если: для любого оператора ОІ Є Oi процедура Pj — ip (ОІ) такова, что, если исходные состояния баз данных bt Є Д и bj Є Bj в которых выполняется ОІ и pj, связаны зависимостью 6, = ф(Ь ) то произведённые о действия переводят bi в состояние Ь {, а действия pj переводят bj в состояние bj, причём Ь { = ф (bj). При этом оператор о и композиция операторов pj называются эквивалентными относительно отображения ф. Определение 1.2 Набор операторов ОІ ЯМД Ш называется функционально полным, если для любого состояния b t Є Д произвольной базы данных со схемой Si можно задать последовательность операторов ЯМД progi, переводящую базу данных в произвольное состояние Ь" Є Bit удовлетворяющее схеме Sj. Воспроизводимость действий над базой данных модели ШІ В базе данных модели Ш . Любое изменение базы данных в модели Ш , выполняемое некоторым оператором ЯМД progj так, что воспроизводимо средствами ШІ, причём функционально полный набор операторов и свойство воспроизводимости связано следующим предположением:
Предложение 1.1 Набор операторов ОІ ЯМД Шj называется функционально полным, если для любого состояния ЬРГІГПЄІ Є ВІ произвольной базы данных со схемой Si можно задать последовательность операторов ЯМД progi, переводящую базу данных в произвольное состояние b /eBi, удовлетворяющее схеме Sj. Расширение модели 9Я и построение концептуальной модели 9ЯС. Однако, расширение непосредственное затруднено, ввиду того, что семантика 9Я; должна быть настолько богатой, чтобы чтобы ее средствами можно было выразить произвольные логические зависимости данных, присущих произвольным схемам из модели данных SXtj, в силу того, что будучи биекцией ф, отображение Msioa получение пространства состояний Wlt эквивалентного ZUlj. Расширение числа внутренних моделей представления схем баз данных fflk выдвигает требование однозначного отображения пространства состояний на Msi о ак,
Свойство отображения /?, требует сохранения инвариантного отображения логических зависимостей из DJlj d 9Jlj- Тогда при увеличении числа моделей внутреннего представления данных DJlj для поддержания функционально полного набора операторов модели JDOTj появляются новые требования к семантике операторов модели
Увеличение числа новых внутренних моделей Шік, ШЦ, 9Яіт приводит к последовательному построению новых расширений , в состав которых входит и исходная модель-ядро 9Jtj. такой процесс называется процессом синтеза концептуальной модели fflc из расширений, которое состоит из двух этапов: построения расширения Ш модели Ш{, построения отображения fflj в ЧЖ .
Схема построения концептуальной модели 9ЯС из средств модели ядра и средств всех его расширений приведена на рисунке 2. Расширение Шц модели Mi Расширение Шц, модели Ш{ Расширение Шц модели ШІ Расширение Ж{т модем ЩІ Модель-ядра Ші Рисунок 2. Схема расширения модели SDtj до интерпретации различных внутренних моделей Способ расширения метамодели ШІ ДО 9% основан на построении выражении языковыми средствами в терминах ШІ логических зависимостей данных, определённых на модели Wlj, что ведёт к появлению новой семантики операторов О . Выражение этих логических зависимостей вводится аксиоматически и тогда расширение 9Лг до ЯЯу должно включать в себя совокупность схем аксиом у, сопоставленными с различными классами типов данных из 9Я,- и выражающих некоторые зависимости из fflt. На основе схемы аксиом у и конкретной схемы Sj Є Bj строятся конкретные аксиомы iiij, отражающие зависимости в конкретной базе данных, интерпретируемой средствами
Существует два способа определения семантики операторов ЯМД ЭЛу-: либо при помощи заданного наборам аксиом у, которые определяют семантику ЯМД и логические зависимости в схеме 9Я7-, либо процедурно. Во втором случае с каждым первичным типом данных в ЯЛ связывается совокупность процедур, изображаемых средствами ЯМД из Wli, каждая из которых определяет семантику соответствующего оператора ЯМД ЯЛу. Аксиоматический подход к построению модели определяет декларативный характер описания согласования, что эквивалентно передаче пользователю аксиом iiij.
Классификация схем репозитория
Для проведения эксперимента разработана и написана программа на языке программирования PERL, которая генерирует набор текстовых команд на языке SQL, предназначенных для создания и заполнения баз данных: по 56 вариантов заполнения репозитория внешними схемами баз данных на каждую из 5 типовых схем самого репозитория. Полученный на выходе программы текстовый файл загружается в СУБД MySQL посредством ее внутренних команд. Пользуясь стандартными средствами ОС WindowsXP, собрана информация о занимаемом месте на жёстком диске каждой из баз данных. Основываясь на полученных данных, построены графики: зависимости объёма, хранимой в репозиториях информации, от количества таблиц в схемах внешних баз данных при фиксированном количестве полей в таблицах; зависимости объёма, хранимой в репозиториях информации, от количества таблиц и количества полей в схемах внешних баз данных для каждого исследуемого репозитория в отдельности. axiom_2_step
Алгоритм построения наборов схем репозитория Графики демонстрируют линейную зависимость объёма данных от типа репозитория. В поставленной задаче при небольшом количестве параметров и комбинаторной сложности выделим вручную типичные варианты схем, основываясь на сочетаниях атрибутов с точностью вплоть до их перестановок.
Количество атрибутов отношения определяет количество таких схем, в нашем случае пять атрибутов определяют пятёрку типичных схем, представленных на рисунках 7-11.
Схема репозитория № Скоїла иия таблииы Ключ (server id) Адрес сервера имя таблицы Ключ (schema id) Имя схемы Вторичный ключ имя таблицы Ключ (table id) Имя таблицы Вторичный ключ имя таблицы имя таблицы Ключ (attribute id) Имя аттрибута Вторичный ключ Ключ (link id) Атрибут_2 Рисунок 8. Схема репозитория №2
При проведении эксперимента будем ориентироваться на репозитории, создаваемые для клиент-серверных приложений, решающих большие и средние задачи.
Следует подобрать такие схемы внешних баз данных, которыми будет покрыта вся область схем используемых на данный момент баз данных, что практически невозможно, так как схемы внешних баз данных произвольны и на данный момент отсутствует полная статистика.
Введем абстрактную модель схемы внешней базы данных, определяющуюся тремя параметрами: количеством таблиц, количеством полей в таблице, коэффициентом связности таблиц в базе данных. Схема З имя таблицы Ключ (schema id) Имя схемы Имя сервера иия таблицы Имя таблицы Имя аттрибута 1 Имя аттрибута 2 Вторичный ключ Схема имя таблицы Ключ (schema id) Имя схемыИмя сервера имя таблицы Ключ (attribute id) Имя таблицы Имя аттрибута Вторичный ключ имя таблицы Ключ (link id) Атрибут_2 Вторичный ключ Рисунок 10. Схема репозитория №4 схема икя таблицы ияя табяицк Ключ (server id) Адрес сервера Имя схемы Имя таблицы Имя агтрибута 1 Имя аттрибута 2 Вторичный хлюч
Каждая схема базы данных однозначно идентифицируется: - уникальной меткой сервера баз данных из набора меток Srv = {Srvi,Srv2,..., Srvn}. . - именем базы данных DBn = {DBni, DBri2,..., DBnt}, Дисциплина доступа к данным определяется индивидуальными логином и паролем пользователя, которые формируются из наборов пар P(UNxUP){(un,ир)\ип Є Un,up Є Up}.
Ориентируясь на большие и средние базы данных, будем рассматривать такие из них, что количество таблиц в них не превышает пятисот, а количество полей ста в каждой из них, что позволяет моделировать большое число схем реальных баз данных. В качестве наименьшей схемы внешней БД, возьмём схему базы с десятью таблицами по десять полей в каждой. Таким образом, получили минимальную и максимальную схемы.
В ходе эксперимента примем число связей в схемах внешних баз данных постоянным. Выразим значение коэффициента связности таблиц в схеме через отношение числа связных полей к их полному числу и примем равным 10 процентам.
Заполним интервалы параметров промежуточными значениями так, чтобы получилась примерно равномерная сетка (более разряженная для дальних значений): - количество таблиц: 10, 50, 100, 150, 200, 300, 400, 500; - количество полей: 10, 20, 30, 40, 60, 80, 100. Таким образом, получено пятьдесят шесть вариантов моделей схем внешних баз данных.
Объектами управления в информационной подсистеме репозитория являются схемы баз данных s = {К(A, db,Т, F), Lfu fj\Vfu Fj Є F,i= j} из множества схем S, операции управления схемами репозитория Z(S) = {zSaect(si),zInsert(8i)1zDeiete(si),zIntegrity(si)} и консолидированные запросы на выборку данных q — {qi,q2,---,qn} к данным из объединённого репозитория.
Методика оптимизации репозитория и оценки времени отклика подсистемы интеграции на этапе эксплуатации, основанной на реляционном репозитории базы данных состоит выполнении следующих шагов: 1. Фиксации времён выполнения операций выбора и естественного соединения в СУБД на которой Выбор критериев оптимизации относительно времени доступа и объёма данных. 2. Ожидании команды управления репозиторием или запроса на декомпозицию данных из 3. Коректировка частот операций добавления, удаления, выборки данных. 4. Определении объёмов схем интегрируемых баз данных в каждом из вариантов реализации схемы 5. Вычислении времени отклика системы на каждый из типов запросов на каждом варианте схемы 6. Выбора оптимальной конфигурации репозитория и фиксация оценок времени выполнения запроса 7. В случае необходимости реконфигурация репозитория и переход на шаг 2. Схема исполнения алгоритма оптимизации репозитория приведена на рисунке 12. Исследование зависимости объёма данных от класса схемы репозитория В этом разделе будет представлено графическое сравнение пяти исследуемых репо-зиториев на эффективность хранения данных от количества таблиц во внешних БД на фиксированном количестве полей и коэффициенте связности в таблицах внешних БД. В работе приведены два графика: при среднем и максимальном количестве полей (40 и 100). Из обоих графиков видно, что зависимость объема данных на диске относительно количества таблиц во внешних БД линейна, приближенные линейные коэффициенты вычислены и приведены ниже:
Проектирование и реализация универсального интерфейса пользователя генератора отчётов к репозиторию баз данных
Существующие средства генерации электронных отчётов Применение интеллектуального WEB средства генерации электронных отчетов системе ЭСМКТК из базы данных произвольной структуры позволит ускорить разработку создание средств отчетности. Понятие интеллектуальности рассмотрено в узком контексте решаемой задачи. Оно проявляется в том, что генерация отчета происходит на основе данных, которые хранятся в произвольной базе данных. База данных жестко не интегрирована в приложение. Еще одним признаком интеллектуальности является то, что предложенный WEB интерфейс осуществляет контроль над действиями пользователя. Интеллектуальное средство генерации отчетов позволяет стоить произвольный запрос на выборку данных в терминах той предметной области, экспертом в которой является пользователь. А также пользователь освобождается от необходимости знания схемы базы данных.
Интеллектуальное WEB средство генерации электронных отчетов поделено на два программных блока: пользовательский и административный. Оба блока функционируют в автоматизированном режиме, взаимодействуя друг с другом через хранилище данных. В качестве хранилища данных применяется СУБД, в которой хранятся три группы параметров: параметры подключения к внешним базам данных, схемы внешних баз данных с пользовательскими названиями и шаблоны запросов к внешним базам данных во внутреннем формате. Администратор выступает в качестве эксперта. Он назначает системным названиям атрибутов термины из области знаний пользователя. Эти данные сохраняются во внутреннюю базу данных. Пользователю предоставляется мастер по созданию запроса, который будет контролировать его действия, позволяя генерировать отчет в терминах предметной области, специалистом которой является данный пользователь.
Этот раздел посвящен описанию существующих пакетов прикладных программ, которые работают с БД и предоставляют возможность создания запроса на выборку и извлечения данных, которые находятся в БД. Эти программы рассчитаны на пользователей с различной степенью подготовки. Они отличаются интерфейсом, уровнем контроля синтаксиса запроса, глубиной интеграции БД в саму программу. Перечислим основные пакеты прикладных программ:
MySQL Console Client MySQL Console Client позволяет пользователю работать с базой данных в режиме командной строки. Пользователь может выбрать базу данных, может удалять и изменять данные, таблицы, делать запросы на выборку, вычислять агрегированные функции. Для этого ему необходимо написать запрос на языке SQL. Есть «help», в котором перечислены возможные команды SQL и их предназначение. Кроме команд SQL есть сервисные команды, например «exit» и «help».При описании сервисной части можно отметить, что есть прокрутка, т.е. пользователь может просматривать предыдущие команды. Все команды пользователь вводит с клавиатуры. Пользователю предоставляется возможность поиска в выведенном тексте и выделение всего текста. MySQL Console Client рассчитан на пользователя-специалиста баз данных.
MySqlManager MySqlManager - это простейшая графическая утилита для работы с таблицами БД. Все базы, таблицы и поля отображаются в виде древовидного списка, но нет никаких средств автоматического просмотра содержимого таблиц или изменения свойств полей. Для всех операций предусмотрено только интерактивное окно работы с SQL запросами. В контекстном меню для каждой БД есть команда «SQL query», которая вызывает окно запроса, и в теле SQL надо прописывать базу и таблицу, к которой обращаемся. Это средство рассчитано на пользователя - специалиста баз данных.
Crystal Reports Средство доступа к базам данных, позволяющие выбирать поля, Crystal Reports фирмы Seagate объединяет в себе возможности генератора запросов и средств генерации отчетов. Crystal Reports предоставляет пользователям следующие основные возможности: 1. Выбрать источник данных. 2. Выбрать таблицы и/или запросы. 3. Выбрать поля для отображения в отчёте. 4. Определить поля, по которым будет происходить сортировка. 5. Определить поля, по которым будет производиться подсчёт итогов (только для полей, для которых это можно сделать, можно подсчитать sum, average, count, min, max). 6. Определить количество записей, которое надо поместить в отчёт (все, N первых, N последних). 7. Вставить графические объекты (например, диаграмму). 8. Выбрать стиль оформления отчёта. Возможность вставить рисунок - логотип компании; ввести заголовок отчёта. 9. Сохранить отчёт для дальнейшей работы с ним. Crystal Reports рассчитан на пользователя - специалиста в области баз данных. Достоинства: С помощью Crystal Reports можно отобразить информацию из базы данных, произвести сортировку и группировку данных, а также произвести агрегатные вычисления. Используя деловую графику, пользователь может выбрать любую, удобную ему форму представления данных в отчёте. А также Crystal Reports может освоить и квалифицированный пользователь. Недостатки: Проблема заключается в источнике данных, с которыми будет работать Crystal Reports. Пользователь в этом случае обращается непосредственно к базе данных и должен понимать, что такое структура данных и разбираться в соответствии значений таблиц и полей, знать схему базы данных.
OLAP или On-line Analytical Processing Работу со средством OLAP можно условно разбить на две части. Первая часть рассчитана на привлечения пользователя - специалиста в области баз данных, знающего физическую реализацию базы данных. Для квалифицированных пользователей он переводит название таблиц и ее полей в термины предметной области, формирует кубы OLAP. Кубы OLAP представляют собой массивы, как правило, трехмерные. Таким образом, IT специалист, скрывает физическую реализацию базы данных от конечного пользователя. Вторая часть - это настройка OLAP-отчета. Этим может заняться специалист предметной области. Сначала поля плоской выборки данных разбиваются на две группы — факты (facts или measures) и измерения (dimensions). Факты — это цифры, а измерения — «разрезы», в которых будут суммироваться факты. Для факта нужно выбрать один или несколько алгоритмов агрегации. OLAP способен не только суммировать итоги, но и выполнять более сложные вычисления, вплоть до статистического анализа (например, один алгоритм агрегации — «Сумма»). Для того чтобы манипуляции с данными были интуитивно понятны, в полученном пользователем отчете инструментами управления динамической таблицей являются элементы самой таблицы — ее колонки и строки. Пользователь может перемещать их, удалять, фильтровать и выполнять другие OLAP-операции. При этом таблица автоматически вычисляет новые промежуточные и окончательные итоги. OLAP-средства ориентированы на квалифицированного пользователя. Достоинства: С помощью OLAP-средств можно получить информацию из базы данных, произвести сортировку и группировку данных, а также произвести агрегатные вычисления. И все это пользователь делает в терминах той предметной области, специалистом которой он является. Недостатки: Пользователь работает только с теми данными, для которых сформированы OLAP кубы. Если ему понадобятся дополнительные данные, то нужно будет опять привлекать IT специалиста, чтобы тот сформировал новые OLAP кубы. Классификация средств генерации отчётов
Типы классификации На основании рассмотренных пакетов прикладных программ, предназначенных для генерации запроса на выборку и получения данных из БД, был сделан анализ и предложены две классификации программных продуктов. Программные продукты, обеспечивающие доступ пользователя к базе данных, предлагается классифицировать по двум критериям (на рисунке 22): по уровню интеграции базы данных в приложение и по уровню подготовки пользователя, на которого рассчитан программный продукт.
Реализация подсистемы интеграции в электронной системе мониторинга технологических компетенцией
Происходит добавление двух новых линий с помощью функции AddPhisicalLine (Line line). Одна начинается в точке начала линии с индексом index и заканчивается в точке Point point и добавляются в список Lines всех линий с индексом first, другая начинается в точке Point point, а заканчивается в точке конца линии index и добавляются в список Lines всех линий с индексом second. Далее с помощью функции ChangeLinklndex (int index, int first, int second) для всех таблиц из списка входящих и исходящих линий исключается линия index и добавляются две новые линии first и second. Нужно отметить, что физическое удаление старой связи не происходит - эта связь до сих пор находится в списке List Line Lines и соответственно занимает память. Для того, чтобы физически удалить данную связь из списка связей вызывается функция DeleteUnnecessaryLines(), которая определяет какие линии не используются для связи атрибутов и удаляет такие связи. Так как произошло удалец не одной старой и добавление двух новых линий необходимо отредактировать граф физических связей всей схемы. Для этого вызывается функция UpdateMatrix().3Ta функция определяет координаты точек начала и конца отрезков, из которых состоит граф физических связей, и сохраняет их в списке boarderPoints. Для обновленного списка узловых точек строится матрица смежности. Таким образом происходит переопределние графа физических связей, учитывающее изменение связей.
Удаление точки Для того чтобы определить какую точку необходимо удалить вызывается функция InPoint(Point point). Из-за особенностей информационной модели, каждый узел графа связей на самом деле представляет из себя совокупность двух точек: точка конца одного отрезка и точка начала другого(в случае если данная точка не является точкой ветвления).В случае если точка является точкой ветвления в ней могут начинатся или заканчиваться произвольное число отрезков. Поэтому функция InPoint (Point point) возвращает не единственную точку, а список точек типа ExtendPoint, в котором для каждого экземпляра хранится дополнительная информация кроме непосредственно координат точки: тип точки, какой линии принадлежит точка, является ли точка концом или началом этой линии и др.
Далее этот список анализируется. Нельзя допустить удаление точек ветвления, поэтому в списке должно быть ровно две точки - начало одного отрезка и конец другого. Также невозможно удаление стартовой и конечной точек связи, поэтому все точки списка должны быть внутренними то есть иметь тип cross. Если все условия выполнены, то происходит вызов функции ConnectionLine (List ExtendPoint points) которая непосредственно осуществляет удаление точки.Удаление происходит следующим образом: определяется secondLine - индекс линии начинающейся в удаляемой точке. Такая линия будет обязательно найдена и притом только одна, так как удаляемая точка не является точкой ветвления. Также определяется firstLine - индекс линии, заканчивающейся в удаляемой точке. Координата конца линии firstLine получает значение координаты конца линии secondLine, а с помощью функции DeletelnComeLinklndex (int index) линия с индексом secondLine удаляется из списков входящих связей таблиц.Далее вызывается ConnectionLine (List ExtendPoii»t i points) определяется sccondLine - индекс липни начинающейся в удаляемой і очке определяется firstLine - индекс линии. ыканчиваюшейся в удаляемой точке Координата копна линии firstLine получаст значение координаты конца линии sccondLine линия с индексом sccondLine удаляется из списков входящих связей таблиц ранее описанная функция UpdateMatrix(), чтобы отразить изменения в графе физических связей всей схемы.
Перемещение точки Для того чтобы определить какую точку необходимо переместить, вызывается функция InPoint (Point point), которая возвращает не единственную точку, а список точек points типа ExtendPoint. Особенности работы этой функции были описаны ранее. Если этот список не пустой - значит имело место попадание в совокупность, состоящую из одной двух или более точек. Теперь в списке points хранятся точки доступные к перемещению. Далее вызывается функция IsAbleToMovePoint (Point mouseClick, int width, int heigh) с помощью которой определяется возможность перемещения. Для этого должен быть заготовлен непустой список перемещаемых точек, а координаты новой точки не должны выходить за границы рабочей области.Если данные требования выполняются, вызывается функция MovePoint (Point newPoint) которая непосредственно осуществляет перемещения точек. В теле этой функции для каждой точки выполняется функция ChangePointPosition (List ExtendPoint points), которая выбирает из списка Lines те линии,у которых координаты концов совпадают с координатами одной из точек списка points. Для таких линий происходит изменение координат концов.
Данная функция могла быть вызвана для точек начала или конца связи. Поэтому для выполнения требования, согласно которому связь начинается у названия атрибута Primary Key одной таблицы и заканчивается у атрибута «First key» другой, необходимо переместить начало или конец связи к левому или правому краю соответствующего атрибута. Для этого служит функция MoveExtremalPoints (Point mouseClick). Просматривается список points. Для каждой точки проверяется, является ли эта точка началом или концом связи. Если данная проверка выполняется, то связь необходимо перерисовать, так чтбы ее начало и конец были привязаны к какому-либо атрибуту. Для этого служит функция ChangePointPosition (ExtendPoint point, Table table, int atributlndex), которая определяет к какому краю атрибута - левому или правому точка конца или начала связи находится ближе и производит соответствующее изменение координат.
Далее вызывается ранее описанная функция UpdateMatrix(), чтобы отразить изменения в графе физических связей всей схемы
Объединение связей Объединение связей выполняется с помощью функции SplitLines (Point mouseClick) путем перемещения точки одной связи к точки другой связи. Для того чтобы определить какую точку необходимо переместить, вызывается функция InPoint (Point point), которая возвращает не единственную точку, а список точек points типа ExtendPoint. Особенности работы этой функции были описаны ранее. Если этот список не пустой - значит имело место попадание в совокупность, состоящую из одной двух или более точек. Теперь в списке points хранятся точки доступные к перемещению. Объединение возможно только для связей начинающихся или заканчивающихся у одного и того же атрибута. Это ограничение продиктовано необходимостью поддержания изолированности графа, представляющего собой совокупность связей одного атрибута. С помощью функции BothLinesStartsAtSameAtribut (out Point point, out
Физическое удаление связи к»списка Lines всех логическихсвязей схекы , переопределние графа физическихсвязей, учитывающее удалениелогической связи. t конец Рисунок 50. Блок-схема алгоритма перемещения точки int index) определяется начинаются ли обе связи у одного и тогоже атрибута. В случае выполнения проверки,выполняется объединение начальных отрезков связей.В резуль 106 тате объединения связи будут выглядеть следующим образом сначала общая начальная часть связей, затем точка ветвления, далее оставшиеся независимые отрезки связей.
С помощью функции BothLinesEndsAtSameAtribut (out Point point, out int index) определяется заканчиваются ли обе связи у одного и тогоже атрибута. В случае выполнения проверки,выполняется объединение конечных отрезков связей.В результате объединения связи будут выглядеть следующим образом сначала независимые начальные отрезки связей, затем точка ветвления, далее общая часть связей.
