Лекция
Привет, Вы узнаете о том , что такое системы обработки многопользовательских бд, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое системы обработки многопользовательских бд , настоятельно рекомендую прочитать все из категории Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL.
1. ЭВОЛЮЦИЯ КОНЦЕПЦИЙ ОБРАБОТКИ ДАННЫХ
Обработка данных со временем претерпела некоторую эволюцию. В развитии концепций обработки данных можно выделить следующие этапы:
2. СИСТЕМЫ УДАЛЕННОЙ ОБРАБОТКИ
Классической архитектурой обработки многопользовательских БД является удаленная обработка.
Пользователи обрабатывают данные в пакетном режиме. Интерактивный режим доступа осуществляется с помощью терминалов, которые не обладают собственными вычислительными ресурсами. Программы управления коммуникациями (связью), прикладные программы, СУБД и ОС работают на едином центральном компьютере. Поскольку вся обработка производится единственным компьютером, то пользовательский интерфейс систем удаленной обработки обычно достаточно прост. Схема удаленной обработки показана на рис.1.
Пользователи (на рис. 1 показано n – пользователей) работают с терминалами, которые передают данные и сообщения о транзакциях центральному компьютеру (компьютер удаленной обработки). Функции управления данными возложены на операционную систему. Часть ОС, отвечающая за управление связью, принимает сообщения и данные и передает их соответствующим прикладным программам. Программы обращаются к СУБД, а СУБД выполняет операции с БД, используя ту часть ОС, которая отвечает за обработку данных. Когда транзакция завершается, подсистема управления связью возвращает результаты пользователям, сидящим у терминалов. Поскольку их пользовательский интерфейс достаточно прост и имеет в основном текстовую ориентацию, все команды форматирования вывода генерируются процессором центрального компьютера и передаются по линии связи. Такие системы, подобные описанной называются системами удаленной обработки, поскольку связь между входами и выходами осуществляется через находящийся на расстоянии центральный компьютер, ведущий обработку данных.
Преимуществом такой обработки является возможность коллективного использования ресурсов и оборудования, централизованное хранение данных, а недостатком – отсутствие персонализации рабочей среды (все программное обеспечение хранится централизованно и используется коллективно). Исторически системы удаленной обработки были наиболее распространенной альтернативой многопользовательским системам баз данных. Но по мере того, как ПК стали появляться в офисах и выросла их мощь в качестве серверов данных, возникли новые архитектуры многопользовательских систем обработки данных.
3. СИСТЕМЫ СОВМЕСТНОГО ИСПОЛЬЗОВАНИЯ ФАЙЛОВ
3.1. Архитектура файл/сервер и роль настольных СУБД в ней
При наличии компьютерной сети открывается возможность хранить и использовать в многопользовательском режиме централизованные БД, размещаемые на одном компьютере – сервере сети. В этом случае каждый пользователь своего ПК получает доступ к общей для всех пользователей централизованной БД. Существуют различные концепции сетевой обработки данных.
Рассмотрим архитектуру с совместным использованием файлов, которая была разработана до клиент/серверной архитектуры и во многих отношениях является достаточно упрощенной.
Почти во всех системах с совместным использованием файлов применяются локальные сети. Для этой архитектуры характерен коллективный доступ к общей БД на сервере, который является файловым сервером. Файловый сервер содержит файлы, необходимые для работы приложений и самой СУБД. Он обеспечивает функционирование той части сетевой версии СУБД, которая осуществляет управление данными в БД. Однако пользовательские приложения и сама сетевая СУБД размещены и функционируют на отдельных рабочих станциях и обращаются к файловому серверу по мере необходимости.
Рассмотрим организацию архитектуры файл/сервер с использованием настольной СУБД.
Сетевые версии настольных СУБД отличаются от локальных версий тем, что они обладают некоторыми специальными механизмами, позволяющими многим пользователям совместно обращаться к общим ресурсам данных из централизованной базы данных. СУБД на каждой рабочей станции посылает запросы файловому серверу по всем необходимым ей данным, которые хранятся на диске файлового сервера. Все данные из БД пересылаются на компьютер пользователя, независимо от того, сколько реально их нужно для выполнения запроса. В результате на компьютере пользователя создается локальная копия БД (время от времени обновляемая из реальной БД на сервере). Затем СУБД пользователя выполняет запрос. Схема работы с настольной СУБД в многопользовательском режиме показана на рис. 2.
3.2. Недостатки архитектуры файл/сервер
Архитектура с использованием файлового сервера обладает следующими основными недостатками.
1. Поскольку файловый сервер не может обрабатывать SQL-запросы, то при совместном использовании файлов по локальной сети передаются большие объемы данных (полные копии БД перемещаются по сети с сервера на компьютер клиента). При такой архитектуре трафик[1] в локальной сети достаточно большой.
2. С увеличением объема хранимых данных и числа пользователей снижается производительность настольных СУБД. Из-за этих проблем системы с совместным использованием файлов редко используются для обработки больших объемов данных.
3. При такой архитектуре вся тяжесть выполнения запроса к БД и управления целостностью БД ложится на СУБД пользователя.
3. На каждой рабочей станции должна находиться сама сетевая версия настольной СУБД, что требует наличия больших объемов оперативной памяти на компьютере пользователя.
4. Доступ к одним и тем же файлам могут осуществлять сразу несколько пользователей, что усложняет управление целостностью, восстановлением БД на сервере.
3.3. Достоинства и недостатки настольных СУБД
Достоинства настольных СУБД:
Недостатки настольных СУБД:
Известно более десятка настольных СУБД. Наиболее популярными, исходя из числа проданных копий признаются DBASE, Visual DBASE, Paradox, Microsoft FoxPro, Visual FoxPro, Access. Более подробное описание упомянутых СУБД приведено в [1].
[1] Трафик – это объем информации, передаваемый по сети за определенный период времени.
4. КЛИЕНТ/СЕРВЕРНЫЕ СИСТЕМЫ
4.1. Клиенты, серверы
Наиболее эффективную работу с централизованной БД обеспечивает архитектура клиент/сервер. В отличие от системы удаленной обработки, в которой имеется только один компьютер, клиент/серверная система состоит из множества компьютеров, объединенных в сеть. Компьютеры называемые клиентами, занимаются обработкой прикладных программ. Компьютеры, называемые серверами, занимаются обработкой БД.
Тип компьютеров, используемых в качестве клиентов может быть разным, это могут быть большие ЭВМ или микрокомпьютеры. Однако, как правило, функции клиентов выполняют почти всегда ПК. В роли сервера может выступать компьютер любого типа, но по экономическим причинам функции сервера чаще всего также выполняют ПК, но имеющие более высокую производительность.
4.2. Клиентские приложения, серверы баз данных
На сервере сети размещается БД и устанавливается мощная серверная СУБД – сервер баз данных. Сервер БД – это программный компонент, обеспечивающий хранение больших объемов информации, ее обработку и представление ее пользователям в сетевом режиме.
На компьютере-клиенте приложение-клиент формирует запрос к БД. Серверная СУБД обеспечивает интерпретацию запроса, его выполнение, формирование результата запроса и пересылку его по сети на клиентский компьютер. Клиентское приложение интерпретирует его необходимым образом и представляет пользователю. Клиентское приложение может также посылать запрос на обновление БД и серверная СУБД внесет необходимые изменения в БД. Схема архитектуры клиент/сервер приведена на рис. 3.
В архитектуре клиент/сервер функции клиентского приложения и серверной СУБД разделены.
Функции клиентского приложения разбиваются на следующие группы:
Сервер баз данных в общем случае осуществляет целый комплекс действий по управлению данными. Основными среди них являются следующие:
4.3. Об этом говорит сайт https://intellect.icu . Общие сведения о хранимых процедурах и триггерах
В современной модели клиент/сервер бизнес-логика разделена между клиентом и сервером. На сервере бизнес-логика реализована в виде хранимых процедур – специальных программных модулей, которые хранятся в БД и управляются непосредственно СУБД.
Хранимая процедура – это специальная процедура, которая выполняется сервером баз данных. Хранимые процедуры пишутся на процедурном языке, который зависит от конкретной СУБД. Для написания хранимых процедур для MS SQL Server используется расширенный стандарт языка SQL – Transact-SQL. Хранимая процедура здесь – это последовательность операторов Transact-SQL, хранящихся в БД. Хранимые процедуры предварительно откомпилированы, поэтому их эффективность выше, чем обычных запросов. Они выполняются непосредственно на сервере.
Существует два вида хранимых процедур: системные и пользовательские. Системные хранимые процедуры предназначены для получения информации из системных таблиц и выполнения различных служебных операций и особенно полезны при администрировании базы данных. Пользовательские хранимые процедуры создаются непосредственно разработчиками или администраторами базы данных. Полезность хранимых процедур определяется в первую очередь высокой (по сравнению с обычными Transact-SQL запросами) скоростью их выполнения. Однако наибольший эффект достигается при выполнении многократно повторяющихся операций. Пользовательские хранимые процедуры применяются при решении практически любых задач. Пользователь может получить право выполнения хранимой процедуры, даже если он не имеет права доступа к объектам, к которым обращается программа.
Хранимая процедура вызывается явно, т.е. при непосредственном обращении к процедуре из клиентского приложения, работающего с базой данных. Хранимые процедуры используются для извлечения или изменения данных в любое время. Хранимые процедуры могут принимать аргументы при запуске и возвращать значения в виде результирующих наборов данных.
Логика БД реализуется с помощью триггеров. Триггер – это специальный тип хранимой процедуры, которая автоматически выполняется при каждой попытке изменить данные. Триггер всегда связан с конкретной таблицей и выполняется тогда, когда при редактировании этой таблицы наступает событие, с которым он связан (например, вставка, удаление или обновление записи). Каждая таблица может иметь произвольное количество триггеров любых типов. После операций вставки, обновления, удаления может быть запущен триггер, который в результате приведет к вычислению бизнес-правил или к выполнению определенных действий. При удалении таблицы, имеющей триггеры, все они также удаляются.
Триггеры обеспечивают целостность данных, предотвращая их несанкционированное или неправильное изменение. Триггеры не принимают параметров и не возвращают значений. Они выполняются неявно, то есть триггер запускается только при попытке изменения данных. Триггеры могут иметь несколько уровней вложенности (например, в СУБД MS SQL Server триггеры имеют до 32 уровней вложенности), то есть выполнение одного триггера инициирует выполнение другого триггера. Триггер является частью транзакции, следовательно, если триггер не выполнятся, то отменяется вся транзакция. И наоборот, если какая-то часть транзакции не выполнилась, то и триггер будет отменен.
4.4. Преимущества архитектуры клиент/сервер
При клиент/серверной обработке уменьшается сетевой трафик, так как через сеть передаются только результаты запросов.
Груз файловых операций ложится в основном на сервер, который мощнее компьютеров-клиентов и поэтому способен быстрее обслуживать запросы. Как следствие этого, уменьшается потребность клиентских приложений в оперативной памяти.
Поскольку серверы способны хранить большое количество данных, то на компьютерах-клиентах освобождается значительный объем дискового пространства для других приложений.
Повышается уровень непротиворечивости данных и существенно повышается степень безопасности БД, так как правила целостности данных определяются в серверной СУБД и являются едиными для всех приложений, использующих эту БД.
Имеется возможность хранения бизнес-правил (например, правил ссылочной целостности или ограничений на значения данных) на сервере, что позволяет избежать дублирования кода в различных клиентских приложениях, использующих общую базу данных.
4.5. Характеристика серверов баз данных
Современные серверные СУБД:
К современным серверам баз данных относятся Oracle 9 (Oracle), MS SQL Server 2000 (MS), Informix (Informix), Sybase (Sybase), Db2 (IBM). Краткий обзор серверных СУБД приведен в пособии [2].
4.6. Механизмы доступа к базам данных
Все серверные СУБД имеют клиентскую часть, которая обращается к БД посредством СУБД. Между клиентским приложением и СУБД не существует прямой связи и дополнительно встраиваются программные модули, позволяющие клиентскому приложению получать доступ к БД, создаваемым с помощью разных СУБД. Такие модули называются механизмами доступа к данным.
Существует два основных способа доступа к данным из клиентских приложений: использование прикладного интерфейса и использование универсального программного интерфейса.
Прикладной программный интерфейс (API – Application Programming Interface) представляет собой набор функций, вызываемых из клиентского приложения. Он может работать только с СУБД данного производителя и при ее замене придется переписывать значительную часть кода клиентского приложения. Прикладной программный интерфейс различен для разных СУБД.
Универсальный механизм доступа к данным обеспечивает возможность использования одного и того же интерфейса для доступа к разным типам СУБД. Обычно он реализован в виде специальных дополнительных модулей, называемых драйверами.
Наиболее распространенным программным интерфейсом, обеспечивающим доступ к данным конкретной базы данных является ODBC (Open Database Connectivity) фирмы Microsoft. В рамках ODBC программное приложение непосредственно взаимодействует с диспетчером драйвером, посылая ему ODBC-вызовы. Диспетчер драйверов отвечает за динамическую загрузку нужного ODBC-драйвера, через который обращается с серверу баз данных. ODBC-драйвер выполняет все вызовы ODBC-функций и «переводит» их на язык источника данных. СУБД хранит и выводит данные в ответ на запросы со стороны ODBC-драйвера.
Задание ODBC-источникаданных является действием, которое осуществляется средствами операционной системы, управляющей компьютером.В операционной системе Windows в Панели управления предусмотрен пункт Исочники данных ODBC (32 разр) из которого вызывается Администратор источников данных ODBC. С его помощью могут быть заданы:
5. СИСТЕМЫ ОБРАБОТКИ РАСПРЕДЕЛЕННЫХ БАЗ ДАННЫХ
5.1. Понятие и архитектура распределенной БД
Распределенная БД (РаБД) – набор логически связанных между собой разделяемых данных и их описаний, которые физически распределены по нескольким компьютерам ( узлам) в некоторой компьютерной сети.
Каждая таблица в РАБД может быть разделена на некоторое количество частей, называемых фрагментами. Фрагменты могут быть горизонтальными, вертикальными и смешанными. Горизонтальные фрагменты представляют собой подмножества строк, а вертикальные – подмножества столбцов. Фрагменты распределяются на одном или нескольких узлах.
С целью улучшения доступности данных и повышения производительности системы для отдельных фрагментов может быть организована репликация – поддержка актуальной копии некоторого фрагмента на нескольких различных узлах. Репликаты – множество различных физических копий некоторого объекта БД, для которых в соответствии с определенными в БД правилами поддерживается синхронизация с некоторой «главной копией».
Существуют несколько альтернативных стратегий размещения данных в системе: раздельное (фрагментированное) размещение, размещение с полной репликацией и размещение с выборочной репликацией.
Раздельное (фрагментированное) размещение. В этом случае БД разбивается на непересекающиеся фрагменты, каждый из которых размещается на одном из узлов системы. При отсутствии репликации стоимость хранения данных будет минимальна, но при этом будет невысок также уровень надежности и доступности данных в системе. Отказ на любом из узлов вызовет утрату доступа только к той части данных, которая на нем хранилась.
Размещение с полной репликацией. Эта стратегия предусматривает размещение полной копии всей БД на каждом из узлов системы. Следовательно, надежность и доступность данных, а также уровень производительности системы будут максимальными. Однако стоимость хранения данных и уровень затрат на передачу данных в этом случае будут самыми высокими.
Размещение с выборочной репликацией. Данная стратегия представляет собой комбинацию методов фрагментации, репликации и централизации. Одни массивы данных разделяются на фрагменты, тогда как другие подвергаются репликации. Все остальные данные хранятся централизованно. Целью применения данного метода является объединение всех преимуществ, существующих в остальных моделях, с одновременным исключением свойственных им недостатков. Благодаря своей гибкости, именно эта стратегия используется чаще всего.
5.2. Распределенная СУБД
Работу с РаБД обеспечивают распределенные СУБД. Распределенная СУБД (РаСУБД) – комплекс программ, предназначенный для управления распределенной БД и позволяющий сделать распределенность информации «прозрачной» для конечного пользователя. Из определения РаСУБД следует, что для конечного пользователя должен быть полностью скрыт тот факт, что распределенная БД состоит из нескольких фрагментов, которые могут размещаться на нескольких компьютерах, расположенных в сети и к ней возможен параллельный доступ нескольких пользователей. Назначение обеспечения «прозрачности» состоит в том, чтобы распределенная система внешне вела себя точно так же, как и централизованная. Такое распределение данных позволяет, например, хранить в узле сети те данные, которые наиболее часто используются в этом узле. Такой подход облегчает и ускоряет работу с этими данными и оставляет возможность работать с остальными данными БД, хотя для доступа к ним требуется потратить некоторое время на передачу данных по сети.
Основная задача РаСУБД состоит в обеспечении средств интеграции локальных баз данных, располагающихся в некоторых узлах компьютерной сети, с тем, чтобы пользователь, работающий в любом узле сети, имел доступ ко всем этим БД как к единой БД. Другими словами, для клиентских приложений РаБД представляется не набором баз, а единым целым. Каждый фрагмент БД сохраняется на одном или нескольких компьютерах, которые соединены между собой линиями связи и каждый из них работает под управлением отдельной СУБД. Пользователи взаимодействуют с РаБД через приложения. Приложения могут быть классифицированы как те, которые не требуют доступа к данным на других узлах (локальные приложения), и те, которые требуют подобного доступа (глобальные приложения). В РаСУБД должно существовать хотя бы одно глобальное приложение, поэтому любая РаСУБД должна имеет следующие особенности:
СУБД на каждом узле способна поддерживать автономную работу локальных приложений.
5.3. Гомогенные и гетерогенные распределенные БД
РаБД можно классифицировать на гомогенные и гетерогенные.
Гомогенной РаБД управляет один и тот же тип СУБД. Гетерогенной РаБД управляют различные типы СУБД, использующие разные модели данных – реляционные, сетевые, иерархические или объектно-ориентированные СУБД.
Гомогенные РаБД значительно проще проектировать и сопровождать. Кроме того, подобный подход позволяет поэтапно наращивать размеры РаБД, последовательно добавляя новые узлы к уже существующей РаБД. Гетерогенные РаБД обычно возникают в тех случаях, когда независимые узлы, управляемые своей собственной СУБД, интегрируются во вновь создаваемую РаБД.
5.4. Двенадцать правил К. Дейта для РаБД и РаСУБД
К. Дейтом были сформулированы 12 правил (1987) для типичной РаБД. Основой этих правил является то, что РАБД должна восприниматься пользователем точно так же, как и привычная централизованная БД.
1. Локальная автономность. В данном контексте автономность означает следующее:
2. Отсутствие опоры на центральный узел. В системе не должно быть ни одного узла, без которого система не сможет функционировать, т.е. никакой конкретный сервис (управление транзакциями, оптимизация запросов и др.) не должен возлагаться на какой-либо специально выделенный центральный узел.
3. Непрерывное функционирование. В идеале в системе не должна возникать потребность в плановом останове ее функционирования.
4. Независимость от расположения. Пользователь должен получать доступ к базе данных с любого узла, причем получать доступ к любым данным, независимо от того, где они физически сохраняются.
5. Независимость от фрагментации. Пользователь должен получать доступ к данным независимо от способа их фрагментации.
6. Независимость от репликации. Пользователь не должен нуждаться в сведениях о наличии репликации данных, т.е. пользователь не будет иметь средств для получения прямого доступа к конкретной копии элемента данных, а также не должен заботиться об обновлении уже имеющейся копии.
7. Обработка распределенных запросов. Система должна поддерживать обработку запросов, ссылающиеся на данные, расположенные более чем на одном узле.
8. Обработка распределенных транзакций. Система должна поддерживать выполнение транзакций.
9. Независимость от типа оборудования. Система должна быть способна функционировать на оборудовании с различными вычислительными платформами.
10. Независимость от сетевой архитектуры. Система должна быть способна функционировать в сетях с различной архитектурой.
11. Независимость от операционной системы. Система должна быть способна функционировать под управлением различных операционных систем.
12. Независимость от типа СУБД.
5.5. Обработка распределенных запросов
В распределенной среде работа системы не должна демонстрировать никакого снижения производительности, связанного с его распределенной архитектурой, например с присутствием медленных сетевых соединений. РаСУБД должна находить наиболее эффективные стратегии выполнения запросов. В распределенной среде обработчик распределенных запросов отображает запрос на доступ к данным в упорядоченную последовательность операций локальных баз данных (в отличие от централизованной, где обработчик запросов оценивает каждый запрос на доступ к данным, а выполнение его представляет собой упорядоченную последовательность операций с БД). Дополнительная сложность возникает из-за необходимости учитывать наличие фрагментации, репликации и определенной схемы размещения данных. Обработчик распределенных запросов должен выяснить:
Возможности выполнения распределенного запроса поддерживаются сейчас почти всеми серверными СУБД (по крайней мере в том случае, когда в транзакцию вовлечены серверы от одного производителя). С этой целью используется механизм двухфазного завершения транзакций, когда на первом этапе серверы, вовлеченные в транзакцию, сигнализируют о готовности ее завершить, а на втором этапе происходит реальная фиксация изменений в БД.
5.6. Преимущества и недостатки РАСУБД
Системы с распределенными БД имеют дополнительные преимущества перед традиционными централизованными системами баз данных.
Преимущества РаСУБД:
1. Отражение структуры организации.
2. Разделяемость и локальная автономность.
3. Повышение доступности данных.
4. Повышение надежности.
5. Повышение производительности.
6. Экономические выгоды.
7. Модульность системы.
Недостатки РаСУБД:
1. Повышение сложности. РаСУБД являются более сложными программными комплексами, чем централизованные СУБД, что обусловлено распределенной природой используемых ими данных, а также репликацией данных.
2. Увеличение стоимости. Увеличение сложности означает и увеличение затрат на приобретение и сопровождение РаСУБД.
3. Проблемы защиты. В централизованных системах доступ к данным легко контролируется. Однако в распределенных системах требуется организовать контроль доступа не только к данным, реплицируемым на несколько различных узлов, но и защиту сетевых соединений самих по себе.
4. Усложнение контроля за целостностью данных. В РаСУБД повышенная стоимость передачи и обработки данных может препятствовать организации эффективной защиты от нарушений целостности данных.
5. Отсутствие стандартов. Отсутствуют стандарты на каналы связи и протоколы доступа к данным, а также отсутствуют инструментальные средства и методологии, способные помочь пользователям в преобразовании централизованных систем в распределенные.
6. Недостаток опыта. Еще не накоплен необходимый опыт промышленной эксплуатации распределенных систем, сравнимый с опытом эксплуатации централизованных систем.
7. Усложнение процедуры разработки БД. Разработка распределенных БД, помимо обычных трудностей, связанных с процессом проектирования централизованных БД, требует принятия решения о фрагментации данных, распределении фрагментов по отдельным узлам и организации процедур репликации данных.
8. Сложность управления и обусловленная этим потенциальная опасность потери целостности данных.
5.7. Обзор распределенных СУБД
В настоящее время наиболее развитыми в теоретическом и практическом отношении являются реляционные распределенные СУБД. К РаСУБД, наиболее изученным относятся:
В настоящее время в большинстве коммерческих реляционных серверных СУБД предусмотрены разные виды поддержки использования распределенных баз данных. Наиболее полно функции распределенной СУБД реализованы в системах:
Наиболее близко подошли к реализации функций распределенных СУБД такие как:
Представленные результаты и исследования подтверждают, что применение искусственного интеллекта в области системы обработки многопользовательских бд имеет потенциал для революции в различных связанных с данной темой сферах. Надеюсь, что теперь ты понял что такое системы обработки многопользовательских бд и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL
Комментарии
Оставить комментарий
Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL
Термины: Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL