АРХИТЕКТУРЫ УДАЛЕННЫХ БАЗ ДАННЫХ

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

1.1. Термины и определения

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

Рассмотрим термины, применяемые в системах управления распределенными базами данных.

Архитектура БД — организация взаимодействия аппаратных средств.

Виды архитектуры БД: клиент—сервер, двухуровневая и трех­уровневая клиент-сервер, файл —сервер.

Архитектура ODBC (Open DataBase Connectivity) — откры­тый интерфейс доступа к базам данных, т.е. взаимодействие про­цессора (ядра) базы данных Jet с внешними источниками дан­ных.

Модели данных — схемы, характеризующие базы данных с раз­ных сторон с целью определить оптимальное построение инфор­мационной системы.

Ядро базы данных — внутренняя структура СУБД, обеспечива­ющая доступ ко всем компонентам базы данных. В новых версиях СУБД Access называется Microsoft Data Engine (MSDE); в ранних версиях ядро базы данных называлось машина базы данных Microsoft Jet. Ядро базы данных обеспечивает поддержку символов различ­ных алфавитов, синтаксис языка SQL и другие средства обработ­ки различных типов данных.

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

Запрос — процесс обращения пользователя к БД с целью вве­сти, получить или изменить информацию.

Транзакция — последовательность операций модификации дан­ных в БД, переводящая ее из одного непротиворечивого состоя­ния в другое непротиворечивое состояние.

логическая структура бд — определение БД на физически не­зависимом уровне, что ближе всего соответствует концептуаль­ной ее модели.

топология бд , или структура распределенной бд , — схема рас­пределения физической организации базы данных в сети.

локальная автономность — понятие, означающее, что инфор­мация локальной БД и связанные с ней определения данных при­надлежат локальному владельцу и им управляются.

удаленный запрос — запрос к базам данных, находящихся на ресурсах локальной сети предприятия или сети Интернет.

Возможность реализации удаленной транзакции — обработка одной транзакции, состоящей из множества SQL-запросов, на одном удаленном узле.

поддержка распределенной транзакции — обработка транзакции, состоящей из нескольких SQL-запросов, выполняемых на несколь­ких узлах сети (удаленных или локальных), но каждый из которых обрабатывается только на одном узле.

распределенный запрос — запрос, при обработке которого ис­пользуются данные из БД, расположенные в разных узлах сети.

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

1.2. Архитектуры клиент—сервер в технологии управления удаленными базами данных

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

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

• функции ввода и отображения данных (Presentation Logic);

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

• функции обработки данных внутри приложения (DataBase Logic);

• функции управления информационными ресурсами (DataBase Manager System);

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

Структура типового приложения, работающего с базой дан­ных в архитектуре клиент—сервер, приведена рис. 1.1.

Как видно из рис. 1.1, клиентская часть приложения включает в себя следующие части:

• презентационную логику;

• бизнес-логику, или логику собственно приложений;

• логику обработки данных;

• процессор управления данными.

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

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

• формирование экранных изображений;

• чтение и запись в экранные формы информации;

• управление экраном;

• обработка движений мыши и нажатие клавиш клавиатуры.

Бизнес-логика, или логика собственно приложений (Business

Processing Logic), — это часть кода приложения, которая опреде­ляет собственно алгоритмы решения конкретных его задач. Обыч­но этот код записывается с использованием различных языков программирования, таких как С, С++, Visual Basic и др.

Логика обработки данных (Data Manipulation Logic) — это часть кода приложения, которая непосредственно связана с обработ­кой данных внутри него. Далными управляет собственно СУБД, а для обеспечения доступа к ним используется язык SQL.

Процессор управления данными (DataBase Manager System Processing) — это собственно СУБД, которая обеспечивает хра­нение и управление базами данных. В идеале функции СУБД дол­жны быть скрыты от бизнес-логики приложения, однако при рас­смотрении архитектуры приложения мы выделим их в отдельную его часть.

В централизованной архитектуре (Host-Based Processing) ука­занные части приложения располагаются в единой среде и ком­бинируются внутри одной исполняемой программы. В децентра­лизованной архитектуре эти части приложения могут быть по-раз­ному распределены между серверным и клиентским процессами.

В зависимости от характера распределений задач можно выде­лить следующие их модели (рис. 1.2):

• распределенное представление (Distribution Presentation);

• удаленное представление (Remote Presentation);

• распределенная бизнес-логика (Remote Business Logic);

• удаленное управление данными (Remote Data Management);

• распределенное управление данными (Distributed Data Management).

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

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

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

Модель удаленного управления данными, или модель файлового сервера (File Server — FS). В этой модели презентационная логика и бизнес-логика располагаются на клиентской части. На сервере располагаются файлы с данными и поддерживается доступ к этим файлам. Функции управления информационными ресурсами в этой модели находятся на клиентской части.

Распределение функций компонентов приложения в моделях клиент — сервер представлено на рис. 1.3.

В этой модели файлы базы данных хранятся на сервере, клиент обращается к серверу с файловыми командами, а механизм уп­равления всеми информационными ресурсами — собственно база метаданных (выбранных данных) — находится на компьютере кли­ента.

Рис. 1.3. Модель файлового сервера

Д остоинство данной модели состоит в том, что приложение разделено на два взаимодействующих процесса. При этом сервер

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

Алгоритм выполнения клиентского запроса сводится к следу­ющему.

• 1. Запрос формулируется в командах языка манипулирования данными (ЯМД).

  2. СУБД переводит этот запрос в последовательность файловых команд.

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

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

Рассмотренная модель имеет следующие недостатки:

• высокий сетевой трафик, который связан с передачей по сети множества блоков и файлов, необходимых приложению;

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

• отсутствие адекватных средств безопасности доступа к дан­ным (защита только на уровне файловой системы).

Модель удаленного доступа к данным (Remote Data Access — RDA). В этой модели база данных хранится на сервере. Там же находится и ядро СУБД. На компьютере клиента располагаются презентационная логика и бизнес-логика приложения. Клиент обращается к серверу с запросами на языке SQL. Структура моде­ли удаленного доступа к данным приведена на рис. 1.4.

Преимущества данной модели состоят в следующем:

• перенос компонента представления и прикладного компо­нента на клиентский компьютер существенно разгружает сервер БД, сводя к минимуму общее число выполняемых процессов в операционной системе;

• сервер БД освобождается от несвойственных ему функций, а процессор или процессоры сервера целиком загружаются опера­циями обработки данных запросов и транзакций;

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

Основным достоинством модели RDA является унификация интерфейса клиент—сервер, т.е. стандартным при общении при­ложения клиента и сервера становится язык SQL.

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

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

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

• так как сервер в этой модели играет пассивную роль, функ­ции управления информационными ресурсами должны выполнять­ся на компьютере клиента.Модель сервера баз данных. Для исключения недостатков мо­дели удаленного доступа к данным необходимо выполнение сле­дующих условий.

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

  2. БД должна отражать некоторые правила предметной области и законы, по которым она функционирует (Business Rules). На­пример, завод может нормально работать, только если на складе имеется достаточный (страховой) запас деталей определенной номенклатуры, а деталь может быть запущена в производство, толь­ко если на складе имеется достаточно материала для ее изготовле­ния, и т.д.

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

  4. Возникновение некоторой ситуации в БД должно четко и оперативно влиять на ход выполнения прикладной задачи.

  5. Совершенствование контроля типов данных СУБД. В насто­ящее время СУБД контролирует синтаксически только стандарт- но-допустимые типы данных, т. е. которые определены в DDL (Data Definition Language) — языке описания данных, являющемся ча­стью SQL. Однако в реальных предметных областях существуют данные, которые несут в себе еще и семантическую составляющую, например координаты объектов или единицы измерений.

Модель сервера баз данных поддерживают большинство совре­менных СУБД: Informix, Ingres, Sybase, Oracle, MS SQL Server. Основу данной модели составляют: механизм хранимых процедур как средство программирования SQL-сервера, механизм тригге­ров как механизм отслеживания текущего состояния информаци­онного хранилища и механизм ограничений на пользовательские типы данных, который иногда называют механизмом поддержки доменной структуры.

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

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

Централизованный контроль в модели сервера баз данных вы­полняется с использованием механизма триггеров, которые так­же являются частью БД.

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

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

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

Хранимые процедуры и триггеры хранятся в словаре БД и, следовательно, могут быть использованы несколькими клиента­ми, что существенно уменьшает дублирование алгоритмов обра­ботки данных в разных клиентских приложениях.

Недостатком данной модели является очень большая загрузка сервера, так как он обслуживает множество клиентов и выполня­ет следующие функции:

• осуществляет мониторинг событий, связанных с выполнени­ем разработанных триггеров;

• обеспечивает автоматическое срабатывание триггеров при воз­никновении связанных с ними событий;

• обеспечивает исполнение внутренней программы каждого триггера;

• запускает хранимые процедуры по запросам пользователей;

• запускает хранимые процедуры из триггеров;

• возвращает требуемые данные клиенту;

• обеспечивает выполнение всех функций СУБД (доступ к дан­ным, контроль и поддержку целостности данных в БД, контроль доступа, обеспечение корректной параллельной работы всех пользователей с единой БД).

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

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

Архитектура трехуровневой модели приведена на рис. 1.6. Про­межуточный уровень может содержать один или несколько серве­ров приложений.

В данной модели компоненты приложения делятся между тре­мя исполнителями: клиентом, сервером приложений и сервером базы данных.

Клиент обеспечивает логику представления, включая графи­ческий пользовательский интерфейс и локальные редакторы. Кли­ент может запускать локальный код приложения клиента, кото­рый может содержать обращения к локальной БД, расположен­ной на его компьютере. Клиент исполняет коммуникационные функции front-end части приложения, обеспечивающие ему дос­туп в локальную или глобальную сеть. Дополнительно реализация взаимодействия между клиентом и сервером может включать в себя управление распределенными транзакциями, что соответству­ет случаям, когда клиент также является клиентом менеджера рас­пределенных транзакций.

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

Серверы баз данных в этой модели занимаются исключительно функциями СУБД: обеспечивают функции создания и ведения БД, поддерживают целостность реляционной БД, обеспечивают функции хранилищ данных (warehouse services). Кроме того, на них возлагаются функции создания резервных копий БД и восста­новления БД после сбоев, управления выполнением транзакций и поддержки устаревших (унаследованных) приложений (legacy application).

Данная модель обладает большей гибкостью, чем двухуровне­вые модели. Наиболее заметны преимущества модели сервера приложений в тех случаях, когда выполняются сложные аналити­ческие расчеты в базе данных, относящихся к области OLAP-при- ложений (On-line analytical processing). В этой модели большая часть бизнес-логики клиента изолирована от возможностей встроенно­го языка SQL, реализованного в конкретной СУБД, и может быть выполнена на языках программирования С, С++, Sir.i. Talk, Cobol, что повышает переносимость системы и ее масштабируемость.

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

Рассмотрим эволюцию подобных механизмов. В основном та­кой механизм определяется структурой реализации серверных процессов и часто называется архитектурой сервера баз данных.

Как уже отмечалось, поначалу существовала модель, в кото­рой управление данными (функция сервера) и взаимодействие с пользователем были совмещены в одной программе. Этот этап развития серверов БД можно назвать нулевым.

Затем функции управления данными были выделены в само­стоятельную группу — сервер. Однако при этом модель взаимо­действия пользователя с сервером соответствовала структуре свя­зей между таблицами баз данных «один к одному» (рис. 1.7), т.е. сервер обслуживал запросы только одного пользователя (клиен­та), а для обслуживания нескольких клиентов нужно было запус­тить соответствующее число серверов.

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

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

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

дельной нитью (thread) или потоком, по которому пересылаются запросы. Такая архитектура, получившая название многопотоко­вой односерверной (multi-threaded), позволяет значительно умень­шить нагрузку на операционную систему, возникающую при ра­боте большого числа пользователей (trashing).

Кроме того, обеспеченная в данной модели возможность вза­имодействия многих клиентов с одним сервером позволяет в пол­ной мере использовать разделяемые объекты (начиная с открытых файлов и заканчивая данными из системных каталогов), что зна­чительно уменьшает потребность в памяти и общее число процес­сов операционной системы. Например, в модели «один к одному» СУБД создает 100 копий процессов для 100 пользователей, а си­стеме с многопотоковой архитектурой для этого понадобится толь­ко один серверный процесс.

Однако такое решение имеет свои недостатки. Так как сервер может выполняться только на одном процессоре, возникает есте­ственное ограничение на применение СУБД для мультипроцес­сорных платформ. Если компьютер имеет, например, четыре про­цессора, то СУБД с одним сервером использует только один из них, не загружая другие три.

Контрольные вопросы

1. Дайте определения следующих терминов: архитектура ODBC, модели данных, транзакция, топология БД (или струк­тура распределенной БД), локальная автономность, удаленный запрос, распределенный запрос, поддержка распределенной транзакции, презентационная логика, биз­нес-логика, логика обработки данных, процессор управления данными.
2. Какие двухуровневые модели вы знаете? Назовите их достоинства и недостатки.

Вау!! 😲 Ты еще не читал? Это зря!

• Виды баз данных
• Транзакция
• СУБД

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

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