Добавлен: 26.06.2023
Просмотров: 66
Скачиваний: 2
Рисунок 1.3 – Модель сервера баз данных
На практике часто используется смешанные модели, когда поддержка целостности базы данных и некоторые простейшие прикладные функции выполняются хранимыми процедурами (DBS-модель), а более сложные функции реализуются непосредственно в прикладной программе, которая работает на компьютере-клиенте (RDA-модель). Так или иначе, современные многопользовательские СУБД опираются на RDA- и DBS-модели и при создании ИС, предполагающем использование только СУБД, выбирают одну из этих двух моделей, либо их разумное сочетание.
В AS-модели процесс, выполняющийся на компьютере-клиенте, отвечает, как обычно, за интерфейс с пользователем (то есть реализует функции первой группы). Обращаясь за выполнением услуг к прикладному компоненту, этот процесс играет роль клиента приложения (Application Client - AC). Прикладной компонент реализован как группа процессов, выполняющих прикладные функции и называется сервером приложения (Application Server - AS). Все операции над информационными ресурсами выполняются соответствующим компонентом, по отношению к которому AS играет роль клиента. Из прикладных компонентов доступны ресурсы различных типов - базы данных, очереди, почтовые службы и др.
Рисунок 1.4 – Модель сервера приложений
RDA- и DBS-модели опираются на двухзвенную схему разделения функций. В RDA-модели прикладные функции приданы программе-клиенту, в DBS-модели ответственность за их выполнение берет на себя ядро СУБД. В первом случае прикладной компонент сливается с компонентом представления, во втором - интегрируется в компонент доступа к информационным ресурсам. В AS-модели реализована трехзвенная схема разделения функций, где прикладной компонент выделен как важнейший изолированный элемент приложения, для его определения используются универсальные механизмы многозадачной операционной системы, и стандартизованы интерфейсы с двумя другими компонентами. AS-модель является фундаментом для мониторов обработки транзакций (Transaction Processing Monitors - TPM), или, проще, мониторов транзакций, которые выделяются как особый вид программного обеспечения.
В период создания первых СУБД технология «клиент-сервер» только зарождалась. Поэтому изначально в архитектуре систем не было адекватного механизма организации взаимодействия такого типа, в современных же системах он жизненно необходим.
Чтобы понять проблему, рассмотрим эволюцию серверов баз данных. Первое время доминировала модель, когда управление данными (функция сервера) и взаимодействие с пользователем были совмещены в одной программе. Затем функции управления данными были выделены в самостоятельную группу - сервер, однако модель взаимодействия пользователя с сервером соответствовала парадигме «один-к-одному», то есть сервер обслуживал запросы ровно одного пользователя (клиента), и для обслуживания нескольких клиентов нужно было запустить эквивалентное число серверов. Выделение сервера в отдельную программу - революционный шаг, позволяющий, в частности, поместить сервер на одну машину, а программный интерфейс с пользователем - на другую, осуществляя взаимодействие между ними по сети. Однако необходимость запуска большого числа серверов для обслуживания множества пользователей сильно ограничивала возможности такой системы.
Проблемы, возникающие в модели «один-к-одному», решаются в архитектуре систем с выделенным сервером, способным обрабатывать запросы от многих клиентов. Сервер единственный обладает монополией на управление данными и взаимодействует одновременно со многими клиентами. Логически каждый клиент связан с сервером отдельной нитью (thread) или потоком, по которому пересылаются запросы. Такая архитектура получила название многопотоковой (multi-threaded).
Она позволяет значительно уменьшить нагрузку на операционную систему, возникающую при работе большого числа пользователей. С другой стороны, возможность взаимодействия с одним сервером многих клиентов позволяет в полной степени использовать разделяемые объекты (начиная с открытых файлов и кончая данными из системных каталогов), что сильно уменьшает потребности в памяти и общее число процессов операционной системы. Например, системой с архитектурой «один-к-одному» будет создано 50 копий процессов СУБД для 50 пользователей, тогда как системе с многопотоковой архитектурой для этого понадобиться только один сервер.
Однако такое решение создает новую проблему. Так как сервер может выполняться только на одном процессоре, возникает естественное ограничение на применение СУБД для мультипроцессорных платформ. Если компьютер имеет, например, четыре процессора, то СУБД с одним сервером используют только один из них, не загружая оставшиеся три.
В некоторых системах эта проблема решается заменой выделенного сервера на диспетчер или виртуальный сервер (virtual server), который теряет право монопольно распоряжаться данными, выполняя только функции диспетчеризации запросов к актуальным серверам. Таким образом, в архитектуру системы добавляется новый слой, который размещается между клиентом и сервером, что увеличивает трату ресурсов на поддержку баланса загрузки (load balancing) и ограничивает возможности управления взаимодействием «клиент-сервер». Во-первых, становится невозможным направить запрос от конкретного клиента конкретному серверу, во-вторых, серверы становятся равноправными - невозможно устанавливать приоритеты для обслуживания запросов.
Современное решение проблемы СУБД для мультипроцессорных платформ заключается в возможности запуска нескольких серверов базы данных, в том числе и на различных процессорах. При этом каждый из серверов должен быть многопотоковым. Если два эти условия выполнены, то есть основание говорить о многопотоковой архитектуре с несколькими серверами (multi-threaded, multi-server architecture).
Высокопроизводительный, экономичный, многоплатформенный сервер баз данных InterBase представляет собой экономичную СУБД с обработкой транзакций, которую используют миллионы пользователей во всем мире. Сочетая легкость установки, автоматическое восстановление после аварийных отказов и минимальные требования к администрированию, InterBase является наиболее подходящим решением для встраивания в тиражируемые приложения. Обладая поддержкой многопроцессорного режима и сложной архитектурой, InterBase идеально подходит для многофункциональных бизнес приложений, обслуживающих большое количество пользователей. Графический пользовательский интерфейс IBConsole включает монитор производительности, одновременно отслеживающий состояние нескольких серверов и баз данных InterBase.
В основе InterBase находится многоуровневая архитектура управления несколькими версиями, предлагающая весомые преимущества в надежности, производительности, эффективности труда разработчиков и постоянном сопровождении. InterBase освобождает разработчиков от решения проблем совместимости и задач памятью, и наряду с этим обеспечивает немедленное восстановление после аварийных отказов.
InterBase представляет собой идеальное решение для установки в условиях отсутствия администратора баз данных или IT поддержки. Автоматическое восстановление после аварийных сбоев и автоматизированные процессы управления учетными записями пользователей, оперативное резервное копирование и автоматизация других задач сопровождения позволяют существенно уменьшить потребность в администрировании. Функции автоматической настройки включают оптимизацию запросов на основе затрат и автоматическую «сборку мусора». Динамическая перестройка структур индекса улучшает производительность и уменьшает потребность в администрировании.
СУБД InterBase не привязывает разработчиков к определенному языку программирования или к какой-либо платформе. InterBase обеспечивает межплатформенную совместимость систем Windows, Linux, Solaris и Java, при этом не требуется перекодирование и поддержка нескольких серверных частей СУБД.
Высокая экономичность и универсальность мощной встраиваемой СУБД Borland InterBase – это широко распространенная СУБД для потребительских приложений, используемых тысячами конечных пользователей.
Клиент-серверные компоненты среды Delphi
Разработка распределенных корпоративных систем доступа к данным – одна из наиболее высокотехнологических и динамично развивающихся областей современной индустрии ПО. Именно здесь сосредоточены усилия разработчиков прикладного ПО.
Мощные серверы должны обеспечивать бесперебойный доступ к данным сотен клиентов одновременно. При этом клиентское ПО установлено на разных аппаратных платформах и работает под управлением разных ОС. Пользователи могут находится в корпоративной сети, обращаться к серверу через Internet, intranet или по радиоканалу.
Для создания распределенных систем разработаны подходы на основе ряда технологических решений. Используются технологии COM, OLEnterprise, сокеты TCP\IP, Microsoft Transaction Server, CORBA.
Для работы с корпоративными БД используются многоуровневые приложения, т.к. эффективное взаимодействие с БД многих пользователей может обеспечить только ПО промежуточного уровня. Серверы приложений решают задачи управления запросами клиентов и результатами запросов, разграничения доступа, сохранения целостности данных т.д. Причем и в этой сфере существуют готовые решения на основе вышеперечисленных технологий.
В Delphi можно создавать приложения для распределенных систем на основе всех перечисленных подходов. Для этого предназначена специальная технология MIDAS (Multi-tired Distributed Application Service) – Службы многоуровневых распределенных приложений. Она обеспечивает создание приложений для распределенных систем баз данных на основе единого подхода.
MIDAS – это технология компании Borland, разработанная для создания многоуровневых приложений баз данных. Применение данной архитектуры позволяет быстро разрабатывать простые в сопровождении и установке, надежные распределенные БД. Трехуровневое приложение баз данных содержит несколько компонентов (слоев):
а) Слой БД. Хранит данные. Выполняет функции хранения информации, обеспечения целостности и непротиворечивости данных. Пример – локальные (dBase, Paradox) и серверные БД (Oracle, Sybase, MS SQL), текстовые файлы и т.д. В нашем случае это InterBase.
б) Слой бизнес логики (сервер приложений) - это программа, обеспечивающая доступ клиентов к информации. На этом слое вводится понятие сервиса, как некоей услуги, поставляемой клиенту (например, получение данных об остатке денег на счете, как частный случай из реляционной БД). В этом слое реализуются правила и алгоритмы обработки информации, отражающие поведение реального моделируемого объекта (бизнес правила). Например, проверка остатка денег на не отрицательность, перевод денег со счета на счет.
в) Презентационный слой (тонкий клиент). Задача этого слоя, используя сервисы слоя бизнес логики, предоставлять пользователям запрошенную информацию в удобной и приятной во всех отношениях форме. Может быть выполнен в виде традиционного exe-файла. Также в качестве тонкого клиента можно использовать Web-браузер.
Применение данной схемы позволяет создать клиентское приложение, которое практически не требует настройки и сопровождения, вся логика работы с БД сосредоточена в среднем слое (сервере приложений). Соответственно при доработке алгоритмов доступа к БД необходимо лишь переустановить сервер приложений.
MIDAS предназначен для обеспечения связи между слоем бизнес логики и презентационным слоем. Он позволяет организовать взаимодействие тонкого клиента с сервером приложений. При этом сервер приложений взаимодействует с реляционной БД (чаще всего данные хранятся именно в этой форме) как и обычные приложения работы с БД, разработанные в Delphi.
Тонкий клиент для конечного пользователя ничем не отличается от обычного (толстого) клиента БД. Разница в том, что толстый клиент через BDE, ADO, компоненты прямого доступа к серверам БД и другие библиотеки работает с БД, а тонкий клиент взаимодействует с сервером приложений, используя MIDAS. Сервер приложений скрывает от клиента детали доступа и обработки БД. На компьютере с тонким клиентом не нужно устанавливать и настраивать BDE, ADO, клиентскую часть сервера БД. Необходимо лишь иметь небольшие по объему dll, которые легко переносить вместе с exe файлом тонкого клиента. В качестве тонкого клиента может использоваться и Web-браузер.
Структурированный язык запросов – SQL
На рубеже 70-х годов XX века Е.Ф. Кодд опубликовал базовую концепцию реляционной модели хранения данных, в которой было предусмотрено создание реляционных языков, осуществляющих управление данными. Одной из ключевых реализаций реляционных языков стал структурированный язык запросов (SQL, Structured Query Language). Впервые о языке SQL заговорили в 1974 году благодаря Д. Чамберлине, работавшему вместе с Коддом в лаборатории IBM. Первоначально язык назывался несколько иначе – SEQUEL (Structured English Query Language), поэтому от программистов, стоявших у истоков SQL, и сейчас можно услышать сокращение «СИКвЕЛ» вместо «ЭсКюЭль». SEQUEL был переименован в SQL по юридическим соображениям; видимо, аббревиатура SEQUEL была уже кем-то захвачена.
На данный момент общепризнанным считается стандарт SQL-92, принятый в 1992 году и имеющий официальное название: ISO (1992). Database Language SQL (ISO 9075:1992(E)). International Organization for Standardization. Практически любая серьезная компания, разрабатывающая СУБД, поддерживает требования SQL-92. К наиболее известным клиент–серверным СУБД стоит отнести Oracle, INGRES, Informix, Sybase, SQLbase, Microsoft SQL Server, DB2 и Interbase.
В первоначальной минимальной нотации SQL был нацелен на решение трех базовых задач: