Двухуровневые модели

Модели клиент-сервер в технологии баз данных.

Сам термин клиент-сервер применяется в архитектуре программного обеспечения, которая описывала распределение процессов выполнения по принципу взаимодействия 2 программных процессов, 1 из которых называется клиентом второй сервером. Ранее приложения не разделялось на части, а выполнялось монолитным блоком. В вычислительной техники нельзя подобные технологию использовать напрямую. Основной принцип технологии клиент-сервер применительно к технологии баз данных заключается в разделении функций стандартного интерактивного приложения на 5 групп имеющих рахличную природу:

1) Функции ввода и отображения данных (презентационная логика);

2) Прикладные функции определяющие основные алгоритмы решения задач приложения (бизнес логика);

3) Функции обработки данных внутри приложения (Database логика);

4) Функции управления информационными ресурсами;

5) Служебные функции, они играют роль связи между первыми четырьмя;

Клиент

База данных

|

Сервер

СУБД

|

През логика

Биз логика

Database логика

Служеб логика

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

Бизнес логика - это логика собственно приложений, то есть часть кода приложения, которая определяет алгоритмы решения некоторых задач, код пишется с помощью языков программирования: С, С++, Java, VB.

Логика обработки данных – это часть когда приложения, которая связана с обработкой данных внутри этого приложения. Данные управляются СУБД. Для обеспечения доступа к данным используется SQL. Обычно операторы SQL встраиваются в языки программирования 3-4 поколения, которые используются для написания кода приложения. Процесс управления данными это, как правило, СУБД, которая обеспечивает хранение и управление базами данных.

Двухуровневые модели являются результатом распределения пяти перечисленных процессов между двумя процессами, которые выполняются на двух платформах на клиенте и на сервере:

1) Модель удалённого управления данными, модель файлового сервера. В этой модели презентационная логика и бизнес логика располагается на клиенте. На сервере располагаются файлы с данными, и поддерживается доступ к файлам. Функции управления информационными ресурсами в этой модели находятся на клиенте. В этой модели файлы базы данных хранятся на сервере. Клиент обращается к серверу с помощью файловых команд, а механизм управления всеми информационными ресурсами, т. е. база метаданных находится на клиенте. Схематически это можно представить в следующем виде:

База данных

(стрелка вверх и вниз)

Сервер

СУФ

Блок данных (стрелка вниз) Файловые команды (стрелка вверх)

Клиент

През логика

Биз логика

Связующие функции

Database логика

СУБД

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

Недостатком этой модели является:

1) Высокий сетевой трафик, т.е. по сети перекачивается множество блоков;

2) Узкий спектр операций манипулирования данными, которые определяются только файловыми командами;

3) Отсутствие адекватных средств к доступа к данным;

2) Модель удалённого доступа к данным;

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

База данных

БМД (базы метаданных)

(стрелка вверх и вниз)

Сервер

Database логика

СУБД

|

SQL запросы (стрелка вверх) Результаты (стрелка вниз)

Клиент

През логика

Биз логика

Связующиеся функции

Достоинством этой модели является:

1) При переносе компонента представления и прикладного компонента клиентский компьютер существенно разгрузил сервер баз данных;

2) Сервер баз данных освобождается от несвойственных ему

3) Резко уменьшается загрузка сети, т.к. они пишутся на языке SQL и объем их данных резко уменьшается

Недостатки такой модели:

1) Запросы на языке SQL при интенсивной работе клиентов могут существенно загрузить сеть;

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

3) Сервер в этой модели играет пассивную роль, так как фикции управления информационными ресурсами должны выполняться на клиенте.

3) Модель сервера баз данных

Для того чтобы избавиться от недостатков моделей удалённого доступа, должны быть соблюдены следящие условия:

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

2) База данных должна отражать некоторые правила предметной области, законы, по которым она функционирует;

3) Необходим постоянный контроль за состоянием базы данных. Отслеживание всех изменений и адекватная реакция на них;

4) Необходимо чтобы возникновение некоторой ситуации в базе данных чётко и оперативно влияло на ход выполнения прикладной задачи;

5) Одно из важнейших проблем СУБД является контроль типов данных;

Данную модель поддерживает большинство современных СУБД (Oracle, Microsoft Access Server, DB2). Основа этой модели составляет механизм хранимых процедур, как средство программирования SQL сервером и механизм триггеров как средство отслеживания текущей ситуации в базе данных. Схематически это будет представлено в следующем виде:

База данных

БМД (базы метаданных)

Триггеры

Хранимые процедуры

(стрелка вверх и вниз)

Сервер

Хранимые процедуры

Обработка общих событий

СУБД

|

Вызов хранимых процедур (стрелка вверх) Результаты (стрелка вниз)

Клиент

Биз логика

През логика

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

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

4) Модель сервера приложения

Эта модель является расширением двухуровневой модели и в ней вводится промежуточный раздел (уровень) между клиентом и сервером. Зарисуем архитектуру этой системы:

Клиент

Презентационная Логика

Связующая Логика

Вызов хранимых процедур (стрелка вниз)

Результат (стрелка вверх)
Сервер приложения

Бизнес логика

(вверх и вниз)
Сервер БД

Хранимые процедуры

DATABASE Логика

(вверх и вниз)
БД

В этой модели компоненты распределены между 3мя исполнителями:

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

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

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

5) Модели серверов баз данных

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

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

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

Pic_3.jpg

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

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

Pic_4.jpg

Дата добавления: 2014-01-20