СОДЕРЖАНИЕ
ВВЕДЕНИЕ
1. СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ
1.1. Возможности систем управления базами данных
1.2. Архитектура систем управления базами данных
1.2.1. Архитектура с файловым сервером
1.2.2. Многотерминальная архитектура (host-терминалы)
1.2.3. Архитектура клиент-сервер
1.2.4. Архитектура с использованием сервера приложений (трехзвенная архитектура)
1.3. Характеристики SQL СУБД
1.3.1. СУБД Oracle
1.3.2. СУБД Microsoft SQL Server
1.3.3. СУБД DB2
1.3.4. СУБД Informix
2. ОСОБЕННОСТИ ЯЗЫКА SQL И СТРУКТУРА ТЕСТОВОЙ БАЗЫ ДАННЫХ
2.1. Особенности языка SQL
2.1.1. Стандарт языка SQL
2.1.2. Язык SQL в различных СУБД
2.2. Модель тестовой базы данных
3. СРАВНИТЕЛЬНЫЙ АНАЛИЗ ЭФФЕКТИВНОСТИ ВЫБОРА ДАННЫХ КОНКРЕТНОЙ СУБД СРЕДСТВАМИ ЯЗЫКА SQL
3.1. Извлечение данных из неиндексированной базы данных
3.2. Извлечение данных из индексированной базы данных
3.3. Анализ результатов
4. ЗАКЛЮЧЕНИЕ
5. СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
Введение
Система управления базами данных – это комплекс программных и языковых средств, необходимых для создания баз данных, поддержания их в актуальном состоянии и организации поиска в них необходимой информации.
Одной из основных задач, стоящих перед системами управления базами данных, является задача оптимизации поиска данных, запрашиваемых пользователем. Современным средством доступа к данным является структурированный язык запросов (SQL – Structured Query Language). Это непроцедурный язык, оперирующий данными на логическом уровне. Выполнение запроса пользователя СУБД необходимо реализовать максимально быстро, для этого в современных СУБД применяются оптимизаторы запросов, механизмы кэширования, поддерживается параллельное выполнение запросов и т.д.
Предметом данной работы является исследование механизма выбора данных, т.е. насколько эффективно разработчики смогли реализовать алгоритм поиска данных. Эффективность поиска можно оценить временем выполнения того или иного запроса.
В первой главе рассматриваются общие понятия о системах управления базами данных, используемые технологии при построении систем управления и возможности наиболее распространенных СУБД, таких как Informix, DB2, MS SQL Server и Oracle.
Вторая глава посвящена описанию языка SQL, используемого в различных СУБД и модели тестовой базы данных. Для каждой СУБД используется своя версия языка SQL, но все версии поддерживают стандарт, разработанный Американским национальным институтом стандартов (American National Standard Institute, ANSI), SQL-92.
В последней главе будет проведено непосредственно исследование скорости выполнения запросов. Здесь будут использованы практически все средства, предоставляемые пользователю языком SQL, для извлечения данных.
1. СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ
Система управления базами данных (СУБД) – это средство централизованного управления базами данных как социальным ресурсом в интересах всей совокупности пользователей и представляет собой набор программных средств, предназначенных для создания общей базы данных для множества приложений, поддержания её в работоспособном состоянии, предоставления пользователю всех допустимых средств для работы с данными и обеспечения эффективного доступа к данным в рамках предоставленных прав доступа.
1.1. Возможности систем управления базами данных
Возможности, которые должна иметь СУБД, можно представить следующим образом:
1. СУБД должна воспринимать и обрабатывать команды пользователей и приложений на выборку, изменение, добавление или удаление данных. Таким образом, в СУБД должен быть компонент, отвечающий за выполнение этих действий, – специальный язык обработки данных. Чаще всего этим языком является язык SQL;
2. СУБД должна иметь возможность принимать данные в исходной форме из различных по своей природе источников и преобразовывать их в форму, соответствующую собственным объектам;
3. СУБД должна иметь функции по обеспечению безопасности, целостности, а в случае повреждения и по восстановлению хранящейся в базе данных информации;
4. В СУБД должен входить компонент, хранящий сведения обо всех объектах, которыми оперирует данная СУБД, и связях между ними, а также сведения о самой СУБД, например, об используемой ею памяти, активных соединениях и т.д.;
5. Желательно, чтобы в СУБД были реализованы механизмы оптимизации, обеспечивающие максимальную эффективность выполнения всех функций СУБД.
1.2. Архитектура систем управления базами данных
Системы управления базами данных различаются как по характеру использования, так и по архитектуре построения. По характеру использования СУБД можно классифицировать как однопользовательские и многопользовательские. Однопользовательские СУБД – это фактически локальная СУБД на отдельной локальной машине. Многопользовательские СУБД – это компонент вычислительной сети, который обеспечивает распределенную обработку данных.
В многопользовательских системах управления базами данных можно выделить следующие три основные архитектуры:
1. архитектура с файловым сервером;
2. многотерминальная архитектура (host-терминалы);
3. архитектура клиент-сервер;
4. архитектура с использованием сервера приложений (трехзвенная архитектура).
1.2.1. Архитектура с файловым сервером
Данная архитектура стала популярной в тот момент, когда персональные компьютеры стали объединяться в локальные сети на основе файлового сервера (например, Novell Netware). Особо популярной данная архитектура являлась в середине-конце 80‑х годов, в период массового объединения персональных компьютеров в локальные вычислительные сети.
Суть этой архитектуры сводится к тому, что на каждом из персональных компьютеров запускается приложение, использующее общие файлы, находящиеся на файловом сервере. Преимуществом такой архитектуры является то, что стало возможным очень быстро и относительно недорого запустить какое-либо однопользовательское приложение в многопользовательском режиме.
По своей сути, такая многопользовательская версия ничем не отличается от однопользовательской версии. Каждый из клиентов работает с общими данными так, как будто это его собственные персональные данные. Однако, быстро выяснилось, что такой вариант многопользовательских систем имеет существенные недостатки. А именно:
1. При интенсивной работе нескольких пользователей трафик по сети сильно увеличивается. Кроме того, существенно замедлялась вся остальная работа по сети, как, например, печать файлов, загрузка программ и т.д.;
2. Так как все действия по обеспечению целостности данных возлагались на прикладную программу, то любая ошибка в ней могла привести к нарушению согласованности данных;
3. Так как подобные системы выросли из персональных компьютеров, которые работали в однозадачном режиме и с одним пользователем, то никаких специальных возможностей для многопользовательского доступа изначально не было. В результате, действия одних пользователей могли привести к затруднению или полной невозможности для других пользователей работать с данной системой. Если какой‑то пользователь открывал файл на модификацию, то другие пользователи, в лучшем случае, могли только читать данные;
4. При случайном аппаратном сбое (наиболее частой причиной было отключение питания) файловый сервер после перезапуска никак не мог проверить корректность имеющихся на нем данных, так как ничего не знал об их структуре. Проверка и восстановление информации в этом случае возлагались на администратора системы, который должен был “перестроить индексы”. Данная процедура зачастую требовала нескольких часов работы;
5. При аппаратном сбое возникала и другая проблема - проблема незакрытых транзакций. Некоторые действия в информационной системе должны выполняться группами. Например, перевод денег с одного счета на другой подразумевает две операции, каждая из которых по отдельности не имеет смысла - надо списать сумму с одного счета (действие номер 1) и приплюсовать к другому счету (действие номер 2). Если аппаратный сбой произойдет между этими действиями, то это не должно привести к пропаже или возникновению “ниоткуда” переводимой суммы;
6. Высокая стоимость администрирования и сопровождения прикладных систем.
Учитывая эти недостатки, были предприняты попытки модифицировать приложения, сделанные на основе файл-серверной архитектуры. Например, для отслеживания транзакций стал использоваться механизм транзакций над файлами, встроенный в сетевую операционную систему NetWare. Это привело к тому, что данное приложение уже не могло быть перенесено в другую среду (Unix или Windows NT). Для обеспечения совместной многопользовательской работы в приложения был введен механизм установки и отслеживания блокировок. Проблема при этом заключалась в том, что обычно в одной информационной системе существует несколько приложений - для построения отчетов, для ввода новых данных, для администрирования содержимого базы и т.д. Данный механизм блокировок надо было согласовать между разными типами приложений, и не забывать про него при разработке новых приложений. Это систему негибкой и тяжелой в разработке и сопровождении.
Если некоторые недостатки использования файл-серверной архитектуры для информационных систем и можно было устранить, пусть даже ценой увеличения стоимости разработки и сопровождения, то такие недостатки, как низкая производительность при интенсивной работе нескольких пользователей и проблемы по обеспечению целостности, оказались принципиальными и непреодолимыми. С этими недостатками мирились, пока критерий низкой начальной стоимости перевешивал все остальное. Однако, стоимость накопленной информации росла, затраты по поддержанию системы тоже возрастали и наступал момент, когда становилась очевидной невозможность использовать файл‑серверную архитектуру для той или иной конкретной задачи.
В тоже время, нельзя говорить о полном изживании файл-серверной архитектуры для информационных систем. Подобная архитектура остается допустимой для систем с небольшим числом пользователем, с небольшими объемами данных и некритичной, недорогой информацией. Например, для общего телефонного справочника небольшой фирмы из 5-10 человек подобная архитектура вполне подходит. Но если в планах есть развитие информационной системы, или будет увеличено число пользователей, или высока ценность информации, использование файл-серверной архитектуры может породить проблемы.
1.2.2. Многотерминальная архитектура (host-терминалы)
Другой вариант архитектуры, тоже очень популярной в свое время для построения информационных систем, называется терминальной или архитектурой “хост-терминал”. В отличие от архитектуры файлового сервера, где вся обработка перенесена как можно ближе к пользователю, а общими являются только данные, терминальная архитектура на рабочем месте пользователя (на терминале) производит только физическое отображение и ввод информации, а вся логика приложения, все данные хранятся на центральном компьютере (хосте). Такая архитектура соответствовала идее больших компьютеров (мэйнфреймов) и была особенно популярна в 70-х и начале 80-х годов.
На центральном компьютере работает общее, единое для всех пользователей приложение. Это приложение работает со своими данными. Каждый из пользователей подключается к информационной системе через систему удаленного терминального доступа (телемонитор). На рабочем месте пользователя производится прием нажатых клавиш, их пересылка на компьютер, получение и отработка команд на вывод информации.
Так как операционные системы, работающие на таких компьютерах, также как и системы программирования и сами компьютеры были изначально разработаны для многопользовательского доступа, неразрешимых проблем с одновременной работой нескольких пользователей не возникало. Не возникало также и особых проблем с пропускной способностью линий связи, так как передавалась только та информация, которую мог воспринять и ввести пользователь.
Однако администрирование и сопровождение терминальных информационных систем было очень дорогим, что стало особенно заметно в сравнении с недорогими персональными компьютерами. Кроме того, терминальные системы, как правило, обеспечивали только достаточно примитивный, алфавитно-цифровой, монохромный интерфейс. Для некоторых задач этого было недостаточно. Существенной проблемой стала и масштабируемость терминальных систем. Увеличение числа пользователей в какой-то момент приводило к необходимости очень существенных финансовых вложений, связанных с модернизацией аппаратного комплекса в целом.
Логическим развитием архитектуры информационных систем, причем развитием на качественно новом уровне, стала архитектура “клиент-сервер”.
1.2.3. Архитектура клиент-сервер
Все современные системы управления базами данных выполнены по архитектуре “клиент-сервер”. Архитектура “клиент-сервер” относится к описанию взаимодействия программ, причем как находящихся на одном компьютере, так и на разных. Данная архитектура получила широкое распространение благодаря широкому внедрению вычислительных сетей. Рассмотрим основные идеи этой архитектуры.
Если вернутся к архитектуре информационных систем на основе идеи файл-сервера, то принципиальным недостатком такой архитектуры являлось разнесение программ, обрабатывающих данные, и самих данных. Основным принципиальным недостатком терминальной архитектуры являлось слишком сильное разнесение пользователя и программы обработки. Архитектура “клиент-сервер” устраняет эти недостатки.
Архитектура “клиент-сервер” подразумевает наличие двух типов программ - программы-клиента и программы-сервера. Программа-клиент является “активной” программой, то есть в ее задачи входит генерация некоторых обращений за услугами к программе‑серверу. Программа‑сервер является пассивной программой, то есть в ее функции входит ожидание запроса от программы-клиента. Когда такой запрос поступает, программа-сервер отрабатывает его и, при необходимости, возвращает программе-клиенту некоторые результаты.
Естественно, взаимодействие между программой-клиентом и программой-сервером должно происходить по четко определенному интерфейсу. В противном случае, они рискуют не понять друг друга.
Программа‑сервер базы данных, является центральной с точки зрения доступа к данным. Именно поэтому большая часть функций, которая должна быть реализована в информационной системе, ложится на сервер базы данных. Перечислим теперь основные функции, которые должна выполнять программа‑сервер базы данных:
1. Выполнять клиентские запросы по извлечению и модификации данных. Это основная функция сервера баз данных. Механизм реализации этой функции может быть скрыт от пользователя, то есть пользователь (а, точнее, работающая с ним программа‑клиент) просто формулирует то, что ему нужно, а сервер базы данных исполняет этот запрос;
2. Обеспечивать одновременный доступ к данным нескольких пользователей. При многопользовательском доступе к данным возникают дополнительные задачи, которые должны быть решены. К таким задачам относится, например, блокировка данных. Блокировка означает, что часть данных в некоторые моменты времени должна быть закрыта для модификации, или даже для чтения другим пользователям. Другой аспект многопользовательского доступа - это распараллеливание доступа, то есть сервер баз данных должен уметь обрабатывать несколько запросов одновременно;
3. Обеспечивать идентификацию пользователей и разграничение прав доступа разных пользователей к различным данным. Таким образом, сервер баз данных должен, во-первых, уметь понимать команды, которые описывают такое разграничение прав, а, во-вторых, в процессе обслуживания запросов пользователя контролировать соблюдение этих разграничений;
4. Обеспечивать целостность и непротиворечивость данных в случае аппаратных и программных сбоев;
5. Защищать данные от несанкционированного доступа. Помимо разграничения доступа для разных категорий пользователей, сервер базы данных должен обеспечивать защиту от попыток получить доступ к данным тем лицам, которые не являются пользователями информационной системы;
6. Предоставлять дополнительные средства администрирования информационной системы. Информационная система должна позволять добавлять или удалять пользователей, настраиваться на новые ресурсы и т.д. Также должна существовать процедура архивирования и восстановления данных.
Как правило, программа‑клиент в системах управления базами данных отвечает за взаимодействие с пользователем. Взаимодействие может строиться на основе каких-либо экранных форм или диалога. На основе команд, введенных пользователем, программа‑клиент формирует запрос к серверу базы данных. После того, как запрос будет обработан и нужные данные найдены и переданы программе‑клиенту, программа‑клиент выдает их на экран.
Могут существовать программы‑клиенты, которые не ведут никакого диалога с пользователем, а выполняют системные задачи. Например, принимают сообщения по почте, извлекают из них данные и заносят в базу данных. В любом случае, программа‑клиент выполняет роль взаимодействия с внешним миром, но не занимается вопросами внутреннего представления и хранения данных.
Но у архитектуры клиент-сервер есть и отрицательные стороны. В последнее время стал возникать синдром "толстого клиента". Это означает, что клиентское приложение имеет размер, сравнимый или даже превышающий размер программы-сервера базы данных. Такое приложение зачастую требует от компьютера-клиента очень больших ресурсов. А клиентских мест в реальной информационной системе, как правило, достаточно много. Поэтому общие затраты на оборудование для компьютеров-клиентов могут быть неоправданно большими. С другой стороны, программы-клиенты в одной информационной системе с большой вероятностью содержат повторяющиеся куски кода. При некоторых видах обработки информации, хранящейся в базе данных, требуется передавать по сети большие объемы информации.
1.2.4. Архитектура с использованием сервера приложений (трехзвенная архитектура)
Классическая архитектура клиент-сервер, как было рассмотрено выше, подразумевает, что есть две программы. Первая, сервер баз данных, следит за сохранностью данных, размещает их на внешнем носителе и исполняет приходящие запросы на поиск и обновление данных. Вторая программа, программа-клиент, обеспечивает интерфейс с пользователем, формирует запросы к серверу базы данных, отсылает их и получает нужные данные, которые показывает пользователю. Программа-клиент и программа-сервер могут физически находиться как на одном компьютере, так и на разных.
Использование архитектуры клиент-сервер позволило ускорить доступ к данным (сервер не занимается интерфейсом и логикой приложений), строить гетерогенные сети (клиент и сервер общаются по сетевому протоколу, и могут функционировать на совершенно различных платформах).
Решением для проблемы «толстого клиента» могло быть проведение обработки непосредственно на том же компьютере, где хранятся данные. Серверы баз данных поддерживают механизм хранимых процедур. Хранимые процедуры принадлежат, хранятся и исполняются на сервере.
Идея сервера приложений заключается в разбиении приложения на две части – клиента и сервера данного приложения. Причем сервер приложений может быть один на большое число приложений. Клиенты общаются с сервером приложений или с серверами приложений (можно иметь несколько серверов приложений), посылая серверу приложений запросы, а получают ответы. Клиенты могут обратиться и непосредственно к серверу базы данных за теми или иными данными. Обращение за данными к серверу базы данных может производить и сервер приложений.
Таким образом, имеется три типа взаимодействующих компонент – сервер базы данных, приложение (клиент) и сервер приложения.
Именно по причине наличия трех компонент (приложение, сервер приложения, сервер баз данных), подобная архитектура называется трехсвязной (английский термин three-tier architecture).
1.3. Характеристики SQL СУБД
На сегодня известно большое число различных серверов баз данных, в которых язык SQL используется как основной язык доступа к данным. Остановимся на следующих четырех ведущих серверных SQL СУБД – Oracle, IBM DB2, Microsoft SQL Server и Informix.
1.3.1 СУБД Oracle
Пакет Oracle наделен самым развитым набором функций для работы с языком Java и доступа к данным через Интернет, системой оптимизации одновременного доступа. Среди основных свойств СУБД Oracle следует отметить такие, как:
1. Высочайшая надежность;
2. Возможность разбиения крупных баз данных на разделы (large-database partition), что дает возможность эффективно управлять гигантскими гигабайтными базами;
3. Наличие универсальных средств защиты информации;
4. Эффективные методы максимального повышения скорости обработки запросов;
5. Индексация по битовому отображению;
6. Свободные таблицы (в других СУБД все таблицы заполняются сразу при создании);
7. Распараллеливание операций в запросе;
8. Наличие широкого спектра средств разработки, мониторинга и администрирования;
9. Ориентация на интернет технологии.
Ориентация на интернет технологии - основной девиз современных продуктов Oracle. В этой связи можно отметить пакеты InterMedia, обеспечивающие обработку данных в мультимедийных форматах, и Jserver, встроенное средство для работы с языком Java, которое объединяет возможности языка Java с возможностями реляционных баз данных (возможность составлять на языке Java не только внутренние программы для баз данных (хранимые процедуры и триггеры), но и разрабатывать компоненты Enterprise JavaBeans и даже запустить их на сервере).
В Oracle реализованы средства для объектно-ориентированного конструирования баз данных, в том числе табличные структуры, допускающие наследование свойств и методов других табличных объектов баз данных, что позволят избежать ошибок при построении баз данных и облегчает их обслуживание.
Также необходимо отметить, что разработанная фирмой Oracle система оптимизации одновременного доступа (multiversioning concurrency) является одной из важнейших характеристик архитектуры Oracle (подобная функция есть лишь в СУБД InterBase). Данная функция позволяет исключить ситуацию, когда одному пользователю приходится ждать, пока другой завершит изменения в содержимом баз данных (т.е. в Oracle отсутствуют блокировки на чтение).
Единственным недостатком данной СУБД является сложность администрирования.
1.3.2. СУБД Microsoft SQL Server
Важнейшие характеристики данной СУБД - это:
1. простота администрирования;
2. возможность подключения к Web;
3. быстродействие и функциональные возможности механизма сервера СУБД;
4. наличие средств удаленного доступа.
В комплект средств административного управления данной СУБД входит целый набор специальных мастеров и средств автоматической настройки параметров конфигурации. Также данная БД оснащена замечательными средствами тиражирования, позволяющими синхронизировать данные ПК с информацией БД и наоборот. Входящий в комплект поставки сервер OLAP дает возможность сохранять и анализировать все имеющиеся у пользователя данные. В принципе данная СУБД представляет собой современную полнофункциональную СУБД, которая идеально подходит для малых и средних организаций.
Необходимо заметить, что SQL Server уступает другим рассматриваемым СУБД по двум важным показателям: программируемость и средства работы. При разработке клиентских БД приложений на основе языков Java, HTML часто возникает проблема недостаточности программных средств SQL Server и пользоваться этой СУБД будет труднее, чем системами DB2, Informix, Oracle или Sybase. Общемировой тенденцией в XXI веке стал практически повсеместный переход на платформу LINUX, а SQL Server функционирует только в среде Windows. Поэтому использование SQL Server целесообразно, только если для доступа к содержимому базы данных используется исключительно стандарт ODBC, в противном случае лучше использовать другие СУБД.
1.3.3. СУБД IBM DB2
В данной СУБД реализованы все известные новаторские технологии механизма баз данных такие, как распараллеливание обработки запроса, полный набор средств тиражирования, сводные таблицы запросов для повышения производительности базы данных, возможности объектно-ориентированного конструирования баз данных и средства языка Java. К этому надо добавить, что система DB2 оснащена полым набором мультимедиа-расширений, позволяющих сохранять текст, звук и видео фрагменты, изображения и географические данные и манипулировать ими. Можно говорить, что по возможностям масштабирования разработанная специалистами IBM технология кластеризации баз данных не имеет аналогов. Эти расширения существенно облегчают процесс разработки приложений для Web, а так же программ, содержащих фотоизображения и объемные текстовые отчеты. Система DB2 вполне конкурентоспособна и в качестве платформы для разработки приложений, так как существует средство Stored Procedure Builder - автоматически преобразовывающее оператор SQL в соответствующий класс Java и включающее его в структуру базы данных. Неплохо реализована и функциональная совместимость с другими СУБД: пакет позволяет использовать разработанную Microsoft спецификацию OLE DB – новый стандарт доступа к базам данных. Средства административного управления СУБД DB2, которые написаны на Java и могут быть получены из Web, заслуживают самой высокой оценки.
В данной СУБД благодаря Index Smart-Guide возможно осуществлять настройку, формируя оптимальные индексы для заданного числа обращений, характеризующего типичную нагрузку на базу данных. DB2 – единственный пакет позволяющий генерировать сводные таблицы, что значительно повышает эффективность работы СУБД в качестве хранилищ данных. Сводная таблица – это временная рабочая область, используемая базой данных для хранения ответов на часто поступающие запросы.
Средства административного управления этой СУБД вполне соответствуют уровню решаемых задач, кроме того, она предоставляет исключительно широкие возможности для работы с мультимедиа-данными и для программирования (чего явно недостает системе Microsoft SQL Server).
Основными недостатками данной СУБД является относительная сложность администрирования и отсутствие (пока) реализаций под популярные серверные операционные системы, например LINUX.
1.3.4. СУБД Informix
Informix Dynamic Server 2000 – построен по архитектуре Dynamic Scalable Architecture (DSA), обеспечивающей мощные средства для параллельной обработки данных. В числе основных характеристик Informix Dynamic Server следует отметить:
1. использование для управления дисковым пространством как средств операционной системы (UNIX или Microsoft Windows NT), так и собственных функций, позволяющих обойти ограничения операционной системы и добиться более высокой производительности, — такое управление дисковым пространством называется Raw Disk Management;
2. управление разделением памяти — поддержку одновременного доступа к данным, находящимся в памяти, нескольким приложениям;
3. динамическое управление потоками (поток – это подзадача, выполняемая в рамках одного из серверных процессов);
4. поддержку фрагментации таблиц и индексов на нескольких дисках (обработка больших таблиц ускоряется пропорционально числу фрагментов, располагаемых на разных дисковых устройствах);
5. распараллеливание запросов (PDQ – Parallel Database Query, выполнение сложного запроса распределяется между всеми наличными процессорами);
6. зеркалирование данных (при выходе из строя диска, на котором находится первичная область, сервер автоматически продолжает работу с оставшимся диском без перехода сервера в режим offline, все операции чтения-записи происходят с зеркальной областью при условии, что она находится на другом диске; восстановление копии на первичном диске после его включения производится в оперативном режиме).
Сервер поддерживает двухфазное завершение транзакций, гетерогенные транзакции (в этом случае в транзакциях может принимать участие и не-Informix сервер, доступный через Informix Enterprise Gateway).
Говоря о сервере фирмы Informix, следует упомянуть и поддержку OLAP: продукт под названием Informix MetaCube поставляется как часть Informix Decision Frontier — комплексного решения для создания хранилищ данных.
2. ОСОБЕННОСТИ ЯЗЫКА SQL И СТРУКТУРА ТЕСТОВОЙ БАЗЫ ДАННЫХ
2.1 Особенности языка SQL
2.1.1 Стандарт языка SQL
В настоящее время язык SQL является общепринятым стандартом при работе с реляционными системами управления базами данных. Язык SQL был официально утвержден в качестве промышленного стандарта организациями по стандартизации ANSI (American National Standard Institute) и ISO/IEC (International Standards Organizations / International Electromechanical Commissions). Последний стандарт, опубликованный ANSI и ISO, часто называется SQL92, также называемый SQL2. Официальное название стандарта такое:
1. ANSI X3.135-1992 «Database Language SQL»;
2. ISO/IEC 9075: 1992, «Database Language SQL».
Стандартный язык SQL был задуман как язык запросов и команд, а не как язык программирования. В 1996 году была принята дополнительная часть стандарта, расширяющая возможности стандартного языка SQL и предоставляющая пользователям средства создания сложных программных конструкций. Это дополнение известно как ISO/IEC 9075-5:1996.
В стандарте ANSI команды SQL объединены по группам, которые называются подразделами:
1. Язык определения данных (DDL – Data Definition Language). В эту группу входят команды, предназначенные для создания, модификации и удаления объектов баз данных, таких как таблицы и представления (представления – это виртуальные таблицы, содержимое которых формируется запросом). К командам этой группы также относятся и команды управления доступом пользователей к объектам базы данных;
2. Язык манипулирования данными (DML – Data Manipulation Language). Эта группа содержит команды, используемые для манипулирования данными в таблицах и представлениях. То есть с помощью команд этой группы выполняется выборка данных, вставка новых, изменение и удаление существующих;
3. Команды управления транзакциями (Transaction Control Statement). Транзакция – неделимая с точки зрения воздействия на базу данных группа операторов, выполняющихся как единое целое, переводящая базу данных из одного целостного состояния в другое. Команды, входящие в эту группу, рассматриваются совместно с командами манипулирования данными и позволяют контролировать изменение данных;
4. Команды управления соединением (Session Control Statement). С помощью команд этой группы можно управлять свойствами соединения;
5. Команды управления системой (System Control Statement). Команды этой группы позволяют управлять свойствами самой СУБД. Однако не в каждой СУБД для этого используются собственно команды. Например, в Microsoft SQL Server эта задача решается с помощью хранимых процедур, изменяющих значения в системных таблицах.
Любая СУБД поддерживает язык определения данных и язык манипулирования данными.
Одной из целей, стоявших при разработке стандартов языка SQL, было преодоление несовместимости диалектов SQL, используемых различными производителями СУБД. Но, пожалуй, сейчас не найдется ни одной коммерческой СУБД, которая бы не отходила от стандарта языка SQL, хотя реализованные в этих СУБД варианты языка SQL часто полностью соответствуют стандарту ANSI SQL92. Уход от стандарта объясняется тем, что производители СУБД снабжают свои модификации языка SQL множеством различных дополнений, расширяющих возможности пользователя как при работе с данными, так и с объектами баз данных и самой СУБД.
2.1.2 Язык SQL в различных СУБД
Рассмотрим особенности языка SQL на примере таких SQL СУБД как IBM DB2, Informix Dynamic Server 2000 и Microsoft SQL Server 2000. Во всех трех СУБД язык SQL поддерживает принятый стандарт SQL92, это является неотъемлемым атрибутом языков, которые используются в данных СУБД. Таким образом, языки, с точки зрения семантики, практически не отличаются, так как в любом из этих трех языков используются основные пять групп, описанные в стандарте.
На примере хранимых процедур и триггеров можно показать особенности языка в разных СУБД.
Основным отличием является синтаксис и имена операторов. Поскольку продукты принадлежат разным фирмам, то соответственно в каждом продукте реализованы свои методы, используемые в основных группах языка. Особенно это различие проявляется в командах управления системой и управлением соединением, но не только. Например, одним из важных элементов любой базы данных является хранимая процедура. Хранимая процедура – это именованный набор команд языка, хранящийся непосредственно на сервере и представляющий собой самостоятельный объект базы данных.
Хранимые процедуры используются для следующих целей:
1. для уменьшения времени на обработку SQL запроса вследствие отсутствия в хранимых процедурах этапов синтаксического анализа и оптимизации;
2. сокращения трафика сети, так как серверу передается только имя процедуры и её параметры;
3. использования одной процедуры несколькими прикладными программами одновременно;
4. обеспечения независимости уровня централизованного доступа к данным;
5. для поддержания целостности базы данных.
Во всех трех рассматриваемых СУБД реализованы средства для создания хранимых процедур с помощью языка SQL.
В сервере Informix это выглядит следующим образом:
CREATE PROCEDURE имя_процедуры ([список параметров]) [;]
Блок операторов на языке SPL
END PROCEDURE.
В продукте фирмы Microsoft MS SQL Server 2000 оператор создания процедуры имеет следующий вид:
CREATE PROC [EDURE] имя_процедуры [:идентификационный номер]
[{@имя_параметра тип_параметра} [OUTPUT] ] [,…n] AS
операторы Transact-SQL.
Здесь параметр OUTPUT показывает, является ли данный параметр возвращаемым значением.
У фирмы IBM в СУБД DB2 создание процедуры осуществляется командой:
CREATE PROCEDURE имя_процедуры
([тип_параметра имя_параметра тип данных параметра])
[Specific особенное имя] EXTERNAL [NAME ‘строка’| идентификатор]
LANGUAGE {C | COBOL | JAVA}
PARAMETER STYLE {DB2SQL | JAVA |GENERAL}.
Ещё одним важнейшим элементом любой базы данных является триггер. Триггер – это специальный тип хранимых процедур, запускаемых сервером автоматически при выполнении тех или иных действий с данными таблицы. Каждый триггер привязывается к конкретной таблице. Все триггеры делятся по типу команд на три группы:
1. INSERT TRIGGER – триггеры этого типа запускаются при попытке вставки данных с помощью команды INSERT;
2. UPDATE TRIGGER – запускаются при попытке изменения данных с помощью команды UPDATE:
3. DELETE TRIGGER – запускаются при попытке удаления данных с помощью команды DELETE.
Помимо классификации триггеров по типу изменения данных, они также классифицируются по типу поведения. Существуют два параметра, определяющих поведение триггера:
1. After – триггер выполняется после успешно завершения команды, изменяющей данные в таблице;
2. Before – в этом случае триггер вызывается до выполнения команд, изменяющих данные.
Создаются триггеры следующим образом:
1. В СУБД Informix:
CREATE TRIGGER имя_триггера
{INSERT ON | DELETE ON | UPDATE ON} имя_таблицы
{тело триггера | опция REFERENCING тело триггера};
2. В СУБД MS SQL Server 2000:
CREATE TRIGGER имя_триггера ON имя_таблицы [с шифрованием]
{ {FOR | AFTER | INSTEAD OF}
{[DELETE][.][INSERT][.][UPDATE ] AS
действия триггера }
3. В СУБД IBM DB2:
CREATE TRIGGER имя_триггера {NO CASCADE BEFORE | AFTER}
{INSERT | DELETE | UPDATE } [опция REFERENCING]
{FOR EACH ROW | FOR EACH STATEMENT } MODE DB2SQL
действия триггера
В рассматриваемых СУБД триггеры отличаются те только синтаксисом создающих их команд. В СУБД IBM DB2 и Microsoft SQL Server 2000 на определенное действие в определенное таблице (например, на добавление данных командой INSERT) можно определить несколько различных триггеров, в то время для СУБД Informix Dynamic Server это невозможно.
Поэтому при переносе модели базы данных из одной СУБД в другую, возможно ситуации, что приходится менять не только синтаксис операторов, но и алгоритмы тех средств, которые предназначены для поддержания целостности базы данных (триггеры и хранимые процедуры).