Задачи повышения производительности запросов в программной системе
Рассмотрена актуальная проблема повышения производительности запросов в программных системах, поддерживающих базы данных. С целью повысить производительность, предлагается вариация модели хранения вложенных отношений, которая позволит уменьшить количество доступов к жёсткому диску, производимых сист...
Збережено в:
| Дата: | 2008 |
|---|---|
| Автор: | |
| Формат: | Стаття |
| Мова: | Російська |
| Опубліковано: |
Інститут програмних систем НАН України
2008
|
| Теми: | |
| Онлайн доступ: | https://nasplib.isofts.kiev.ua/handle/123456789/1496 |
| Теги: |
Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
|
| Назва журналу: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Цитувати: | Задачи повышения производительности запросов в программной системе / И.В. Федоров // Пробл. програмув. — 2008. — N 2-3. — С. 627-635. — Бібліогр.: 8 назв. — рус. |
Репозитарії
Digital Library of Periodicals of National Academy of Sciences of Ukraine| _version_ | 1860002534475694080 |
|---|---|
| author | Федоров, И.В. |
| author_facet | Федоров, И.В. |
| citation_txt | Задачи повышения производительности запросов в программной системе / И.В. Федоров // Пробл. програмув. — 2008. — N 2-3. — С. 627-635. — Бібліогр.: 8 назв. — рус. |
| collection | DSpace DC |
| description | Рассмотрена актуальная проблема повышения производительности запросов в программных системах, поддерживающих базы данных. С целью повысить производительность, предлагается вариация модели хранения вложенных отношений, которая позволит уменьшить количество доступов к жёсткому диску, производимых системой при выполнении запросов и соответственно повысить производительность индексных структур данных, используемых в системе.
The actual problem of increase of productivity of inquiries in the program systems supporting databases is considered. With the purpose to raise productivity, the variation of model of storage of the enclosed attitudes which will allow to reduce quantity reading to a hard disk is offered, made by system at performance of inquiries and accordingly to raise productivity of index structures of the data used in system.
|
| first_indexed | 2025-12-07T16:37:12Z |
| format | Article |
| fulltext |
Інструментальні засоби і середовища програмування
627
УДК 681.3
ЗАДАЧИ ПОВЫШЕНИЯ ПРОИЗВОДИТЕЛЬНОСТИ ЗАПРОСОВ В
ПРОГРАММНОЙ СИСТЕМЕ
И.В.Фёдоров
Институт программных систем НАН Украины,
03187, Киев, проспект Академика Глушкова, 40.
Тел.: +380 (44) 526 3309; факс: 380 (44) 526 6263; e-mail: iffivt@rambler.ru
Рассмотрена актуальная проблема повышения производительности запросов в программных системах, поддерживающих базы
данных. С целью повысить производительность, предлагается вариация модели хранения вложенных отношений, которая
позволит уменьшить количество доступов к жёсткому диску, производимых системой при выполнении запросов и соответственно
повысить производительность индексных структур данных, используемых в системе.
The actual problem of increase of productivity of inquiries in the program systems supporting databases is considered. With the purpose to
raise productivity, the variation of model of storage of the enclosed attitudes which will allow to reduce quantity reading to a hard disk is
offered, made by system at performance of inquiries and accordingly to raise productivity of index structures of the data used in system.
Введение
Наибольшую трудность в процессе разработки программной продукции вызывает выявление факторов,
которые ухудшают те или иные её показатели. Тенденцией последних лет становится всё более частое
использование методик проектирования с применением технологий учёта факторов, что несёт в себе цель
наиболее эффективнее измерить показатели системы. Это позволит получить объективную основу для
выработки оперативных и экономически эффективных управляющих воздействий на организацию в целом,
ее структурные подразделения и отдельных сотрудников. Препятствием в определении показателей обычно
являются традиционные функционально спроектированные информационные системы, которые
испытывают недостаток в способности консолидации и представления данных в удобном для анализа виде.
Это усложняет для пользователей проведение операций отслеживания ключевых бизнес-показателей,
анализа проблем с производительностью, что не позволяет им нормализовать свою работу. Пользователи
хотят иметь возможность оперировать реальной картиной процессов и финансовых потоков, в перспективе
осуществляя прогнозирование, что позволит оптимально использовать все имеющиеся ресурсы. Всё
большее количество организаций нуждается в современных инструментальных средствах поддержки и
автоматизации анализа производительности бизнес-показателей, разработка которых требует решения
проблемы наиболее оптимальной организации данных в таких программных системах.
В литературе изложены основополагающие принципы измерения показателей, но вместе с этим
отдельные методические вопросы учёта факторов, влиящих на эффективность измерения показателей
исследованы недостаточно и нуждаются в дальнейшем развитии.
В частности, требуют уточнения и дальнейшей методической проработки:
- задачи анализа проблем производительности;
- проблемы выбора эффективных решений в процессе проектирования программных систем;
- вопросы прогнозирования производительности разрабатываемой системы.
Отсутствие достоверных решений – один из факторов, сдерживающих инвестиции в разработку
программных систем. Учитывая данное, на практике в процессе проектирования необходим адекватный
инструментарий, позволяющий более эффективно использовать накопившийся научный потенциал.
Поэтому дальнейшее развитие и разработка инструментов измерения количественных показателей
приобретает особую значимость и актуальность.
Цель исследования – развитие вышеописанного инструментария в условиях влияния множества
факторов.
Достижение поставленной цели определило необходимость решения таких задач:
- исследовать традиционные подходы повышения производительности запросов в программной
системе;
- проанализировать существующие методы измерения количественных показателей;
- сформировать концепцию разработки проекта, учитывающую применение методов измерения в
Інструментальні засоби і середовища програмування
628
условиях влияния множества факторов;
- разработать инструментарий измерения показателей и соответствующие технологии
проектирования программных систем.
На текущий момент времени все более распространенным способом повышения производительности
запросов является использование в программных системах, поддерживающих базы данных, различных
вариаций моделей хранения вложенных отношений с целью минимизации количества доступов к жесткому
диску, производимых системой. Наиболее интересные исследования по данной тематике произведены
математиками С. Хошафяном и Г. Копландом. Как результат их исследований предложено несколько типов
моделей вложенных отношений. Минимизация обращений к диску достигалась путём разбивки вложенных
отношений для хранения их в как можно меньшем количестве файлах допустимого формата. Достигалось
это путём применения алгоритмов транспонированного хранения и алгоритмов жадного слияния
отношений. На момент проведения исследования эксперименты показали очень хорошие результаты, но со
временем из-за появления все более сложных индексных структур данных алгоритмы начали требовать
отдельных доработок. Все чаще требуются варианты моделей построения отношений, позволяющие
проводить оптимизацию запросов с различными вариантами построения индексных структур. Предлагается
использовать алгоритм вертикального разделения отношений, таким образом, при котором внутренние
отношения, которые часто доступны, вместе хранятся в одинаковых файлах. Это позволит минимизировать
количество обращений к диску в системах, использующих индексацию с различными правилами поддержки
баланса за счёт чтения за одно обращение всей вложенности отношения. Измерение показателя будет
осуществляться путём адаптации к системе баз данных, где применена данная модель, эффективных классов
измерения системных показателей, использующихся в объектно-ориентированных языках
программирования. В зависимости от применения конкретных классов (т. е. классов, наиболее эффективных
для определённых индексных структур баз данных), будет изменяться информация о проекте (а,
следовательно, и модель проекта). Для хранения информации о проекте используется репозиторий, в
котором хранятся соответствия системных показателей полям объектов. Объекты представляются в виде,
который допустим стандартом интеграции баз данных с объектно-ориентированными языками
программирования, что позволяет использовать их для измерения производительности запросов в
программной системе, использующей базы данных.
1. Концепция измерения показателей программной системы
Процесс разработки программного обеспечения [1] состоит из нескольких стадий. Причем эти стадии
существуют в любых моделях жизненного цикла проектов, они лишь отличаются названиями и
группировкой действий.
UML [2] поддерживает все стадии жизненного цикла проекта, его применения достаточно для полной
поддержки разработки приложения. Особенность UML в том, что он оптимизирован для применения при
разработке программных систем, что дает возможность максимально ускорить разработку программных
продуктов и заметно улучшить качество получаемой системы. Модели, разработанные в UML, позволяют
значительно упростить процесс кодирования и направить усилия программистов непосредственно на
реализацию системы.
Рассмотрим стадию проектирования, в течение которой должны быть описаны способы решения задач,
выполняемых системой. Эта стадия полностью описывает функции, классы системы и графический
интерфейс с пользователем. На данной стадии разрабатываются диаграммы классов, включая отношения
между классами и их атрибутами, что позволяет произвести классификацию объектов, функционирующих в
системе. С помощью разработанной модели поведения устанавливаются зависимости между классами,
производится разделение системы на модули и выделение классов, реализуемых в данных модулях для того,
чтобы можно было эффективно организовать разработку системы командой разработчиков. При разработке
систем, использующих реляционные базы данных, на основании диаграммы классов создаётся физическая
модель базы данных для хранения данных объектов постоянных классов.
Одним из наиболее важных параметров таких систем является время выполнения запросов (или,
другими словами, производительность их выполнения). Это промежуток между нажатием пользователем
клавиши "ввод" и получением им отчета на экране. Данный параметр является не тем искусственным
временем, которое поставщики упоминают в своих характеристиках или тестах. Эти величины
характеризуют только такой параметр, как время работы сервера при выполнении запроса. Нас не
интересует данный параметр, так как пользователям безразличны эти значения. Их волнуют реальные
задержки, с которыми они сталкиваются, связанные со скоростью передачи данных в сети и временем их
обработки персональным компьютером.
Достижение высокой производительности при выполнении запросов имеет большое значение, так как
Інструментальні засоби і середовища програмування
629
данный параметр существенно влияет на общую значимость приложения для бизнеса. Большинство людей
считает, что если выполнение запросов занимает меньше одной секунды или от одной до пяти секунд, то это
вряд ли будет составлять существенную разницу и иметь какое-либо значение при получении бизнес-
преимуществ. Но данный эффект можно количественно измерить и, более того, снижение
производительности выполнения запросов оказывает заметное негативное влияние на эффективность
бизнеса. Именно производительность выполнения запросов имеет максимальное значение для величин
показателя бизнес-преимуществ
Основными ресурсами, которые расходуются при выполнении запроса, являются ресурсы процессора,
ресурсы устройств внешней памяти и сетевые ресурсы. Последний вид ресурсов задействуется только в
распределённых системах, построенных на основе аппаратуры вычислительных сетей.
Эффективность выполнения запроса определяется временем его выполнения, т.е. реактивностью
системы по отношению к обрабатываемым ею запросам. Мерой эффективности запроса можно считать
количество системных ресурсов, требуемых для его выполнения. Для оценки работы процессора и памяти
необходимо смоделировать действия реального приложения. Реальные задачи бывают очень разные – это
может быть простая база с огромными таблицами или наоборот, очень сложная база с набором тысяч из
пяти таблиц. SQL работает неодинаково с различными базами данных. Кроме того, в реальных задачах чаще
всего ещё существует промежуточный слой COM+ приложений [3], которые используются для доступа к
базе и тоже участвуют в транзакциях. Вследствие этого мы можем сильно ошибиться в измерениях за счёт
того, что маленькую базу данных SQL элементарно закеширует в память, да и другие эффекты типа
кеширования SQL-запросов могут влиять на это. Следовательно, точные измерения можно провести только
над фиксированной базой данных. При ситуации, когда готового приложения нет, можно воспользоваться
набором тестов ТРС для баз “среднего размера” [4].
Измерение будет проводиться над программной системой, в которой поддерживается следующая
организация данных. С помощью специально спроектированного редактора в программном интерфейсе
должны указываться основные выполняемые системой функции, а также основные пользователи этих
функций. Далее проводиться разбиение этих функций на более мелкие и из них выстраивается дерево.
После этого базовые функции (на основе которых можно будет строить все остальные) можно
спроектировать. После обозначения объектов, которые будут вовлечены в выполнение базовых функций, на
UML-диаграммах сценариев описывается взаимодействие объектов. Объекты разбиваются на классы,
диаграмму которых изображают в редакторе классов. На диаграмме классов также отмечаются ассоциации,
которые перейдут в связи, соединяющие экземпляры классов, отношения наследования между классами.
Затем для каждого класса описывается его поведение. По информации о классах и их поведении, можно
осуществить создание такого алгоритма, который будет использоваться для получения оценки времени
выполнения запросов.
При разработке проекта всю информацию о проекте нужно сохранить в специальной базе данных –
репозитарии, который представляется в виде реляционной базы данных. Этот способ организации
репозитория имеет следующие достоинства:
− доступ к репозиторию из программных средств проекта будет осуществляться в объектно-
ориентированном стиле;
− в схеме данных репозитория возможно не только описание типов и отношений как в реляционных
базах данных, но и использование наследования.
Эти свойства делают возможным обращение к репозиторию в терминах предметной области, т. е. в
терминах элементов проекта, таких, например как поведение класса. Это позволит реализовать
программный интерфейс, который сможет обеспечить работу с объектами базы данных как с объектами
языка программирования. Реляционная база данных отвечает за хранение данных, а программный
интерфейс занимается представлением этих данных в объектно-ориентированном стиле. Объектно-
ориентированный стиль доступа − возможность доступа к репозиторию в терминах схемы данных.
Единицей хранения служит объект − его можно добавить в базу данных или удалить, у каждого объекта
прочитать/изменить значение атрибутов, получить объект(ы), связанный(ые) с данным.
С помощью UML можно представить функциональную, структурную и поведенческую модель проекта.
Можно также создать с помощью UML графическую нотацию для описания этих моделей. Мы будем
использовать структурную модель UML – диаграмму классов, так как диаграммы классов UML – это
мощный инструмент для создания концептуальных схем баз данных. Соответствие диаграммы классов UML
и схемы реляционной БД примерно следующее: класс соответствует таблице, а ассоциация между классами
соответствует связи между таблицами (по некоторому ключу). Именно диаграмма классов UML будет
являться исходными данными для задания схемы базы данных.
Доступ к базе данных будет происходить с помощью технологии ADO [5]. Тогда репозиторий может
поддерживаться любой СУБД, для которых существуют ODBC-драйвера для ADO. Обращение к базе
Інструментальні засоби і середовища програмування
630
данных через ADO происходит из программного интерфейса С++. Язык C++ удобен для эмуляции нагрузки.
Его использование позволяет открыть такое количество соединений, какое позволят ресурсы
информационной системы, тогда как в клиентских приложениях СУБД новые соединения необходимо
пользователю создавать вручную. Он предлагает набор классов на С++, с помощью которых осуществляется
обращение к репозиторию в терминах схемы базы данных, реализованной с помощью UML-диаграммы
классов. Репозиторий должен обеспечивать выполнение SQL-запросов, поэтому программный интерфейс
позволяет выбирать объекты, определённые SQL-предложением. Схема доступа к репозиторию показана на
рис. 1.
Рис. 1. Схема доступа к репозитарию
Международная группа ODMG [6] (Object Data Management Group) объединяет ведущих разработчиков
баз данных. Результат деятельности группы ODMG − стандарт объектно-ориентированных баз данных.
Цели этого стандарта – описать основные требования к базам данных и интегрировать базы данных с
объектно-ориентированными языками программирования.
ODMG описывает:
- объектную модель;
- язык определения объектов (ODL);
- объектный язык запросов (OQL);
- связь объектов базы данных с объектами языка программирования;
- язык манипулирования объектами (OML).
1. Объектная модель ODMG не противоречит понятиям диаграммы классов UML. Единицей хранения в
объектной базе данных стандарта ODMG является объект. Все объекты распределены по типам. Все
объекты одного типа образуют экстент. Объекты одного типа имеют одинаковое поведение и одинаковое
пространство состояний. Поведение − набор операций, которые может совершать над объектом, а состояние
определяется набором свойств объекта. Свойство − это атрибут или отношение с другим объектом
(несколькими объектами). Тип объекта может иметь супертип, что означает наследование свойств и
поведения супертипа. Наследование в ODMG может быть множественным.
2. Язык описания объектов (ODL) [6] предназначен для формального описания интерфейсов объектов
базы данных. Он является модификацией языка IDL (Interface Definition Language), созданного
международной группой OMG [OMG]. ODL служит для таких целей:
Программа доступа к
репозиторию
Программный
интерфейс OLE
Программный
интерфейс С++
ADO
ODBC
Реляционная база
данных
Інструментальні засоби і середовища програмування
631
- обеспечения универсальности описания схемы базы данных (к базе данных, схема которой описана на
ODL, можно обращаться из программ на разных языках программирования, поскольку ODL не завязан ни на
один из них);
- генерации описания интерфейса базы данных на конкретном языке программирования, из которого
планируется доступ к ней. Использование языка описания объектов показано на рис. 2.
Рис. 2. Использование языка описания объектов
3. Объектный язык запросов (OQL) [6] – декларативный язык обращения к базе данных, похожий на
язык SQL для реляционных БД. Выражения на OQL на 90 % совместимы с синтаксисом оператора select из
стандарта SQL’92. Отличия запросов на OQL от запросов на SQL заключаются в том, что входными и
выходными данными запросов OQL являются объекты, а не таблицы. В запросе можно указать, какие
атрибуты из каких экстентов мы хотим выбрать, какими условиями должны обладать объекты, из которых
мы выбираем. Для записи запроса используется конструкция select-from-where, как и в SQL. В результате
запроса на OQL можно получить как подмножество некоторого экстента объектов базы данных, так и
сконструировать из атрибутов объектов другие типы данных, например, структуру, массив. Однако нельзя
из одних объектов сконструировать другие объекты, которые бы тоже имели связи и методы.
Всё это позволит осуществить связывание баз данных с языком C++ согласно стандарта ODMG.
Перечислим основные цели проведения данной операции:
- отобразить язык описания объектов (ODL) в C++, используя Rational Rose [7] для обеспечения
взаимодействия с базами данных;
- встроить возможности объектного языка запросов (OQL) в язык программирования C++;
- определить способы манипулирования объектами базы данных в C++.
2. Методика интеграции объектов баз данных с программными объектами для
оптимизации и вычисления производительности запросов в программной системе
Rational Rose [7] − программный продукт фирмы Rational Software Corp. Rational Rose предлагает
разработчику с помощью UML проводить анализ и проектирование программного обеспечения. Разработчик
строит различные модели программного обеспечения: диаграммы случаев использования, диаграммы
классов, диаграммы сценариев. Данные с этих диаграмм сохраняются в специальной базе данных. Когда
Rational Rose запущен и пользователь работает с моделью, эта база данных находится целиком в памяти.
При выходе из программы информация сохраняется в текстовом файле, при повторном обращении к модели
содержимое этого файла закачивается в память. Работа с базой данных проекта возможна только через
Rational Rose, он должен быть запущен, база данных проекта должна находится у него в памяти.
В модели классов для каждого класса можно указать является ли он временным (transient) или
постоянным (persistent). Экземпляры временных классов существуют только во время работы программы, а
экземпляры постоянных классов сохраняются в базе данных и после окончания работы программы. По
модели классов Rational Rose позволяет сгенерировать описания классов и заголовки их методов.
Рассмотрим, каким образом понятия модели классов UML преобразовать в элементы реляционной базы
данных.
Описание интерфейсов
на ODL
ODL-препроцессор
Схема базы данных Описание интерфейсов на
языке программирования
Інструментальні засоби і середовища програмування
632
Каждому классу соответствует таблица в базе данных. В полях этой таблицы хранятся атрибуты и связи
экземпляров данного класса. Если у класса есть предок, то в таблице этого класса есть поле, указывающее
на строку таблицы предка. Унаследованные атрибуты и связи хранятся в таблице предка. Для каждого
класса, имеющего предков, описывается динамическая таблица (view), которая позволяет собрать все
атрибуты и связи объекта из нескольких таблиц. Создание ассоциаций модели классов в Rational Rose будет
выглядеть следующим образом. У экземпляра одного класса есть ссылка на строку таблицы второго класса.
Экземпляр второго класса содержит обратную ссылку.
В Rational Rose генерируются только заголовки методов классов. Операции над объектами баз данных
для предоставления их в виде объектов языка программирования должны быть описаны разработчиком.
Заготовки кода, генерируемого в Rational Rose, достаточно универсальны и подходят для любого
компилятора и СУБД. Для выполнения OQL-запросов из программы на С++ в OML введена специальная
функция oql. Её параметр – строка символов с выражением на OQL. Возвращаемым значением может быть
как некоторое скалярное значение, так и массив, структура, объект базы данных, коллекция объектов.
Теперь можно определить способы манипулирования объектами базы данных в C++ с помощью языка OML
[6].
Основной принцип языка манипулирования объектами (OML) – сделать работу с постоянными
объектами (объектами базы данных) максимально похожей на работу с временными объектами
(обыкновенными объектами C++). Для создания постоянных объектов в C++ ODMG предлагает перегрузить
и использовать оператор new. Работа с постоянными объектами производится с помощью ссылок на объект.
Оператор new, создающий постоянный объект, возвращает ссылку на него. Далее манипуляции над
объектами можно будет выполнять через эту ссылку. С помощью оператора «->» можно вызвать методы
объекта, изменить его атрибуты. Эти же ссылки используются для связи объектов в отношениях. Для
автоматического поддержания целостности ссылок предлагаются следующие действия: если между
классами в схеме данных есть отношение один к одному, то пару их экземпляров можно связать друг с
другом. Надо у одного объекта проставить ссылку на другой объект, тогда у второго объекта обратная
ссылка должна быть проставлена автоматически. Автоматическая модификация обратных ссылок должна
поддерживаться для отношений один ко многим и многие ко многим. Отношение многие ко многим можно
смоделировать с помощью введения дополнительного класса в схему базы данных.
Рис. 3. Моделирование отношения многие ко многим
Далее с помощью языка ODL осуществляется описание интерфейса объектов в базе данных в текстовом
виде, когда по диаграмме классов из репозитария автоматически генерируется программный интерфейс OLE
[8]. Частью программного интерфейса OLE является файл с описанием OLE интерфейсов объектов
репозитория. OLE-интерфейс обладает свойством языковой независимости и является лишь переходником
между пользовательской программой и интерфейсом С++. Программный интерфейс OLE баз данных
реализуется в виде динамически подключаемой библиотеки и представляет собой набор классов, которые
реализуют OLE-интерфейсы классов базы данных. OLE-интерфейсы классов базы данных содержат методы,
с помощью которых можно обратиться к атрибутам и отношениям. Классы программного интерфейса OLE
наследуются от соответствующих классов программного интерфейса C++, с помощью методов которых они
обращаются к базе данных. Главная задача программного интерфейса OLE состоит в обеспечении
возможности доступа к базе данных через OLE, а не в работе с базой данных. Поэтому программный
интерфейс OLE переадресует запросы к базе данных программному интерфейсу С++, который также
организован в виде динамически подключаемой библиотеки.
Каждому типу объектов, который хранится в репозитории, соответствует C++ класс, через методы
которого происходит доступ к его экземплярам в базе данных. Экземпляры класса создаются в базе данных
и заполняются необходимыми данными, а затем сохраняются в репозитории. Когда задаётся поведение
объектов класса, то состояния, представляются объектами класса и сохраняются в репозитории. Добавление
нового состояния в описание поведения некоторого класса осуществляется с помощью использования
следующей структуры данных:
Класс2
n n
Класс1
Класс1 Вспомогательный класс Класс1
1 n n 1
Інструментальні засоби і середовища програмування
633
имя_класса * имя_переменной =new имя_класса();
имя_класса ->SetName(«имя_состояния»);
имя_класса->SetOwner(описание_поведения);
имя_класса ->Update();
delete имя_класса;
Программный интерфейс предоставляет возможность извлекать данные из репозитория. Для
выполнения данной функции предназначены классы для представления коллекций объектов репозитория.
Далее осуществляется выбор коллекции объектов одного типа, обладающих заданными свойствами
(указанных с помощью предложений языка запросов). В любой коллекции можно выбрать первый элемент,
следующий, предыдущий. Каждый отдельно взятый элемент является экземпляром соответствующего
класса из интерфейса репозитория и предоставляет возможность получить все сведения об объекте из базы
данных репозитория. Методы классов программного интерфейса позволяют получить объекты, связанные
ассоциациями с данными. Для поддержки ассоциаций один к одному и один ко многим, по ассоциации мы
можем получить экземпляр интерфейсного класса, представляющий один объект базы данных, а можем
получить и целую коллекцию объектов. Для выполнения запросов к базе данных из программы
осуществляется вызов специальной функции СУБД для выполнения инструкций встроенного языка
запросов. Таким образом, измерение времени выполнения запроса в программной системе становится
возможным проводить, если для хранения отношений использовать следующую модель.
В литературе модели хранения отношений делятся на четыре класса. Каждая модель хранения
отображается вложенным отношением. Для демонстрации каждой модели хранения используются схемы
вложенного отношения. Для каждого внешнего отношения существует суррогатный атрибут, (то есть
искусственный идентификатор), который используется как идентификатор для отношения.
1. Декомпозированная модель хранения использует транспонированное хранение. Каждый атомарный
атрибут отношения существует вместе с суррогатным атрибутом для записи форм единичной матрицы
бинарного отношения. Каждое бинарное отношение хранится в отдельном файле.
2. Нормализованная модель хранения разбивает вложенное отношение таким образом, что атомарные
атрибуты каждого внешнего отношения и внутренние отношения на подаваемом уровне связываются друг с
другом, используя суррогатные атрибуты. Индексы объединения могут использоваться в порядке
извлечения внутреннего отношения.
3. Простая модель хранения в оригинале называется непосредственной моделью хранения. Вложенное
отношение хранится прямо в файле. Каждая запись файла представляется целым внешним отношением.
Записи файла могут быть объединены по атомарным атрибутам кортежей внешнего отношения. Доступ к
кортежам внешнего отношения базируется на атрибутах отличных от кортежей внешнего отношения и
осуществляется путём использования вторичных индексов и проведением последовательного сканирования.
4. В частично декомпозированной модели атомарные атрибуты внешнего отношения являются
разделёнными на такие атомарные атрибуты, которые часто доступны вместе и хранятся в одном и том же
файле. Каждый файл содержит множество атомарных атрибутов.
В данной работе представляется вариант хранимой модели, где нормализованная и простая модель
могут быть отображены как два специальных блока. Вложенное отношение является вертикально
разделённым таким образом, при котором внутренние отношения, которые часто доступны вместе, хранятся
в одинаковых файлах. Каждый файл содержит атомарные атрибуты внешнего отношения и некоторые их
потомки.
При сохранении в один и тот же файл внутренних отношений, которые часто совместно доступны,
номер операций ввода-вывода выполняет функцию представления реакции на запросы, которые были
предварительно обработаны. Модель обеспечивает хорошую поддержку для вложенных систем баз данных,
которые манипулируют внешними кортежами отношения и их атомарными атрибутами на различных
вложенных уровнях.
Модель графически представляется как дерево и называется схемой дерева. Каждый узел в схеме
дерева представляет собой файл, который содержит атомарные атрибуты внешнего отношения. Рисунок 4
описывает схему дерева.
Рис. 4. Схема дерева отношений.
(а)
(b) (c)
(d,e) (f,g)
Інструментальні засоби і середовища програмування
634
3. Модель схемы дерева
Схема дерева Т с узлом множества Nt вложенного отношения представляет собой вложенную структуру
отношения. Схема дерева является также графическим представлением модели. Каждый узел ni и Nt
представляет собой файл, который содержит атомарное отношение. Каждая граница в схеме дерева Т
представляет отношение между двумя атомарными отношениями, которые смежные с ребром.
Схема вложенного отношения R состоит из пяти атомарных отношений: R = (a), X = (b), Y= (c),
Z = (d,e) и V = (f,g).
Схема дерева Т вложенного отношения R показана на рис. 1. Назначим 2 параметра узлам и рёбрам в
поданной схеме дерева: 1) стоимость запроса узла (файла) и 2) частота запроса узла. Стоимость запроса узла
будет являться функцией типов запроса и алгоритмов обработки запроса, которые имеют доступ к этому
узлу. Частоты запроса узлов и рёбер зависит от отношения между узлами включенных в запросы. Для
запроса Q узел n будет узлом запроса, если он ссылается на этот запрос. Nq − это множество всех узлов
запроса с отношением к запросу Q. Те узлы, которые не появляются в запросе Q, называются узлами не
принадлежащие запросу. Nt-Nq является множеством не запросных узлов с отношением к запросу Q.
Теперь необходимо построить дерево запроса. Для этого нужно удалить не запросные узлы из схемы
дерева Т. Принимаем запросные узлы формы как дерево и называем результирующее дерево деревом
запроса Tq (рис. 5).
Рис. 5. Множество назначенных узлов для схемы дерева
Для данного запроса Q, множество узлов запроса является Nq = {n1, n2, n4}. Тогда множество не
запросных узлов является {n3, n5}. Если не запросные узлы удалены из схемы дерева Т тогда остаточные
узлы будут формировать следующее дерево запроса (рис. 6):
Tq:
Рис. 6. Модификация дерева запросов
Файл f представлен схемой узла дерева и может быть доступен: а) запросам, которые только ссылаются
на атрибуты в n, и/или b) запросам, которые ссылаются на n и другие узлы ni, которые смежные с n.
Заданную схему дерева модифицируем в "новую" схему дерева для получения более качественных
показателей. Непосредственно считывая количество запросов у файлов, мы назначаем частоту обоим узлам
и рёбрам схемы дерева в порядке вычисления количества файлов для проверки деревьев схемы. Частота fj
узла nj для типа запроса q обозначает количество этих запросов типа q, которые только ссылаются на
аттибуты в nj. Для типа запроса q, частота fxi ребра ei связанная с узлами n и nj обозначает количество этих
запросов типа q, которые ссылаются на атрибуты n и nj. Принимая то, что L рёбер, связанных с узлом n в Т и
ei, а также 1<= i <= L, можно сделать вывод, что узел является крайним связанным с узлом n. Пусть узел n в
схеме дерева представляет файл F. Тогда время выполнения запроса An,q файла F с отношением типа запроса
q обозначает количество запросов типа q, которые ссылаются на атрибуты n. Таким образом An,q
определяется как
L
An,q := (∑fxi ) + fn .
i = 1
(n1)
(n2) (n3)
(n4) (n5)
(n1)
(n2)
(n4)
Інструментальні засоби і середовища програмування
635
Выводы
Рассмотрен проект системы и описана организация данных, использование которой позволяет более
эффективнее и точнее измерить количественные параметры в программных системах, использующих
реляционные базы данных. Организация данных в описанном виде позволяет повысить способности
консолидации и представления данных в удобном для их анализа виде, что позволит устранить препятствия,
возникающие при определении количественных показателей в системах такого плана. Выбор показателя для
измерения аргументирован его существенным влиянием на эффективность бизнеса организаций,
использующих ИТ-технологии. Для определения влияния системных ресурсов на эффективность
выполнения запросов к базе данных, смоделированы действия приложения,проводящего операции над
объектами баз данных, а также представляющего их в виде объектов языка программированния.
Представлена модель описания объектов баз данных в виде классов, которая позволяет связывать объекты
языков программирования с объектами баз данных при использовании описанной организации данных в
системе. Методы классов позволяют получить объекты, связанные ассоциациями с данными из базы
данных. Разработана модель хранения отношений, которая предназначена для оптимизации запросов к базе
данных, концептуальная схема которой в программной системе представлена в виде UML-диаграммы.
1. Ахо А., Хопкрофт Д., Ульман Д. Построение и анализ вычислительных алгоритмов. − М.: Наука, 1989. − 360 с.
2. Боггс У, М.Боггс М. UML и Rational Rose 2002. − Лори, 2004. − 582 с.
3. Чеппела Д. Технологии ActiveX и OLE // Microsoft Press, 2005. − 538 с.
4. Ресурс Transaction Processing Performance Council - www.tpc.org
5. Баженова И.С. Основы ADO.NET //КУДИЦ-Образ, 2006. − 448 с.
6. Джордан Д. Обработка обьектных баз данных в С++. − М.: "Вильямс", 2006. − 384 с.
7. Леоненков А.В. Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose − БИНОМ.
Лаборатория знаний, Интернет-университет информационных технологий - ИНТУИТ. – 2006. − 567 с.
8. Брокшмидт К. Inside OLE - Microsoft Press, 2005. − 623 с.
|
| id | nasplib_isofts_kiev_ua-123456789-1496 |
| institution | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| issn | 1727-4907 |
| language | Russian |
| last_indexed | 2025-12-07T16:37:12Z |
| publishDate | 2008 |
| publisher | Інститут програмних систем НАН України |
| record_format | dspace |
| spelling | Федоров, И.В. 2008-07-31T15:08:06Z 2008-07-31T15:08:06Z 2008 Задачи повышения производительности запросов в программной системе / И.В. Федоров // Пробл. програмув. — 2008. — N 2-3. — С. 627-635. — Бібліогр.: 8 назв. — рус. 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/1496 683.1 Рассмотрена актуальная проблема повышения производительности запросов в программных системах, поддерживающих базы данных. С целью повысить производительность, предлагается вариация модели хранения вложенных отношений, которая позволит уменьшить количество доступов к жёсткому диску, производимых системой при выполнении запросов и соответственно повысить производительность индексных структур данных, используемых в системе. The actual problem of increase of productivity of inquiries in the program systems supporting databases is considered. With the purpose to raise productivity, the variation of model of storage of the enclosed attitudes which will allow to reduce quantity reading to a hard disk is offered, made by system at performance of inquiries and accordingly to raise productivity of index structures of the data used in system. ru Інститут програмних систем НАН України №2-3 С. 627-635 Інструментальні засоби і середовища програмування Задачи повышения производительности запросов в программной системе Problems of increase productivity queries in program system Article published earlier |
| spellingShingle | Задачи повышения производительности запросов в программной системе Федоров, И.В. Інструментальні засоби і середовища програмування |
| title | Задачи повышения производительности запросов в программной системе |
| title_alt | Problems of increase productivity queries in program system |
| title_full | Задачи повышения производительности запросов в программной системе |
| title_fullStr | Задачи повышения производительности запросов в программной системе |
| title_full_unstemmed | Задачи повышения производительности запросов в программной системе |
| title_short | Задачи повышения производительности запросов в программной системе |
| title_sort | задачи повышения производительности запросов в программной системе |
| topic | Інструментальні засоби і середовища програмування |
| topic_facet | Інструментальні засоби і середовища програмування |
| url | https://nasplib.isofts.kiev.ua/handle/123456789/1496 |
| work_keys_str_mv | AT fedoroviv zadačipovyšeniâproizvoditelʹnostizaprosovvprogrammnoisisteme AT fedoroviv problemsofincreaseproductivityqueriesinprogramsystem |