Содержание к диссертации
Введение
1. Теоретические и методологические аспекты проведения рефакторинга баз данных промышленньгх предприятий 15
1.1. Эволюционный подход к моделированию баз данных 15
1.2. Современные технологии построения распределенных интегрированных информационных систем 20
1.3. Анализ задач проектирования и управления распределенной ингерированной информационной системой 23
1.4. Проблемы применения рефакторинга баз данных при его внедрении в производственный процес 25
1.4.1 Эффективное развертывание с передачей из одной специализированной среды в другую 27
1.4.2 Применение наборов операций рефакторинга базы данных...29
1.4.3 Планирование подходящих интервалов развертывания 31
1.4.4 Развертывание всей системы 34
1.4.5 Удаление устаревшей схемы 37
Выводы 38
2. Синтез и формализация и решение задачи рефакторинга баз данных промышленных предприятий 40
2.1. Метод формирования структуры базы данных 41
2.2. Планирование разработки системы баз данных 44
2.3. Разработка метода распознавания сходства текущего состояния системы с выделенными критическими состояниями 55
Выводы з
3. Методы разработки оптимальных структур данных промышленных предприятий 66
3.1. Оптимальное размещение данных и критерии оптимальности 66
3.2. Оценка семантических свойств доменов при обеспечении целостности и эффективности бд 73
3.3. Учет индивидуальных семантических свойств данных в доменно-ориентированной организации данных 80
3.4. Метод оптимизации структур данных промышленных предприятий по рейтингу запросов 83
4. Проведение рефакторинга распределенной базы данных промышленного предприятия и оценка его эффективности (на примере ликеро-водочного холдинга ООО «Парламент продакшн») 91
4.1. Разработка методики рефакторинга баз данных 91
4.1.1 Общая схема проведения РБД ИСПП 91
4.1.2 Признаки необходимости проведения рефакторинга БД ИСГШ 92
4.1.3 Построение плана проведения РБД ИС
4.2. Реализация полученного плана рефакторинга сложности, встречающие при реализации операций рефакторинга 105
4.3. Управление развертыванием изменений, средства контроля версий, откат изменений 136
4.4. Сравнительная оценка эффективности вариантов иерархической структуры данных 140
4.5. Оценка производительности и работоспособности систем с различной архитектурой 145
Выводы 1
- Анализ задач проектирования и управления распределенной ингерированной информационной системой
- Разработка метода распознавания сходства текущего состояния системы с выделенными критическими состояниями
- Учет индивидуальных семантических свойств данных в доменно-ориентированной организации данных
- Управление развертыванием изменений, средства контроля версий, откат изменений
Анализ задач проектирования и управления распределенной ингерированной информационной системой
В теоретическом плане распределенные интегрированные информационные системы (РИИС) составляют еще одно измерение в пространстве исследований и разработок систем управления базами данных. В этих системах приходится решать все задачи, свойственные централизованным системам, но, как правило, в более сложных постановках. Кроме того, в распределенных системах возникают и специфические проблемы, от решения которых во многом зависит эффективность, надежность и доступность систем БД. В настоящее время большинство распределенных СУБД базируется на реляционной модели данных и рассчитано на использование в локальных сетях ЭВМ. Многие проблемы распространяются и на распределенные СУБД в территориально разнесенных сетях, и почти все проблемы сохраняются для распределенных СУБД, основанных на других моделях данных.
Распределенная база данных - это совокупность множества взаимосвязанных баз данных, распределенных в компьютерной сети. Система управления распределенной базой данных определяется как программная система, которая позволяет управлять базой данных таким образом, чтобы ее распределенность была прозрачна для пользователей. В этом определении следует уточнить два отличительных условия. Первое заключается в том, что система состоит из (возможно, пустого) множества узлов приема запросов и непустого множества узлов данных. Узлы данных обладают средствами для хранения данных, а узлы приема запросов - нет; на них лишь выполняются программы, реализующие пользовательский интерфейс для доступа к данным, хранящимся в узлах данных. Второе условие заключается в том, что узлы логически представляют собой независимые компьютеры, на которых установлены собственные операционные системы (может быть, одинаковые на всех узлах, а возможно, и разные) и могут выполняться независимые приложения. Т.е. узлы - это компьютеры, связанные сетью, а не процессоры, составляющие многопроцессорную конфигурацию. Важнейший отличительный признак -слабосвязанный характер среды, где каждый узел имеет собственную операционную систему и функционирует независимо.
База данных физически распределяется по узлам данных при помощи фрагментации и репликации, или тиражирования, данных. Отношения, принадлежащие реляционной базе данных, могут быть фрагментированы на горизонтальные или вертикальные разделы. Фрагменты данных могут также тиражироваться с учетом спроса на доступ к ним. Это полезно, если доступ к одним и тем же данным нужен из приложений, выполняющихся на разных узлах. В таком случае, с точки зрения экономии затрат, более эффективно будет поддерживать копии данных на всех узлах, чем непрерывно пересылать данные между узлами.
Предположим, что банк, помимо центрального офиса, имеет ряд филиалов, связанных с ним выделенными линиями связи, не обладающими, однако, достаточной пропускной способностью для подключения рабочих мест в филиалах к центральной БД в режиме клиентов. Напрашивается решение с использованием распределенной БД, организованной так, чтобы данные, чаще всего требующиеся в филиале, физически располагались на его локальном сервере. При этом возникает вопрос: как обеспечить возможность доступа из филиалов к центральной БД и из центрального офиса к данным в филиалах?
Если организовать распределенное хранение данных, как в предыдущем варианте, любой такой запрос (или транзакция) может выполняться с большой задержкой. В качестве выхода можно предложить хранить объекты данных в распределенной БД не в единственном экземпляре, а тиражировать их на всех серверах, где к ним может потребоваться быстрый доступ. Естественно при этом возникает необходимость каким-либо образом обеспечить синхронизацию различных копий одних и тех же данных, иначе распределенная БД потеряет свою целостность и превратится в хаос.
Методика обеспечения целостности распределенной БД - лишь один из аспектов, определяющих упомянутое различие. Рассмотрим вопрос об организации связи между серверами в распределенной БД. Если свежесть тиражированных данных требуется, допустим, в пределах суток, а последствия непредсказуемости системы и потери ее целостности не слишком разрушительны. Но если все-таки требуется действительно промышленная система, то необходимо очень тщательно оценить все возможные последствия применения выбранного механизма взаимодействия и ввести в использование того же тиражирования такие ограничения, которые обеспечили бы требуемый уровень целостности системы.
Распределенные СУБД предоставляют ту же функциональность, что и централизованные СУБД, если не считать того, что они работают в среде, где данные распределены по узлам компьютерной сети или в пределах многопроцессорной системы. Как уже упоминалось, пользователи могут вообще ничего не знать о распределении данных. Таким образом, эти системы обеспечивают пользователям логически интегрированное представление физически распределенной базы данных. Поддержка подобного представления - источник ряда сложных проблем, которые должны решаться системными функциями.
Существует множество альтернатив распределенной обработки. Наиболее популярна в настоящее время архитектура клиент-сервер [41], когда множество машин-клиентов осуществляют доступ к одному серверу баз данных. В таких системах, которые можно определить как системы типа много-клиентов/один-сервер, проблемы управления базой данных решаются относительно просто, поскольку вся она хранится на одном сервере. Задачи, с которыми приходится здесь сталкиваться, - это управление буферами клиентов, кэширование данных и, возможно, блокировки. Управление данными реализуется централизованно на одном сервере.
Более распределенной и более гибкой является архитектура типа много-клиентов/много-серверов, когда база данных размещена на множестве серверов, которым, для того чтобы вычислить результат пользовательского запроса или выполнить транзакцию, необходимо взаимодействовать друг с другом. Каждая клиентская машина имеет свой "домашний" сервер; ему она направляет пользовательские запросы. Взаимодействие серверов друг с другом прозрачно для пользователей. В большинстве существующих СУБД реализован один из этих двух типов архитектуры клиент-сервер.
Разработка метода распознавания сходства текущего состояния системы с выделенными критическими состояниями
Для проверки точки на локальный оптимум в алгоритмах ЛОП и Л021 рассматривается вся окрестность (все множество решений) и из перспективных направлений выбирается то, которое дает максимальное улучшение целевой функции. В Л012 и Л022 окрестность точки просматривается до получения первого перспективного решения.
Точность разработанных алгоритмов оценивалась косвенно по результатам, полученным относительно алгоритма поиска начального допустимого решения. Проведенные испытания показали, что предлагаемые алгоритмы позволяют улучшить значение целевой функции на 10- 13% относительно начального решения. При этом максимальную точность обеспечивает алгоритм Л011.
Из характеристики программ, реализующих разработанные алгоритмы, видно, что полученное время счета на 10- 12% лучше, чем при ранее существующей двухкритериальной постановке задачи.
Таким образом, разработанные методы и алгоритмы формирования структуры СБД могут быть практически применены на этапе концептуального проектирования для определения множества ПБД, удовлетворяющих требованиям процесса проектирования и эффективной эксплуатации систем баз данных, для предприятий, имеющих сложную глобальную предметную область, и, в частности, для предприятий, ориентированных на диагностику и ремонт сложных машин и агрегатов.
В первой главе было показано, что создать и внедрить сразу всю СБД не представляется возможным, поэтому на этапе концептуального проектирования необходимо определить последовательность разработки ПБД. Аналогичные проблемы возникают при проектировании ИС [14,76] и программного обеспечения [88, 35]. В [76] данная задача решается неформальными методами группой разработчиков на основе выбранных критериев эффективности и анализа взаимосвязи систем. Преимущество отдается системам, с помощью которых можно продемонстрировать результаты работы в более короткие сроки. Однако при наличии большого числа задач и типов данных планирование разработки неформальными методами становится сложным. Таким образом, является актуальным вопрос разработки формализованного описания задачи планирования и методов ее решения, которые рассмотрены ниже. При этом полагается, что: - разработка ПБД будет производиться последовательно; - в системе нет запросов, требующих многобазовой обработки; - ресурсы, выделяемые на разработку, заданы и не изменяются во времени.
Приоритет внедрения ПБД определяется на основе следующих критериев [35, 97]: сроки разработки и внедрения, сроки окупаемости проекта, косвенные доходы и личный фактор. Так как на этапе концептуального проектирования невозможно дать точную численную оценку этих критериев, то для формализации задачи используется аппарат теории нечетких множеств [46].
Длительность разработки 1-й ПБД задаем нечеткой переменной времени X с монотонно возрастающей функцией принадлежности fД X J, имеющей предел, равный 1, которая физически означает, что: - при х Є [0, а] проектирование ПБД не может быть законченно; - при х Є [а, оо] окончание работ зависит от ряда факторов, но обязательно будет закончено.
Из класса монотонно возрастающих функций для описания процессов планирования рекомендуется использовать экспоненциальную функцию следующего вида [46]: j где: а- положительное вещественное число, равное минимальному сроку реализации системы при заданных ресурсах на разработку; ОС - положительное вещественное число, учитывающее влияние на время реализации ПБД различных случайных факторов.
Оба параметра задаются экспертами на основе анализа схемы ПБД, решаемых задач и запросов. В дальнейшем функцию принадлежности будем обозначать так же, как и функцию трех параметров f (X, а, ОС J. Рассмотрим свойства функции (2.1), необходимые для описания проектирования СБД. Свойство 1. Функция принадлежности суммы двух нечетких переменных принадлежит к тому же классу, что и функции принадлежности слагаемых.
Учет индивидуальных семантических свойств данных в доменно-ориентированной организации данных
Проведенный анализ показал, что в качестве условий окончания процесса кластеризации необходимо выбрать достижение порогового значения функции и/или максимального количества итераций, или сходимость к окончательному устойчивому разбиению, или ограничение времени кластеризации при несходимости алгоритма.
Необходимо решить проблему вычисления функций принадлежности (2.18) в рамках теории нечетких множеств [130] для данного приложения. При этом должна использоваться симметричная матрица индексов сходства (расстояний) для всех пар элементов:
Данные матрицы при расчетах на ЭВМ могут представляться различным образом в оперативной памяти или храниться на внешних носителях [19]. Задавая функции принадлежности тем или иным образом, мы получаем возможность квантифицировать логические данные, то есть как-то численно определить их тип, и, с другой стороны, конечная матрица функций принадлежности рекомендуемого разбиения может помочь идентифицировать найденные кластеры.
Необходимо тщательно подходить к выбору алгоритма начального "дискретного" разбиения, поскольку исследования показывают его сильное влияние на окончательный вид, качество разбиения и весь ход нечеткой классификации - в случае большой "размытости" данных.
Требуется разработать алгоритмы классификации элементов моделей данных, способные работать в реальном масштабе времени - условие эффективности и возможности реализации подхода использования экспертных систем при проектировании БД.
Перечисленные проблемы решены в диссертации при разработке и реализации методов нечеткой классификации элементов концептуальных моделей ПО и оценки ее результатов.
Решение первой задачи автоматизации проведения процесса рефакторинга БД требует распознания текущего состояния БД. Такое распознание предполагается для проведения автоматической классификации множества состояний ИС, так как субъективный выбор меры сходства или различия объектов для конкретной ситуации означает необходимость получения дополнительных знаний о параметрах системы и используемом подходе к классификации. Так, по схеме Михальски [108] показатель сходства К объектов е; и e_j, есть функция наборов характеристик этих объектов Р; и Pj, сведений о приложении R и множества предопределенных концепций Si для определения отношения близости (например, выделение наиболее важных характеристик с помощью системы весовых коэффициентов): K(ei,ej) = f(Pi,Pj,R,Sl) (2.49)
Анализ некоторых известных метрик численной таксономии для конкретных приложений, в том числе (2.32) - (2.38), приведен в [19], однако для задачи проектирования баз данных необходимо провести анализ множества возможных мер сходства с точки зрения совокупности знаний о процессе проектирования БД и использовании в нем свойств-атрибутов объектов и взаимосвязей ПО, формирующих множество К. Такой анализ показал целесообразность использования для данного приложения индекса Жаккара (зависимость (2.32)). На рисунке 2.1 показаны результаты расчета коэффициентов сходства одного из объектов (объект е4) множества тестового примера при N=28 с возможным числом атрибутов - 47 для зависимостей (2.32) - (2.36). В примере наблюдается максимальное сходство объектов е4, е7, Єї і, е2ь е25, некоторое сходство объекта е4 с другими объектами. Очевидно, что ломаная результатов расчета для зависимости (2.32) занимает среднее положение и совокупность значений обладает максимальной дисперсией, то есть высокой чувствительностью по отношению к наличию одинаковых характеристик у пары объектов и "безразличной" к атрибутам, им не присущим.
Запишем зависимость (2.32) в другом виде для расчета коэффициента сходства между объектами ej и ej из множества Е, характеризующихся множествами атрибутов, соответственно, А; и Aj: = canton А,) {250) card{Al) + card(Aj) - card{Al n Al) Знаменатель выражения (2.50) представляет собой размерность (множества объединения Aj и Aj. Результаты расчетов для всех пар объектов из Е представляются матрицей коэффициентов сходства (2.46). Очевидно, что Ve,, е} є Е: kij = кр (2.51) - свойство симметричности и kij = 1 (2.52) - свойство рефлексивности. 20 18 14 10 6 /C4y л і IIп іИ II 11 м ТГ II II / / р; 11 і і/ І І/ Іі/ Л 1 KM ьп Л /л r ч /Л\ /А\ f N 1 : 3 f 3 5 5 1 0 12 14 16 18 20 22 24 26 Условные обозначения: - зависимость (2.32); - зависимость (2.33); - зависимость (2.34); - зависимость (2.35); - зависимость (2.36);
Таким образом, осуществляется переход от исходных данных в виде бинарных матриц принадлежности элементов моделей типа «БД-параметр БД», «состояние-параметр БД», к матрицам коэффициентов сходства, используемым для проведения кластер-анализа, расчета функций принадлежности и функционалов качества разбиения.
Управление развертыванием изменений, средства контроля версий, откат изменений
В качестве индивидуальных семантических свойств данных можно рассматривать способ именования (кодирования, записи и т.д.) данных в естественном языке. Наличие семантических свойств данных можно рассмотреть на примере широко используемых во многих приложениях слов связанных с обозначением понятий: фамилий, имен, отчеств, названий городов. В традиционных СУБД для физического хранения данных используются поля записи. Каждое поле, соответствующее слову, имеет длину равную максимальному количеству символов, необходимых для представления любого слова из некоторой совокупности слов. При доменно-ориентированной организации физическая организация хранения множества слов может учитывать семантические свойства слов {например, общие приставки, корни, суффиксы, окончания). Это позволяет добиться уменьшения физической памяти, используемой при кодировании слов.
В таблице 3.4 приведена зависимость между условной длиной поля (D) и его физической реализацией в различных СУБД, где: D - количество символов в строковом элементе; N - количество элементов в рассматриваемом множестве данных; f(D, N) - функция, указывающая зависимость средней длины поля от D и N; Таблица 3.4. Зависимость между условной длиной поля (D) и его физической реализацией в различных СУБД. Организация данных Количество символов в поле Физическая длина поля (байт) Комментарии СУБД FoxPro D D Физическая длина поля равна средней длине поля D СУБД Clipper D D Физическая длина поля равна средней длине поля D СУБД Oracle D D Физическая длина поля равна средней длине поля D Доменно-ориентированная D f(D, N) Средняя длина поля вычисляется в зависимости Уменьшение объема, используемого для хранения данных, в целом позволит снизить объем внешней и оперативной памяти, используемой для организации хранения данных, и позволит существенно уменьшить количество операций ввода-вывода, что приведет к уменьшению времени доступа.
Рассмотрены зависимости средней длины строкового поля, выделяемого для хранения фамилий, для организации данных в ряде известных СУБД. Указанные способы организации данных не учитывают семантику представляемых данных. Наряду с рассмотренными методами представления данных в СУБД была рассмотрена организация данных, учитывающая семантику слов -фамилий, которая заключается в существовании у слов общей части. Это позволило разрабатывать методы компактного представления данных. В таблице 3.5 приведены результаты эксперимента.
Количествоэлементов вобластихранения Размер текстового файла безсжатия Размер файла в СУБД FoxPro, Cliper (байт) Размер области данных в СУБД Oracle (байт) Размер файла,в которомданныепредставленыс учетомсемантики(байт) Средняя длиназначения поля с учетомсемантики (байт) Средняя длиназначенияполя втекстовомфайле(байт) Средняя длина значения поля в СУБД FoxPro, Clipper (байт) Средняя длиназначения поля в СУБД Oracle (байт)
Зависимость средне длины значения поля от количества элементов в области хранения. Из графика видно, что учет семантических свойств в организации данных позволит уменьшить среднюю длину элемента и, следовательно, объем памяти для хранения данных для больших N (более 20000 элементов, средняя длина элемента уменьшается в четыре раза). Однако при малых значений N (менее 1150 элементов) очевидно, что предложенная организация хранения данных не дает нужного эффекта по сравнению с используемыми в СУБД. Однако учет семантики для организации хранения меньшего количества элементов позволит предложить другие более подходящие методы кодирования данных, например, для фамилий (которых меньше 150) можно выделять память меньшими блоками.
Современные РИИС, в своей работе используют механизм очередей и обслуживающих устройств. Иными словами, любая информационная система может быть представлена в виде взаимодействующих систем массового обслуживания. Система называется высоконагруженной в случае, когда среднее число запросов, находящихся в очереди обслуживающего устройства, превышает единицу. Ввиду того, что система практически постоянно находится в работе, задача по минимизации времени ожидания обслуживания имеет большое практическое значение.
