Достоинства SQL,

SQL – это легкий для понимания язык и в то же время универсальное программное средство управления данными.

Успех языку SQL принесли следующие его особенности:

- независимость от конкретных СУБД;

- переносимость с одной вычислительной системы на другую;

- наличие стандартов;

- поддержка со стороны компании Microsoft (протокол ODBC);

- реляционная основа;

- высокоуровневая структура, напоминающая английский язык;

- возможность выполнения специальных интерактивных запросов;

- обеспечение программного доступа к базам данных;

- полноценность как языка, предназначенного для работы с базами данных;

- возможность динамического определения данных;

- поддержка архитектуры клиент/сервер.

Все перечисленные выше факторы явились причиной того, что SQL стал стандартным инструментом для управления данными на персональных компьютерах, мини-компьютерах и больших ЭВМ. Ниже эти факторы рассмотрены более подробно.

5.3.1. Независимость от конкретных СУБД.

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

5.3.2. Переносимость с одной вычислительной системы на другие.

Поставщики СУБД предлагают программные продукты для различных вычислительных систем: от персональных компьютеров и рабочих станций до локальных сетей, мини-компьютеров и больших ЭВМ. Приложения, созданные с помощью SQL и рассчитанные на однопользовательские системе, по мере своего развития могут быть перенесены в более крупные системы. Информация из корпоративных реляционных баз данных может быть загружена в базы данных отдельных подразделений или в личные базы данных. Наконец, приложения для реляционных баз данных можно вначале смоделировать на экономичных персональных компьютерах, а затем перенести на дорогие многопользовательские системы.

5.3.3. Стандарты языка SQL.

Официальный стандарт языка SQL был опубликован Американским институтом национальных стандартов (American National Standards Institute – ANSI) и Международной организацией по стандартам (International Standards Organization – ISO) в 1986 году и значительно расширен в 1992 году.

5.3.4. Протокол ODBC и компания Microsoft.

Компания Microsoft рассматривает доступ к базам данных как важную часть своей операционной системы Windows. Стандартом этой компании по обеспечению доступа к базам данных является ODBC (Open Database Connectivity – взаимодействие с открытыми базами данных) – программный интерфейс, основанный на SQL. Протокол ODBC поддерживается наиболее распространенными приложениями Windows (электронными таблицами, текстовыми процессорами, базами данных и т.п.), разработанными как самой компанией Microsoft, так и другими ведущими поставщиками. Поддержка JDBC обеспечивается всеми ведущими реляционными базами данных. Кроме того, ODBC опирается на стандарты, одобренные консорциумом поставщиков SQL Access Group, что делает ODBC как стандартом де-факто компании Microsoft, так и стандартом, независимым от конкретных СУБД.

5.3.5. Реляционная основа.

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

5.3.6. Высокоуровневая структура, напоминающая английский язык.

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

5.3.7. Интерактивные запросы.

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

5.3.8. Программный доступ к базе данных.

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

5.3.9. Различные представления данных.

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

5.3.10. Полноценный язык для работы с базами данных.

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

5.3.11. Динамическое определение данных.

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

5.3.12. Архитектура клиент/сервер.

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

5.4. Пятое поколение: мультимедийные базы данных (1995 г. - …)

Реляционные системы внесли много усовершенствований в облегчение использования: графические интерфейсы, клиент-серверные приложения, распределенные базы данных, параллельный поиск данных и добывание данных. Тем не менее около 1985 года исследовательское сообщество начало рассматривать вопросы, выходящие за рамки реляционной модели. Традиционно существовало четкое разделение программ и данных. Этот подход хорошо работал, пока речь шла только о таких данных как числа, символы, массивы, списки или множества записей. По мере появления новых приложений разделение программ и данных стало проблематичным. Приложениям требовалось дать данным поведение. Например, если данные представляли сложный объект, то методы поиска, сравнения и манипулирования данными становились специфичными для типов данных “документ”, “графический образ”, “звук” или “карта”.

 

Чтобы приблизиться к современному состоянию технологии управления данными, имеет смысл описать два крупных проекта управления данными, в которых используются предельные возможности сегодняшней технологии. Система Earth Observation System/Data Information System (EOS/DIS) разрабатывалась агентством NASA и его подрядчиками для хранения всех спутниковых данных, которые начали поступать со спутников серии “Миссия к планете Земля” с 1997 г. Объем базы данных, включающей данные от удаленных сенсорных датчиков, бу-дет расти на 5 Тбайт в день (Тбайт – это 1 млн.Гбайт). К 2007 году размер базы данных вырастет до 15 Пентабайт. Это в тысячу раз больше объема самых больших сегодняшних оперативных баз данных. NASA желает, чтобы эта база данных была доступна каждому в любом месте в любое время. Любой человек сможет производить поиск, анализ и визуализацию данных из этой базы данных. Для построения EOC/DIS потребуются наиболее развитые методы хранения, управления, поиска и визуализации данных. Большая часть данных будет обладать пространственными и временными характеристиками, так что для системы потребуются существенное развитие технологии хранения данных этих типов, а также библиотеки классов для различных научных наборов данных. Например, для этого приложения потребуется библиотека для определения снежного покрова, каталога растительных форм, анализа облачности и других физических свойств образов LandSat. Эта библиотека классов должна легко подключаться к менеджеру данных EOS/DIS.

Другим впечатляющим примером базы данных является возникающая всемирная библиотека. Многие ведомственные библиотеки открывают доступ к своим хранилищам в режиме on-line. Такой вид публикации поднимает трудные социальные вопросы по поводу авторских прав и интеллектуальной собственности и заставляет решать глубокие технические проблемы. Пугают размеры и многообразие информации. Информация появляется на многих языках, во многих форматах данных и в громадных объемах. При применении традиционных подходов к организации такой информации (автор, тема, название) не используются мощности компьютеров для поиска информации по содержимому, для связывания документов и для группирования сходных документов. Обнаружение информации, нахождение требуемой информации в море документов, карт, фотографий, звука и видео представляет собой захватывающую и трудную проблему.

5.5. Основные требования.

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

5.5.1. Расширяемость.

Расширяемость – это свойство системы, которое допускает предсказуемую поддержку дополнительных пользователей, более высокую производительность, пропускную способность и т.д. путем добавления вычислительных ресурсов и без изменения приложений и административного сопровождения. Существует два способа расширения сервера баз данных: горизонтальный и вертикальный. Горизонтальное может быть получено, когда несколько серверов действуют независимо и делят рабочее пространство. Этот метод более применим для слабосвязанных систем и распределенных баз данных, однако он требует дополнительной административной поддержки. Вертикальное расширение, затрагивающее отдельный сервер, может быть достигнуто путем добавления к платформе дополнительных ресурсов, как, например, более быстрых процессорных элементов или дополнительных процессоров, с целью уменьшения времени отклика или увеличения пропускной способности. Поддержка сервера баз данных для вертикального расширения не должна требовать включения дополнительных программных модулей, поскольку это увеличивает административные издержки и понижает предсказуемость. Независимо от того, какое расширение используется, вертикальное или горизонтальное, его эффективность зависит от того, как хорошо использует программное обеспечение сервера доступные ресурсы.

а) Многопроцессорность.

Системы SMP часто используются для получения вертикального расширения, поскольку они допускают добавление процессорных элементов без изменения всей платформы. Системы MPP также могут быть использованы для вертикального расширения, но сегодня их применение ограничивается только специализированными приложениями. Две основных проблемы для SMP-архитектуры сервера баз данных – масштабируемость и прозрачность.

Масштабируемость означает, что архитектура сервера баз данных не специализирована некоторым заданным числом процессоров; с одинаковым успехом она должна позволять поддерживать один процессор или полдесятка процессоров, не требуя при этом повторной установки, выключения при изменении конфигурационных параметров или дополнительных программных опций. Такая архитектура будет одинаково полезна и эффективна для случая одного процессора, нескольких процессоров (SMP) или даже многих процессоров (MPP). Пользователю нет необходимости специально заботиться о программной обеспечении, ориентированном на конкретную платформу.

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

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

б) Расширяемость архитектуры.

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

5.5.2. Производительность.

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

а) Распараллеливание алгоритмов.

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

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

Если каждая из операций баз данных разработана таким образом, что она управляется запросом (т.е. подход потока данных), сервер может использовать параллелизм, одновременно выполняя разные операции баз данных. Например, операция, выбирающая записи по значению поля, может выполняться одновременно с операцией доступа к записям с диска и не должна ждать, пока все записи будут считаны. Аналогично, выбранные записи могут быть загружены для сортировки для начального разбиения в соответствии с ключом сортировки, пока выполняются операции выбора и доступа. Вдобавок к независимости реализации от степени параллелизма проблемно-ориентированный подход допускает прозрачное включение новых существенно параллельных алгоритмов. Это позволяет использовать современные достижения в области алгоритмов для увеличения производительности.

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

б) Многопроцессорная обработка с помощью нитей.

Метод обработки запросов пользователя, с которым связаны наименьшие накладные издержки, называется многопроцессорной обработкой с помощью нитей (отличается от моделируемой обработки). Нить как вариант процесса представляет собой управление контекстом, работающее под управлением одного процесса, он может быть либо порожден внутри процесса (например, сервер базы данных), либо средствами ОС. Переключатель контекста процесса уровня ОС – это более дорогое действие, чем переключатель уровня самой нити, так же как и операции создания и уничтожения процессов по сравнению с аналогичными операциями для нитей. В принципе, нити могут выполнять одновременные задания с помощью саморазмножения, создавая нити, похожие на подпроцессы. Поскольку ОС не требуется создавать, распределять или прерывать множественные процессы, накладные расходы многопроцессорных баз данных, использующие нити, будут ниже, чем для других архитектур.

в) Оптимизация.

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

г) Управление ресурсами.

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

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

д) Параллельная обработка запросов.

Параллельная обработка запросов позволяет решить проблему низкой производительности для сложных запросов и объемных баз данных. Получая доступ и обрабатывая данные параллельно, параллельная обработка запросов может привести к существенному увеличению производительности для DSS и пакетной обработки. Такое увеличение производительности позволяет включать самые сложные запросы в транзакции читать/писать без ущерба целостности данных и изоляции транзакций. При подходящей величине времени отклика очереди DSS, которые были бы невозможны на традиционных системах, становятся возможными и не конкурируют разрушительным образом с приложениями OLTP.

5.5.3. Сопровождение в оперативном режиме.

В идеальном случае утилиты сопровождения должны поддерживать непрерывные операции, с помощью которых система должна редуцировать или даже исключать плановые и неплановые неполадки. Часто в реляционных СУБД приходится выходить в режим off-line, чтобы выполнить некоторую утилиту. Утилиты для загрузки, резервирования, восстановления, проверки целостности, реорганизации индексов и т.д. должны допускать выполнение в оперативном режиме. Если происходит сбой во время выполнения этих операций, утилита не должна быть запущена с начала операции. Например, могут выполняться периодические проверки или даже полное протоколирование, позволяющее запустить утилиты с места сбоя. Другие возможности, так как автоматическое архивирование и архивирование в оперативном режиме полных протоколов, автоматический перезапуск (без дополнительных операторов), управляемые времена перезапуска системы имеют также большое значение; это минимальный набор тех операций, которые могут потребовать, чтобы реляционная СУБД вошла в режим off-line.

5.5.4. Устойчивость.

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

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

Избыточность по данным возникает в двух формах: программного зеркалирования и копирования.