Вопрос оптимизации запросов всегда является актуальным как для разработчиков баз данных, так и для программистов, которые с ними работают. Поэтому актуально понять причины снижения производительности SQL Server и в результате минимизировать затраты ресурсов сервера путем оптимизации запросов.

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

1 Актуальность темы и научная новизна

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

Также актуальным вопросом в рамках действующей АСУ является написание оптимизированных запросов на стадии их разработки, так как в большинстве задач используются большие запросы с множественной связкой таблиц между разными базами данных. Благодаря оптимизированным запросам можно избежать большой нагрузки на сервер, при этом не отнимать ресурс сервера у других задач.

Научная новизна работы состоит в повышении эффективности существующих алгоритмов оптимизации запросов с целью улучшения работы действующей автоматизированной системы управления ДонНТУ (Донецкий национальный технический университет).

Практическая часть состоит в разработке и внедрению программы автоматизированного формирования расписания занятий в ВУЗе, с целью уменьшения трудозатрат персонала.

2 Цели и задачи исследования, планируемые результаты

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

Список целей, которые необходимо выполнить в рамках магистерской работы:

1) Изучение технологии формирования расписания занятий в ВУЗе;

2) Изучение технологии, математических методов и подходов для формирования расписания занятий в ВУЗе;

3) Разработка плана по автоматизации процесса формирования расписания занятий в ВУЗе;

4) Разработка структуры программного обеспечения (ПО) и набора необходимых функций;

5) Разработка структуры базы данных для реализации поставленной задачи.

Результатами успешного выполнения магистерской работы должны являться:

1) Desktop — версия приложения для автоматизированного формирования расписание занятий в ВУЗе в рамках ВУЗа;

2) Web — версия приложения для просмотра расписания на текущий учебный семестр.

3 Обзор исследований и разработок

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

Автоматизации процесса формирования расписания, является довольно распространенной. Соответственно разработок в этой области не на много меньше чем в оптимизации запросов.

3.1 Обзор международных источников

В мире существует множество работ и публикаций на тему «оптимизации запросов» и «расписание занятий в ВУЗе». Ниже приведен список наиболее популярных публикаций, авторы которых внесли весомый вклад в развитие данной отрасли.

Публикация Colorni A., Dorigo M., Maniezzo V. A genetic algorithm to solve the timetable problem // Submitted to computational optimization and applications journal. В данной работе представлены результаты исследования возможностей, предлагаемых генетических алгоритмов для решения задачи расписание [1].

Публикация Wilke P., Gröbner M , Oster N. A Hybrid Genetic Algorithm for School Timetabling // AI 2002: Advances in Artificial Intelligence. Гибридные генетические алгоритмы применяются так называемые гибридные или реконструктивные операторы и рассматриваются проблемы конкретных знаний в предметной области их мутации и скрещивания операторов [2].

Публикация Karami A.H. , Hasanzadeh M. University course timetabling using a new hybrid genetic algorithm // Computer and Knowledge Engineering (ICCKE), 2012 2nd International eConference on. Рассматривается проблема формирования расписания занятий университета, которая является классической, старая и известная проблема в области задач оптимизации [3].

Публикация Salwani A., Hamza T. Generating University Course Timetable Using Genetic Algorithms and Local Search // Convergence and Hybrid Information Technology, 2008. ICCIT '08. Third International Conference on (Volume:1 ). В этой работе мы устанавливаем новый алгоритм на основе генетических алгоритмов (ГА) и последовательного локального поиска, чтобы решить проблему формирования расписания[4].

Публикация Ozsu M. N., Valduriez P. Principles of Distributed Database Systems. В книге идет речь об особенностях работы с распределенными базами данных и СУБД [5].

Публикация Chaudhari S. An Overview of Query Optimization in Relational Systems. Рассматриваются методы оптимизации запросов в реляционных системах [6].

3.2 Обзор национальных источников

В России и Украине также множество ученых занимается исследованиями в области оптимизации запросов. Список наиболее популярных публикаций будет приведен ниже.

Исследований в области формирования расписаний для ВУЗа на мой взгляд больше чем иностранных.

Публикация Деканова М. В. Математическая модель и алгоритм построения расписания учебных занятий университета. Представлена математическая модель составления расписания учебных занятий для университета на основе гиперграфа [7].

Публикация Верёвкин В. И., Исмагилова О. М., Атавин Т. А. Автоматизированное составление расписания учебных занятий ВУЗа с учётом трудности дисциплин и утомляемости студентов [8].

Публикация Блажко А. А., Левченко А. Ю., Пригожев А. С. Модели для автоматизированной оптимизации производительности систем управления базами данных. Рассмотрены методы повышения производительности информационных систем, построенных на базе СУБД [9].

Публикация Яковлев Ю. С. О концепции построения и выбора распределенных баз данных информационно-поисковых систем. Предложены основные концептуальные положения подхода к созданию (выбору) распределенных баз данных информационно-поисковых систем с ориентацией на применение инструментальных средств информационной поддержки [10].

3.3 Обзор локальных источников

Студентов, которые в рамках ДонНТУ занимались разработками в области формирования автоматизированного расписания ВУЗа не было найдено, но были похожие темы, однако есть студенты, которые занимались исследованиями в области оптимизации запросов.

Работа магистра ДонНТУ Заславского В.А. Система оптимизации клиентских запросов к серверам распределённой базы данных. В работе идет речь о применении различных методов оптимизации запросов в частности, муравьиный алгоритм [11].

Работа магистра ДонНТУ Бабич К.К. Оптимизации для высоконагруженных реляционных БД и альтернативные решения. В работе идет речь о создании высоконагруженной веб-системы и применении оптимизации реляционных баз данных, для решения задачи множественного доступа и высокой посещаемости [12].

Работа магистра ДонНТУ Афонов И. В. Исследование свойств распределённых систем хранения данных. В работе проводится исследование существующих моделей производительности реплицированных и распределённых баз данных. [13].

Работа магистра ДонНТУ Мошкола А. Я. WEB – ориентированная комплексная система управления факультетом. В работе проектируется WEB – ориентированная комплексная система управления факультетом в который входит формирование расписаний занятий и сессии [14].

Работа магистра ДонНТУ Стародубов В. К. Комплексный реижениринг информационной компьютерной системы факультетского уровня. Целью данной магистерской работы является повышение эффективности работы деканата при увеличении доли автоматизации во взаимодействии между деканатом и студентами [15].

4 АРМ «Расписание занятий в ВУЗе»

Процесс составления расписания занятий реализуются во взаимодействии таких подразделений ВУЗа как: кафедры, деканаты и учебно-методические отделы (УМО). Система расписания получает информацию об учебных планах, структуре и количественном составе студенческих групп в деканатах, а о составе преподавателей, их пожеланиях и возможностях — от кафедр.

4.1 Исследование процесса формирования расписания

На рис. 1 схематично представлена очередность реализации учебных процессов и решения задач, необходимых для формирования расписания, а именно: учебные планы, нагрузка по кафедрам и преподавателям. На базе таких данных возможна реализация задачи по автоматизации формирования базового расписания занятий. Однако, конечное расписание предусматривает вмешательство диспетчера в части его изменения для учета человеческого фактора преподавателей, свободного фонда аудиторий, изменения временной сетки занятий.

Рисунок 1. Схема формирования учебного процесса на семестр.

Весь процесс происходит следующим образом:

1. Кафедры разрабатывает учебные планы, которые утверждаются Учебным отделов ВУЗа;

2. На основе данных имеющихся планов, формируется нагрузка по каждой кафедре в университете;

3. Нагрузка распределяется между преподавателями кафедр;

4. Формируется базовое расписание занятий, учитывая вышеперечисленное.

Опираясь на полученные данные, планируется разработать программный продукт, который будет формировать расписание по ВУЗу, при этом учитывать разные нюансы, такие как:

• Расположение аудитории (корпус, этаж);

• Размер аудитории (вместимость);

• Количество студентов в группе или в потоке групп;

• Временной диапазон учебных занятий (сетка часов по курсам);

• Вид обучения (дневное/заочное);

• Аудиторная нагрузка студента и преподавателя.

Нюансы, которые невозможно решить программно, должны быть включены в ручной режим редактирование расписания в диспетчерских службах.

Таким образом, система «расписание» поддерживает процесс автоматизированного формирования расписания. Система взаимодействует с системой «деканат» для получения информации о группах студентов и учебных планах.

Процесс формирования расписания можно разделить на такие этапы (рис. 1):

1. Составление и утверждение учебных планов по направлениям подготовки и специальностям;

2. Формирование на основе учебных планов рабочих учебных планов для студенческих групп на каждый семестр;

3. Формирование нагрузки кадрового преподавательского состава;

4. Формирование контингента студентов, потоков групп и подгрупп;

5. Формирование аудиторного фонда;

6. Формирование временной сетки занятий с учетом спецификации факультетов;

7. Размещение занятий в соответствии с требованиями и ограничениями.

4.2 Математическая модель формирования расписания

В результате исследования в качестве математической модели формирования расписания был выбран генетический алгоритм. Формирование расписания делится на 7 этапов:

1. На первом этапе случайным образом формируется исходная популяция, состоящая из заданного числа N особей, где каждая особь популяции представляет собой отдельный вариант расписания;

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

3. Третьим этапом генетического алгоритма является скрещивание. На этом этапе основную функцию выполняет оператор кроссинговера. Это языковая конструкция, позволяющая на основе скрещивания хромосом родителей создавать хромосомы потомков;

4. На четвертом этапе применяется оператор мутации. Мутация играет достаточно важную роль в работе генетического алгоритма: вносит дополнительное разнообразие в текущую популяцию и тем самым расширяет пространство поиска оптимального решения;

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

6. На шестом этапе – новое поколение, сформированное в результате применения операторов отбора, скрещивания и мутации, называемое популяцией потомков, заменяет родительскую популяцию, после чего выполняется проверка условия прекращения работы алгоритма. Она основана на использовании приращения функции пригодности, т.е. если в течение нескольких поколений особей приращение значения функции пригодности наиболее “лучшего” индивидуума оказывается незначительным, то работа алгоритма завершается. При выполнении заданного в алгоритме условия останова осуществляется переход к следующему этапу, в противном случае происходит переход ко второму этапу селекции и процесс поиска оптимального решения продолжается;

7. На завершающем этапе среди полученных особей выбирается наилучшая особь, которая и будет являться решением задачи. Под лучшей особью понимается та, у которой значение функции пригодности является минимальным.

5 Оптимизация запросов MS SQL Server 2008

Рассматривая оптимизацию в реляционных СУБД, имеют в виду аспект оптимизации запросов, то есть такой способ выполнения запросов, когда по начальному представлению запроса путем его синтаксических и семантических преобразований вырабатывается процедурный план выполнения, наиболее оптимальный при существующих в базе данных управляющих структурах. Соответствующие преобразования начального представления запроса выполняются специальным компонентом СУБД − оптимизатором, и оптимальность производимого им плана запроса может носить достаточно условный характер. План оптимален в соответствии с критериями, заложенными в оптимизатор, но при этом возможны отклонения от реальной оптимальности.

5.1 Исследование причин снижения производительности MS SQL Server

На снижения производительности может повлиять неисправность оборудования, но если рассматривать сами запросы, то причины снижения производительности – это другой план выполнения запроса, который менее удачный чем был раньше. Причины, по которым SQL Server выбирает другой план выполнения запроса:

• Изменились данные;

• Устарела статистика;

• Недостаточно ресурсов для поиска лучшего плана выполнения;

• Процедура запущена с «плохими» параметрами.

5.2 Способы оптимизации запросов

5.2.1 Изменение структур (создание и изменение индексов и статистик)

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

Есть целый ряд рекомендаций по построению наиболее эффективного индекса для приложения. Относительно столбцов, по которым будет построен индекс, существуют следующие правила:

• Простой индекс – это индекс, использующий значения одного поля таблицы;

• Покрывающие индексы — индексы состоят из столбца данных, по которому собственно построен индекс и указателя на соответствующую строку;

• Селективный индекс – это индексы с малым процентом дублирующихся значений и являются наиболее эффективными;

• Кластерный индекс — кластерный индекс можно сравнить с телефонным справочником, потому как каждый элемент индекса содержит всю информацию, которая вам нужна и не содержит ссылок для получения дополнительных данных.

5.2.2 Подсказки оптимизатору (hints)

Подсказки в запросах

Подсказки запросов переопределяют заданный по умолчанию порядок работы оптимизатора запросов при обработке инструкции запросов. Подсказки запросов могут быть использованы для указания метода блокировки обрабатываемых таблиц, одного или нескольких индексов, выбора операции обработки запросов (просмотр таблицы или поиск в индексе) и других параметров. Подсказки запросов применяются ко всему запросу [16].

Перечень некоторых подсказок:

FAST number_rows

Указывает, что запрос оптимизирован для быстрого получения первых number_rows. строк. Оно должно быть неотрицательным целым числом. После возвращения первых number_rows строк запрос продолжает выполняться и возвращает полный результирующий набор.

KEEP PLAN

Заставляет оптимизатор запросов снизить приблизительный порог повторной компиляции для запроса. Предполагаемое пороговое значение повторной компиляции — это точка, в которой запрос автоматически перекомпилируется, если в таблице при выполнении инструкций UPDATE, DELETE или INSERT изменилось ожидаемое количество индексированных столбцов. Указывая подсказку KEEP PLAN, убедитесь, что запрос не будет часто перекомпилирован при выполнении множественных обновлений в таблице.

KEEPFIXED PLAN

Принуждает оптимизатор запросов не перекомпилировать запрос при изменении статистики. Указывая подсказку KEEPFIXED PLAN, убедитесь, что запрос будет перекомпилирован только при изменении схемы базовых таблиц или если по отношению к ним выполнена процедура sp_recompile.

MAXDOP number

Переопределяет параметр конфигурации max degree of parallelism хранимой процедуры sp_configure и регулятора ресурсов для запросов, в которых указывается этот параметр. Подсказка в запросе MAXDOP может превысить значение, заданное с помощью процедуры sp_configure. Если MAXDOP превышает значение, настроенное с помощью регулятора ресурсов, компонент Database Engine использует значение MAXDOP регулятора ресурсов. Все семантические правила, используемые параметром конфигурации max degree of parallelism, применимы при использовании подсказки в запросе MAXDOP.

Пример использования подсказки MAXDOP:

USE AdventureWorks2008R2 ;

SELECT ProductID, OrderQty, SUM(LineTotal) AS Total

FROM Sales.SalesOrderDetail

WHERE UnitPrice < $5.00

GROUP BY ProductID, OrderQty

ORDER BY ProductID, OrderQty

OPTION (MAXDOP 2);

Табличные подсказки

Табличные подсказки переопределяют поведение оптимизатора запросов по умолчанию на время выполнения инструкции языка обработки данных (DML) указанием способа блокировки, одного или более индексов, операции обработки запроса, например просмотра таблицы или поиска в индексе, или других параметров. Табличные подсказки указываются в предложении FROM инструкции DML и относятся к таблицам и представлениям, указанным в этом предложении [17].

Перечень некоторых подсказок:

INDEX (index_value [,... n ] ) | INDEX = ( index_value)

Синтаксис INDEX() указывает имя или идентификатор одного или более индексов, используемых при обработке инструкции оптимизатором запросов. Альтернативный синтаксис «INDEX =» позволяет задать отдельное значение индекса. Для каждой таблицы можно задать только одно указание индекса.

Если имеется кластеризованный индекс, аргумент INDEX(0) приводит к просмотру кластеризованного индекса, а INDEX(1) — к просмотру или поиску по кластеризованному индексу. Если кластеризованного индекса нет, аргумент INDEX(0) приводит к просмотру таблицы, а INDEX(1) интерпретируется как ошибка.

Если в отдельном списке указаний используются несколько индексов, повторяющиеся индексы пропускаются, а остальные используются для получения строк из таблицы. Порядок индексов в указании индекса имеет значение. Несколько указаний индекса также принудительно выполняют операции И с индексами, и оптимизатор запросов применяет столько условий, сколько возможно для каждого из индексов, к которым он получает доступ. Если коллекция индексов с подсказками не включает все указанные в запросе столбцы, то выборка для получения остальных столбцов выполняется после того, как компонентом Компонент SQL Server Database Engine будут получены все индексированные столбцы.

FASTFIRSTROW

Равнозначен аргументу OPTION (FAST 1).

NOWAIT

Указывает компоненту Database Engine вернуть сообщение сразу после наложения блокировки на таблицу. Аргумент NOWAIT равнозначен указанию SET LOCK_TIMEOUT 0 для конкретной таблицы.

TABLOCK

Указывает, что полученная блокировка применяется на уровне таблицы. Тип полученной блокировки зависит от того, какая инструкция выполняется. Например, инструкция SELECT может потребовать совмещаемой блокировки. Если указано TABLOCK, то совмещаемая блокировка применяется ко всей таблице, а не на уровне страницы или строки. Если также указано HOLDLOCK, то блокировка таблицы удерживается до конца транзакции.

Во время импорта данных в кучу с помощью инструкции INSERT INTO <целевая_таблица> SELECT <столбцы> FROM <исходная_таблица> можно включить оптимизированное ведение журнала и блокировки для инструкции, указав для целевой таблицы подсказку TABLOCK. Кроме того, для базы данных должна быть задана простая модель восстановления или модель восстановления с неполным протоколированием.

При использовании с поставщиком больших наборов строк OPENROWSET для импорта данных в таблицу подсказка TABLOCK позволяет нескольким клиентам параллельно загружать данные в целевую таблицу с оптимизацией записи в журнал и блокировки.

Пример использования подсказки TABLOCK для указания метода блокировки:

USE AdventureWorks2008R2;

UPDATE Production.Product

WITH (TABLOCK)

SET ListPrice = ListPrice * 1.10

WHERE ProductNumber LIKE 'BK-%';

Подсказки в соединении

Подсказки в соединении указывают оптимизатору запросов на выбор определенной стратегии соединения двух таблиц [18].

Перечень подсказок:

LOOP | HASH | MERGE

Задает использование циклов, хэша и операций объединения при соединении в запросе. Использование LOOP | HASH | MERGE JOIN автоматически создает соединение между двумя таблицами. Аргумент LOOP не может указываться вместе с параметрами RIGHT или FULL в качестве типа соединения.

REMOTE

Задает, что операция соединения проводится на сайте в таблице, расположенной справа. Данный аргумент удобно использовать в случае, когда таблица, расположенная слева, является локальной, а справа располагается удаленная таблица. Аргумент REMOTE может использоваться в случае, когда в таблице слева содержится меньшее количество строк, чем в таблице справа.

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

Аргумент REMOTE не может быть использован для сравнения в предикате соединения значений, одно из которых приведено к другим параметрам сортировки с помощью предложения COLLATE.

Аргумент REMOTE может быть использован только при операциях INNER JOIN.

Пример использования HASH:

USE AdventureWorks2008R2;

SELECT p.Name, pr.ProductReviewID

FROM Production.Product p

LEFT OUTER HASH JOIN Production.ProductReview pr

ON p.ProductID = pr.ProductID

ORDER BY ProductReviewID DESC;

5.2.3 Plan Guides

Для запроса можно использовать определенный план выполнения вручную.

5.2.4 Изменение логики запроса, использование промежуточных наборов

Если таблиц в запросе больше восьми, то SQL Server не может перебрать все комбинации, соответственно можно запросы разбивать при этом предварительно, сохраняя результаты в промежуточные таблицы.

5.2.5 Удаление подсказок

Сотрудники компании Microsoft, а именно разработчики оптимизатора SQL Server, советуют не использовать подсказки, так как оптимизатор в современном SQL Server очень «умный» и в большинстве случаев план выполнения запроса без подсказок для оптимизатора работает лучше, чем с указанием подсказок. Поэтому, удаляя подсказки, можно достичь прироста производительности.

5.3 Техника написания «Быстрых запросов»

• Все возможные вычисления делать предварительно. Не нужно нагружать вычисления в запросе, лучше вычислить предварительно и сохранить в переменной;

• Не изменять проиндексированные поля если по ним желателен поиск. Например, если необходимо посчитать количество записей в 2016 году, то лучше найти все записи между началом и концом 2016 года, чем производить поиск по DATAPART, в таком случае идет сканирование по индексу, а при использовании диапазона между началом и концом – поиск происходит по индексу, что гораздо быстрее;

• Отказаться от неявных преобразований;

• Использовать INNER JOIN если только не нужен OUTER;

• Порядок таблиц в запросе – сначала «меньшие потоки данных». Чем меньше из таблицы нужно выбрать строк, тем она должна быть раньше;

• Универсальные запросы работают всегда одинокого плохо;

• Борьба с прослушиванием параметров. Параметры, которые пришли в процедуру не передавались в запрос. Тогда SQL server будет исполосовать более стабильные планы, т.е. он не будет зависеть от того, с какими параметрами первый раз запускали процедуру, тогда план выполнения будет более стабильным.

Выводы

• Быстродействие конкретных запросов зависит от выбранного оптимизатором плана выполнения;

• Главным образом на выбор «правильного» плана выполнения влияет статистика;

• Хорошая оптимизация запроса заключается в том, чтобы оптимизацией занимался сам сервер.

Литература

1. Colorni A., Dorigo M., Maniezzo V. A genetic algorithm to solve the timetable problem // Submitted to computational optimization and applications journal pp 1-24.

2. Wilke P., Gröbner M , Oster N. A Hybrid Genetic Algorithm for School Timetabling // AI 2002: Advances in Artificial Intelligence Volume 2557 of the series Lecture Notes in Computer Science pp 455-464.

3. Karami A.H. , Hasanzadeh M. University course timetabling using a new hybrid genetic algorithm // Computer and Knowledge Engineering (ICCKE), 2012 2nd International eConference on pp 144 – 149.

4. Salwani A., Hamza T. Generating University Course Timetable Using Genetic Algorithms and Local Search // Convergence and Hybrid Information Technology, 2008. ICCIT '08. Third International Conference on (Volume:1 ) pp 254 - 260.

5. Ozsu M. N., Valduriez P. Principles of Distributed Database Systems. Second Edition. New Jersey: Prentice Hall International, 1999. 666 pp.

6. Chaudhari S. An Overview of Query Optimization in Relational Systems // Proceedings of the seventeenth ACM SIGACT-SIGMOD-SIGART symposium on Principles of database systems. New York: SIGMOD, 1998. Pp. 34-43.

7. Деканова М. В. Математическая модель и алгоритм построения расписания учебных занятий университета // Вестник Полоцкого государственного университета. Сер. C, Фундаментальные науки. - 2013. - № 12. - С. 24-33. - Библиогр.: с. 32-33 (34 назв.). - 1 рис.

8. Верёвкин В. И., Исмагилова О. М., Атавин Т. А. Автоматизированное составление расписания учебных занятий ВУЗа с учётом трудности дисциплин и утомляемости студентов // Доклады ТУСУРа, №1 (19), часть 1, 2009 C. 221-255.

9. Блажко А. А., Левченко А. Ю., Пригожев А. С. Модели для автоматизированнной оптимизации производительности систем управления базами данных // Радіоелектрон. і комп'ют. системи. - 2010. - № 7. - С. 24-29. - Библиогр.: 13 назв. - рус.

10. Яковлев Ю. С. О концепции построения и выбора распределенных баз данных информационно-поисковых систем // Мат. машини і системи. - 2003. - № 2. - С. 35-53. - Библиогр.: 24 назв. - рус.

11. Заславский В. А. Система оптимизации клиентских запросов к серверам распределённой базы данных [Электронный ресурс] // Портал Магистров ДонНТУ, 2011г. URL: http://masters.donntu.ru/2011/fknt/zaslavskiy/diss/index.htm (дата обращения: 24.05.2015).

12. Бабич К. К. Оптимизации для высоконагруженных реляционных БД и альтернативные решения [Электронный ресурс] // Портал Магистров ДонНТУ, 2011г. URL: http://masters.donntu.ru/2013/fknt/babich/diss/index.htm (дата обращения: 24.05.2015).

13. Афонов И. В. Исследование свойств распределённых систем хранения данных [Электронный ресурс] // Портал Магистров ДонНТУ, 2011г. URL: http://masters.donntu.ru/2007/fvti/afonov/diss/index.htm (дата обращения: 24.05.2015).

14. Мошкола А. Я. WEB – ориентированная комплексная система управления факультетом [Электронный ресурс] // Портал Магистров ДонНТУ, 2011г. URL: http://masters.donntu.ru/2009/fvti/moshkola/diss/index.htm (дата обращения: 24.05.2015).

15. Стародубов В. К. Комплексный реижениринг информационной компьютерной системы факультетского уровня [Электронный ресурс] // Портал Магистров ДонНТУ, 2011г. URL: http://masters.donntu.ru/2009/fvti/starodubov/diss/index.htm (дата обращения: 24.05.2015).

16. Подсказки в запросах (Transact-SQL) [Электронный ресурс] TechNet // URL: https://technet.microsoft.com/ru-ru/library/ms181714(v=sql.105).aspx (дата обращения: 24.05.2015).

17. Табличные подсказки (Transact-SQL) [Электронный ресурс] TechNet // URL: https://technet.microsoft.com/ru-ru/library/ms187373(v=sql.105).aspx (дата обращения: 24.05.2015).

18. Подсказки в соединении (Transact-SQL) [Электронный ресурс] TechNet // URL: https://technet.microsoft.com/ru-ru/library/ms173815(v=sql.105).aspx (дата обращения: 24.05.2015).

При написании данного реферата магистерская работа еще не завершена. Окончательное завершение: июнь 2017 года. Полный текст работы и материалы по теме могут быть получены у автора или его руководителя после указанной даты.