SQL - Способы взаимодействия с сервером
Способы взаимодействия с сервером
Взаимодействие с сервером СУБД с рабочего места пользователя может строиться различными способами:
Терминал-сервер.
Эти технологии существуют со времен первых вычислительных машин. Вся обработка информации сосредоточена на сервере. Терминал выполняет только функции отображения. К безусловным достоинствам следует отнести низкую суммарную стоимость владения (TCO - Total Cost Of Ownership) рабочих мест. Она обеспечивается собственно невысокой стоимостью терминалов, их высокой надежностью, т.к. там практически нечему ломаться и простотой в обращении. Экономия особенно заметна на больших количествах рабочих мест.
Стоимость обычного рабочего места пользователя, что сейчас, что десять лет назад составляла около $1000. Сервер стоит гораздо дороже и ценообразование здесь гораздо более сложное, но он один, а рабочих мест много, поэтому львиная доля стоимости вычислительной сети предприятия приходится все-таки на рабочие места. В случае если задачи пользователя связаны только с обработкой текстовой информации, а в качестве серверной системы используется Unix, то рабочие места можно сделать на основе терминалов или терминальных эмуляторов, которые обеспечивают невысокую стоимость рабочего места пользователя.
Стоимость хорошего алфавитно-цифрового терминала зарубежного производства колеблется в пределах $300-$500. Не забудьте про терминальный сервер ($1500-$3000) или про терминальный контроллер ($300-$1000). Это недорого, но есть еще более дешевые решения.
У многих организаций скопилось большое количество исправной, но морально устаревшей техники на базе 386 и 486 процессоров. Вместе с тем она могла бы еще послужить. Существуют эмуляторы терминалов, которые на базе такой устаревшей PC (даже с 286 процессором) обеспечивают нормальное рабочее место, более чем достаточное для работы с приложением Oracle или Informix. Стоимость такого рабочего места может составлять 150-200 долларов (из которых $10-15 стоит дешевая сетевая карта на 10 Мбит). А теперь сосчитайте экономию на парке, например, в 50 машин с PII.
Для Oracle7.3 больше всего подошел эмулятор ANSI-терминала ANSIW95, а под Informix лучше всего работает TELNEAT (после некоторой подкрутки).
К недостаткам следует отнести то, что такие системы работают, как правило, в алфавитно-цифровом режиме. Это не всегда хорошо в представлении данных. Скажем, аналитическая часть любой корпоративной информационной системы более эффективно представляется в графическом виде (диаграммы, графики и пр.), чем столбцами цифр.
Но зато текстовый интерфейс позволяет избежать целого пласта ошибок связанных с организацией графического интерфейса на Windows, работы через ODBC и сетевого клиента СУБД. Причем, ошибки бывают подчас просто мистические.
Клиент-сервер.
В этом случае рабочее место клиента располагает собственными вычислительными мощностями и в состоянии самостоятельно обрабатывать данные. При всей заманчивости подобных систем, а возможности современной рабочей станции уступают возможностям сервера незначительно, система получается достаточно громоздкой. Общая надежность, из-за сложности клиентского ПО и проблем в обеспечении корректного взаимодействия клиента с сервером, ниже чем в терминально-серверной системе.
Архитектура "клиент-сервер" при большом объеме манипуляций с данными требует высокоскоростных каналов, и решения на этой основе становятся дорогими при разнесении рабочего места и сервера уже на 1-2 км.
Кроме того, при идентичном количестве рабочих мест архитектура "клиент-сервер", по сравнению с "терминал-сервер" требует большего штата отделов информационно-технического сопровождения, либо большего времени на решение пользовательских проблем.
В терминально-серверной системе администратор, как правило, не бегает по рабочим местам пользователей, и в большинстве случаев рекомендует (каюсь, грешен, сам так делал J ) пользователю по телефону включить и выключить терминал, перерегистрироваться в системе и произвести проблемные действия заново (при этом, все таки, стоит убедиться, что в системе ничего не сломалось). В восьмидесяти процентах случаев это помогает, в оставшихся двадцати процентах можно не торопясь забраться в систему и все аккуратно починить.
В случае с клиент-серверной архитектурой все менее очевидно. Пример из жизни - вам звонит пользователь и радует вас тем, что у него драйвер ODBC выдает что-то вроде "System Error 0x8098A999EC"? При этом пользователь клянется и божится, что он ничего не трогал и не менял. Самое интересное в том, что он, скорее всего, говорит правду. А если пользователей в системе несколько десятков человек? А если несколько сотен?
Толстый и тонкий.
Один из законов философии гласит: "Все развивается по спирали". Клиенты СУБД не исключение. С началом развертывания массовой кампании по переходу на "клиент-сервер" несколько лет назад, клиентская часть для сервера стараниями фирм- производителей распухла так, что иногда по размерам была сопоставима с собственно сервером. Сообразно размерам она и работала - медленно и печально.
В чью светлую голову пришла идея использовать Internet-технологии для построения интерфейса к СУБД, уже, наверное, не узнает никто. Хотя все гениальное - просто. Посудите сами: существует язык, который позволяет более или менее однозначно описать, что надо пользователю показать на экране (HTML, если кто еще не догадался J ), есть средства для этого, типа Netscape Communicator, MSIE и проч.,при помощи которых можно отрисовать вожделенные пользователю окна, меню и многое другое используя вышеупомянутый HTML. И что важно - эти средства есть практически на каждом компьютере. Грех не воспользоваться! А уж приделать к Web-серверу транслятор запросов к серверу СУБД, как поступил Informix (Informix Universal WebConnect), или включить http-сервер непосредственно в дистрибутив сервера СУБД, как поступил, например, Oracle - это уже дело техники.
Оказалась востребована и Java. Именно она позволяет разрабатывать переносимые программные продукты, а также обеспечивает полноценную логику работы.
Как-то само собой получилось, что компьютерная пресса обозвала тонким клиента на основе браузера, а тяжеловесного клиента (Microsoft Excel или Oracle SQL*Forms для Windows, например) - толстым. Безусловно, тонкий клиент имеет большие перспективы, особенно в отношении организации удаленного доступа.
Строители "междумордий" пытались уйти от алфавитно-цифрового терминала и пришли к терминалу в новом графическом качестве. Вот такая вот прикладная философия.
Современные системы СУБД в состоянии предоставить пользователю выгоды как системы "терминал-сервер", так и выгоды системы "клиент-сервер". Оперативная часть систем для увеличения надежности и скорости работы может строиться на основе алфавитно-цифровых терминалов, а аналитическая часть может быть построена на основе или браузеров или толстых клиентов. Где как удобнее.
Правда, иногда производители СУБД поступают не совсем честно. Начиная с версии 8 Oracle перестал поддерживать столь любимые мною алфавитно-цифровые интерфейсы (точнее говоря поддерживает, но только по корпоративному соглашению). Только графика и Java, одним словом, загоняют пинками в рай.
Организация SQL-сервера.
Физическая структура сервера. OLTP и DSS.
Любой SQL-сервер имеет физическую и логическую структуру. Физическая структура - это метод, с помощью которого SQL-сервер хранит свои данные в ОС. На настоящий момент известно 2 варианта хранения данных. С буферизацией средствами ОС, т.е. сервер СУБД держит свои данные в файлах и без буферизации , когда сервер СУБД работает со своими данными на отдельном разделе диска (raw access), и доступ к которому полностью управляется сервером СУБД.
Второй способ быстрее, производители СУБД называют цифру в 2 раза ( хотя на реальной задаче может быть и меньше), так как сервер СУБД работает в обход файловой системы напрямую с разделом , но в этом случае пользователь накрепко привязан к средствам проверки, починки и резервирования данных в комплекте СУБД, т.к. формат такого раздела - "тайна сия велика есть"
Способ хранения в файлах немного медленнее, но более удобен в работе, так как все лежит в обычных файлах, которые резервировать можно теми методами, которым пользователь доверяет.
Один частный случай. В comp.databases.informix один из компьютерных экспертов, эксплуатировавших Informix на Sun Solaris утверждал, что несмотря на то что в Sun Solaris возможна реализация работы через raw devices, получаемая выгода невелика (прирост производительности составляет около ~20-30%). Это связано с тем, что по его словам, файловая система спроектирована достаточно эффективно. Также, он предупредил, что потенциальные проблемы могут перекрыть получившуюся выгоду, при этом описывалась ситуация, когда из-за ошибки при инсталляции на "сырой" раздел могла уничтожаться таблица разделов жесткого диска.
Raw access применяется для работы с OLTP. OLTP(Online Transaction Processing) - онлайновая обработка транзакций. Это такой способ организации работы СУБД при котором система работает с транзакциями небольшими по размерам, но идущими большим потоком, и при этом клиенту требуется от системы максимально быстрое время ответа.
Примером может служить процессинговый центр банка по операциям с платежными картами. Данные информационной транзакции невелики - номер карты, номер банкомата, запрашиваемая сумма умещаются в 100-200 байт, но банкоматов и торговых точек, подключенных к платежной системе, может быть очень много (тысячи штук), поэтому количество транзакций также может быть очень большим. В особенности это касается пиковых часов, после окончания рабочего дня, когда люди идут по магазинам. И при этом система должна сохранять время ответа в пределах нескольких секунд!
Другой способ организации работы СУБД - DSS (Decision Support System) - системы поддержки принятия решений. Эти системы характеризуются тем, что в них преобладают массированные выборки по большому объему данных в режиме "только чтение".
К ним относятся, например, программное обеспечение на основе СУБД для финансового анализа, численных методов оценки деловой активности и прочих характеристик за большие периоды времени и обрабатывающие большие (сотни гигабайт) объемы данных.
Есть еще ряд специфичных приложений в которых работают сервера СУБД.
К ним относятся BPS (Batch processing System) - системы пакетной обработки. Принцип очень похож на работу старых компьютеров: есть некоторая очередь заданий, каждое из заданий выполняется с полным доступом к ресурсам и максимальной эффективностью.
Более интересным и современным является использование серверов СУБД в качестве медиасерверов MMS(Multi Media Servers), т.е. сервер используется для предоставления пользователям доступа к аудио и видео информации. Задача сервера СУБД в данном случае - обеспечение непрерывности мультимедиа потока во избежание рывков видео и прерывания звука вплоть до уровня передачи в канал.
В каждом из этих случаев требуется выполнение настройки ПО сервера, а иногда и установка дополнительных модулей сервера СУБД реализующих эти возможности.
Логическая структура сервера. Составные компоненты.
Логическая структура СУБД - это те объекты СУБД, которыми сервер СУБД непосредственно манипулирует, но не в контексте операционной системы, а контексте базы данных и которые "видны" пользователю (таблицы, представления, индексы, кластеры, сохраненные процедуры и прочие).
Таблица - это основная единица хранения информации в системе. Таблицы в базе данных хранят все пользовательские данные. Кроме того, в системе есть специальные таблицы, к которым в обычных условиях пользователи доступа не имеют или имеют его только на чтение. Это системные таблицы(data dictionary (словарь данных) в терминологии Oracle и SMI (System Management Interface (интерфейс управления системой)) в терминологии Informix), в которых описана логическая структура всей СУБД, в частности, содержатся параметры пользователей, их права доступа, структуры пользовательских таблиц, тексты сохраненных процедур, триггеров и пр.
Данные в таблице хранятся в строках и столбцах. Каждый столбец имеет свое имя и присвоенный столбцу тип данных. Данные в столбце могут быть только одного типа, т.е. если столбец хранит данные типа DATE, то в него нельзя вставить данные типа FLOAT. Строка в таблице, по своей сути сходна с записью данных в файле DBF.
Как правило, СУБД при операциях вставки/модификации данных обеспечивают там, где это возможно, неявное преобразование типов. Т.е. следующие операторы по сути идентичны, хотя во втором случае в столбец типа INTEGER вставляются текстовые данные:
Insert into my_table (column_int)values (911); и Insert into my_table (column_int)values ('911');
С таблицами связаны правила целостности данных (data integrity rules), которые определяются ограничителями (constraint) и триггерами (trigger). О них речь пойдет дальше.
Представления (view (иногда еще называют вид)) - сгруппированные данные из нескольких таблиц. По своей сути представление - это сохраненный запрос с помощью которого пользователю выдается псевдотаблица, т.к. оно непосредственно не содержит данных, а берет их на основе скомпилированного SQL-запроса из базовых таблиц, которые, в свою очередь, тоже могут быть представлениями. Как и в таблицы в представления можно вставлять строки данных, удалять их оттуда и модифицировать, с теми ограничениями, которые действуют для базовых таблиц или для реализации сервера СУБД.
Представления часто используются для того, чтобы:
- Обеспечить конфиденциальность данных. Компилируя соответствующее представление можно скрыть определенные столбцы в таблицах, содержащие конфиденциальную информацию.
- Упростить представление данных, т.к. пользователь работает с представлением как с единой таблицей, в то время как оно может ссылаться одновременно на несколько таблиц.
- Выполнять дополнительную обработку данных из таблиц, скрывая ее от пользователя.
Использование представлений зависит от реализации SQL-сервера. В некоторых системах с представлениями можно работать только на чтение.
Программные модули. Чтобы можно было писать сохраненные процедуры и триггеры, существуют специальные процедурные расширения SQL языков. К программным модулям, вообще говоря, относятся лишь сохраненные процедуры. Сохраненная процедура это некоторый откомпилированный код, который лежит непосредственно на сервере СУБД и используется по мере надобности прикладными программами. Преимущества централизованного хранения очевидны - в случае изменения логики процедуры, она перекомпилируется только на сервере. Клиентские программы при этом не трогаются. Кроме того, использование сохраненных процедур увеличивает производительность системы, т.к. часто используемый код сервер СУБД помещает в кэш.
Синонимы - это алиасы для таблицы, представления или программного модуля. Синоним это ссылка на объект. Он используется для того, чтобы скрыть реальное имя объекта или реального пользователя объекта, обеспечения общего доступа к объекту или прозрачности доступа к объектам удаленной базы данных. Краткий пример - пользовательская программа выполняет запрос из некоторой таблицы XYZ. Если у нас в системе есть синоним XYZ, который указывает на самом деле на таблицу ABC в схеме пользователя JUSTAS на сервере rhka.org , то используется именно таблица JUSTAS.ABC, а не какая-то другая. Предположим, администратор решил вынести таблицу ABC в схему пользователя ALEX на другой сервер по имени center.com. Чтобы не переписывать клиентские программы администратор пересоздает синоним XYZ, который теперь указывает на ALEX.ABC@center.com. Клиентские программы в этом случае работают с данными с другого сервера. Понятно, что для успешной работы клиентской программы структура обоих таблиц должна совпадать.
Индексы создаются для ускоренного поиска по таблице. В целом идеология совпадает с идеями использования индексов в DBF-технологиях, за исключением того, что в случае с SQL, сервер целиком управляет индексом при операциях с таблицей (удаление/вставка/модификация) и нет необходимости специально перестраивать или корректировать индексы. Более того, при обработке запроса SQL-сервер сам может выбирать подходящий индекс из доступных для данной таблицы. Например, таблица XYZ содержит столбцы A,B,C,D,E,F,G и имеет 3 индекса по полям A,B,C затем D,E,F и F,G. При запросе select a,b,c from xyz будет задействован первый индекс. При запросе select f,g from xyz будет задействован третий индекс. При запросе select a,g from xyz индексы не будут задействованы вообще (строго говоря, это зависит от реализации), но запрос отработается, хотя и с меньшей скоростью. Последний случай крайне нежелателен в случае, если таблица содержит несколько сотен тысяч строк, в этом случае замедление будет очень заметно. Но обычно запросы, с которыми клиентские программы работают с сервером, известны заранее, поэтому на сервере должен быть создан соответствующий индекс.
Индексирование поддерживается всеми SQL-серверами.
Кластер (cluster). Предположим, что есть группа независимых таблиц, между которыми есть некоторая логическая связь. Например, одна таблица содержит характеристики клиентов, вторая содержит описания заказов этих клиентов , Наличие этой связи приводит к тому, что вероятность одновременного запроса данных из нескольких таблиц этой группы весьма велика. В случае если таблицы большие по размерам, то при отдельном их хранении на диске, суммарное время запроса также будет большим. Чтобы этого избежать применяется связка таблиц в кластеры. В кластере строки из разных таблиц чередуются. Такое хранение приводит к тому, что суммарное время запроса по нескольким таблицам существенно уменьшается. Для дальнейшего увеличения скорости запросов может использоваться индексирование или хеширование кластера. Использование кластеров зависит от реализации SQL-сервера. Они поддерживаются как Oracle7, так и Infromix DS. Практически кластеры используются редко, это связано с рядом ограничений.
Последовательность (sequence). Этот объект СУБД специфичен для Oracle. Последовательности представляют собой специальные объекты базы данных для генерации последовательных значений. Каждое следующее обращение к последовательности увеличивает ее текущее значение на шаг, определяемый при создании последовательности. Использование последовательностей зависит от реализации SQL-сервера. В Infromix DS последовательностей нет. Там используется специальный тип данных SERIAL, который при последовательной вставке в таблицу генерирует только целочисленные значения с шагом 1.