Главная страница

В. И. Швецов Базы данных


Скачать 8.45 Mb.
НазваниеВ. И. Швецов Базы данных
АнкорV_I_Shvetsov_Bazy_dannykh.doc
Дата20.12.2017
Размер8.45 Mb.
Формат файлаdoc
Имя файлаV_I_Shvetsov_Bazy_dannykh.doc
ТипУчебное пособие
#12252
страница2 из 24
1   2   3   4   5   6   7   8   9   ...   24








4. Защита логической целостности базы данных.

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

5. Защита физической целостности.

При работе ЭВМ возможны сбои в работе (например, из-за отключения электропитания), повреждение машинных носителей данных. При этом могут быть нарушены связи между данными, что приводит к невозможности дальнейшей работы. Развитые СУБД имеют средства восстановления базы данных. Важнешим используемым понятием является понятие «транзакции». Транзакция – это единица действий, производимых с базой данных. В состав транзакции может входить несколько операторов изменения базы данных, но либо выполняются все эти операторы, либо не выполняется ни один. СУБД, кроме ведения собственно базы данных, ведет также журнал транзакций.

Необходимость использования транзакций в базах данных проиллюстрируем на упрощенном примере. Предположим, что база данных используется в некотором банке и один из клиентов желает перевести деньги на счет другого клиента банка. В базе данных хранится информация о количестве денег у каждого из клиентов. Нам нужно сделать два изменения в базе данных – уменьшить сумму денег на счете одного из клиентов и, соответ­ственно, увеличить сумму денег на другом счете. Конечно, реальный перевод денег в банке представляет собой гораздо более сложный процесс, затрагивающий много таблиц, а возможно, и много баз данных. Однако суть остается та же – нужно либо совершить все действия (увеличить счет одного клиента и уменьшить счет другого), либо не выполнить ни одно из этих действий. Нельзя уменьшить сумму денег на одном счете, но не увеличить сумму денег на другом. Предположим также, что после выполнения первого из действий (уменьшения суммы денег на счете первого клиента) произошел сбой. Например, могла прерваться связь клиентского компьютера с базой данных или на клиентском компьютере мог произойти системный сбой, что привело к перезагрузке операционной системы. Что в этом случае стало с базой данных? Команда на уменьшение денег на счете первого клиента была выполнена, а вторая команда – на увеличение денег на другом счете – нет,что привнло бы к противоречивому, неактуальному состоянию базы данных.

Использование механизма транзакций позволяет находить решение в этом и подобных случаях. Перед выполнением первого действия выдается команда начала транзакции. В транзакцию включается операция снятия денег на одном счете и увеличения суммы на другом счете. Оператор завершения транзакций обычно называется COMMIT. Поскольку после выполнения первого действия транзакция не была завершена, изменения не будут внесены в базу данных. Изменения вносятся (фиксируются) только после завершения транзакции.. До выдачи данного оператора сохранения данных в базе не произойдет.

В нашем примере, поскольку оператор фиксации транзакции не был выдан, база данных «откатится» в первоначальное состояние – иными словами, суммы на счетах клиентов останутся те же, что и были до начала транзакции. Администратор базы данных может отслеживать состояние транзакций и в необходимых случаях вручную «откатывать» транзакции. Кроме того, в очевидных случаях СУБД самостоятельно принимает решение об «откате» транзакции.

Транзакции не обязательно могут быть короткими. Бывают транзакции, которые длятся несколько часов или даже несколько дней. Увеличение количества действий в рамках одной транзакции требует увеличения занимаемых системных ресурсов. Поэтому желательно делать транзакции по возможности короткими. В журнал транзакций заносятся все транзакции – и зафиксированные, и завершившиеся «откатом». Ведение журнала транзакций совместно с созданием резервных копий базы данных позволяет достичь высокой надежности базы данных.

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

6. Управление полномочиями пользователей на доступ к базе данных.

Разные пользователи могут иметь разные полномочия по работе с данными (некоторые данные должны быть недоступны; определенным пользователям не разрешается обновлять данные и т.п.). В СУБД предусматриваются механизмы разграничения полномочий доступа, основанные либо на принципах паролей, либо на описании полномочий.

7. Синхронизация работы нескольких пользователей.

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

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

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

8. Управление ресурсами среды хранения.

БД располагается во внешней памяти ЭВМ. При работе в БД заносятся новые данные (занимается память) и удаляются данные (освобождается память). СУБД выделяет ресурсы памяти для новых данных, перераспределяет освободившуюся память, организует ведение очереди запросов к внешней памяти и т.п.

9. Поддержка деятельности системного персонала.

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

  • Определение структуры создаваемой базы данных, ее инициализация и проведение начальной загрузки

  • Предоставление пользователям возможности манипулирования данными (выборка необходимых данных, выполнение вычислений, разработка интерфейса ввода/вывода, визуализация).

  • Обеспечение независимости прикладных программ и (логической и физической независимости).
  • Защита логической целостности базы данных.

  • Защита физической целостности.

  • Управление полномочиями пользователей на доступ к базе данных.

  • Синхронизация работы нескольких пользователей.

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

  • Поддержка деятельности системного персонала.


Информация по содержанию данной лекции содержится в [1-3]

Контрольные тесты.
Задача 1. Основные причины появления систем управления базами данных.
Вариант 1.

Что обусловило появление систем управления базами данных ?
 необходимость повышения эффективности работы прикладных программ

 появление современных операционных систем

+ ð+ совместное использование данных разными прикладными программами

большой объем данных в прикладной программе

Вариант 2.

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

 большой объем данных в прикладной программе

 большой объем сложных математических вычислений

+ð+ необходимость решения ряда задач с использованием общих данных

Вариант 3.

Требования, из которых не следует необходимость в использовании СУБД:
+ð+ необходимость представления средств организации данных прикладной программе

+ð+ большой объем данных в прикладной программе

+ большой объем сложных математических вычислений

ð+ необходимость решения ряда задач с использованием общих данных

поле

Задача 2. Основная роль СУБД
Вариант 1

.Основное назначение СУБД:
+ обеспечение независимости прикладных программ и данных

 представление средств организации данных одной прикладной программе

 поддержка сложных математических вычислений

+ð+ поддержка интегрированной совокупности данных

Вариант 2.

Что не входит в назначение СУБД?
 обеспечение независимости прикладных программ и данных

+ð+ представление средств организации данных одной прикладной программе

+ð+ поддержка сложных математических вычислений

 поддержка интегрированной совокупности данных

Вариант 3.

Для чего предназначена СУБД?
+ð+ для создания базы данных

+ð+ для ведения базы данных

+ð+ для использования базы данных

 для разработки прикладных программ

Задача 3. Основные функции СУБД

Вариант 1.

Что входит в функции СУБД?
+ð+ создание структуры базы данных

+ð+ загрузка данных в базу данных

+ð+ предоставление возможности манипулирования данными

 проверка корректности прикладных программ, работающих с базой данных

+ð+ обеспечение логической и физической независимости данных

+ð+ защита логической и физической целостности базы данных

+ð+ управление полномочиями пользователей на доступ к базе данных

Вариант 2.

Что не входит в функции СУБД?
 создание структуры базы данных

 загрузка данных в базу данных

 предоставление возможности манипулирования данными

+ð+ проверка корректности прикладных программ, работающих с базой данных

 обеспечение логической и физической независимости данных

 защита логической и физической целостности базы данных

 управление полномочиями пользователей на доступ к базе данных


Вариант 3.

Основные средства СУБД для работы пользователя с базой данных:
+ð+ язык запросов

+ð+ графический интерфейс

 алгоритмический языкПаскаль

 разрабатываемые пользователем программы

Задача 4. Определение понятия банка данных.

Вариант 1.

Что входит в понятие банка данных ?

+ð+ база данных

 прикладные программы работы с базой данных

+ð+ СУБД

+ð+ компьютеры с базой данных

+ð+ администраторы базы данных


Вариант 2.

Как соотносятся понятия база данных и банк данных ?
 одно и то же

 база данных включает банк данных

+ð+ банк данных включает базу данных

 не связанные понятия
Вариант 3.

Что не входит в понятие банк данных?
 база данных

 технология обработки данных

 алгоритмы обработки данных

ð+ +помещение, где обрабатываются данные

 администраторы базы данных


Задача 5. Логическая и физическая независимость данных.

Вариант 1.

Что дает логическая и физическая независимость данных?

ð+ +изменение прикладных программ не приводит к изменению физического представления базы данных

 изменение программ СУБД не приводит к изменению физического представления данных

+ð+ изменение физического представления данных не приводят к изменению прикладных программ

+ð+ изменение программ СУБД не приводит к изменению прикладных программ


Вариант 2.

К чему приведет отсутствие логической и физической независимости данных?
+ð+ к необходимости изменения прикладных программ при изменении физического представления базы данных

 к большей достоверности данных

ð+ +к возможному изменению физического представления данных при изменении прикладных программ

 к более эффективному взаимодействию пользователей с базой данных


Вариант 3.

В чем состоит логическая и физическая независимость данных в базах данных ?
+ð+ представление о данных в прикладных программах и физическое представление данных в компьютере независимы.

 данные одной прикладной программы независимы от данных другой прикладной программы

+ð+ изменение прикладных программ не приводит к изменению физического представления базы данных

+ð+ изменение прикладных программ не приводит к изменению программ СУБД
Задача 6. Что такое логическая и физическая целостность базы данных?

Вариант 1.

Основные цели обеспечения логической и физической целостности базы данных?
 защита от неправильных действий прикладного программиста

 защита от неправильных действий администратора баз данных

ð+ +защита от возможных ошибок ввода данных

+ð+ защита от машинных сбоев

+ð+ защита от возможного появления несоответствия между данными после выполнения операций удаления и корректировки

Вариант 2.

Какие средства используются в СУБД для обеспечения логической целостности?
+ð+ Контроль типа вводимых данных

+ð+ Описание ограничений целостности и их проверка

 Блокировки

 Синхронизация работы пользователей

Вариант 3. Какие средства используются в СУБД для обеспечения физической целостности?
 контроль типа вводимых данных

 описание ограничений целостности и их проверка

+ð+ блокировки

+ð+ транзакции

+ð+ журнал транзакций

Задача 7. Что такое транзакция?

Вариант 1.

В чем суть использования механизма транзакций?
 изменения в базу данных вносятся каждой операцией

+ð+ изменения в базу данных вносятся только после выполнения определенной последовательности операций

 изменения в базу данных вносятся только администратором базы данных

 изменения в базу данных вносятся только при определенных условиях

Вариант 2.

При каких условиях система меняет данные в базе данных?
+ð+ по завершению транзакции

+ð+ по оператору commit

 по указанию администратора

 по оператору модификации данных

Вариант 3.

Для чего ведется журнал транзакций?
 для анализа действий с базой данных

 для использования прикладными программами

 для проверки правильности данных

ð+ для восстановления базы данных

Задача 8. Что такое синхронизация работы пользователей?

Вариант 1.

Зачем нужна синхронизация?

 для ускорения работы прикладных программ

 для восстановления базы данных после сбоев

ð+ для предотвращения нарушения достоверности данных

 для поддержки деятельности системного персонала

Вариант 2.

Какие средства используются для синхронизации?
ð+ блокировки

 транзакции

 пароли

 описание полномочий

Вариант 3.

Последовательность действий СУБД при синхронизации:
 установка блокировки, начало транзакции, снятие блокировки, завершение транзакции
+ð+ начало транзакции, установка блокировки, завершение транзакции, снятие блокировки

 начало транзакции, установка блокировки, продолжение транзакции, снятие блокировки, завершение транзакции
+ð+ начало транзакции, установка блокировки, выполнение транзакции, откат транзакции, снятие блокировки

Литература


  1. Дейт К.Дж. Введение в системы баз данных: Пер. с англ. – 6-е изд. – К.: Диалектика, 1998. – 784 с.

  2. Конноли Т., Бэгг К., Страчан А. Базы данных: проектирование, реализация и сопровождение. Теория и практика. 2-е изд.: Пер. с англ. – М.: Издательский дом «Вильямс», 2000. – 1120 с.

  3. Крёнке Д. Теория и практика построения баз данных. 8-е изд. – СПб.: Питер, 2003. – 800 с.


Лекция 3. Различные архитектурные решения, используемые при реализации многопользовательских СУБД. Краткий обзор СУБД.

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

Цель лекции: показать основные варианты технологии работы нескольких пользователей с одной базой данных, связанные как с основными свойствами вычислительной техники так и с развитием программного обеспечения.
Как уже отмечалось, понятие базы данных изначально предполагало возможность решения многих задач несколькими пользователями. В связи с этим, важнешей характеристикой современных СУБД является наличие многопользовательской технологии работы. Разная реализация таких технологий в разное время была связана как с основными свойствами вычислительной техники так и с развитием программного обеспечения. Дадим краткую характеристику этих технологий в хронологическом порядке.
3.1. Централизованная архитектура

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

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

  • На том же компьютере установлены СУБД и приложение для работы с БД .

  • Пользователь запускает приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к БД на выборку/обновление информации.

  • Все обращения к БД идут через СУБД, которая инкапсулирует внутри себя все сведения о физической структуре БД.

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

  • Результат СУБД возвращает в приложение.

  • Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.




Рис. 3.1. Централизованная архитектура
Подобная архитектура использовалась в первых версиях СУБД DB2, Oracle, Ingres [81].

Многопользовательская технология работы обеспечивалась либо режимом мультипрограммирования (одновременно могли работать процессор и внешние устройства – например, пока в прикладной программе одного пользователя шло считывание данных из внешней памяти, программа другого пользователя обрабатывалась процессором), либо режимом разделения времени (пользователям по очереди выделялись кванты времени на выполнении их программ). Такая технология была распространена в период «господства» больших ЭВМ (IBM-370, ЕС-1045, ЕС-1060). Основным недостатком этой модели является резкое снижение производительности при увеличении числа пользователей.
3.2. Технология с сетью и файловым сервером (архитектура «файл-сервер»)

Увеличение сложности задач, появление персональных компьютеров и локальных вычислительных сетей явились предпосылками появления новой архитектуры «файл-сервер». Эта архитектура баз данных с сетевым доступом предполагает назначение одного из компьютеров сети в качестве выделенного сервера, на котором будут храниться файлы базы данных [362]. В соответствии с запросами пользователей файлы с файл-сервера передаются на рабочие станции пользователей, где и осуществляется основная часть обработки данных. Центральный сервер выполняет в основном только роль хранилища файлов, не участвуя в обработке самих данных (рис.3.2.).


Рис. 3.2.. Архитектура «файл-сервер»
Работа построена следующим образом:

  • База данных в виде набора файлов находится на жестком диске специально выделенного компьютера (файлового сервера).

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

  • На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к БД на выборку/обновление информации.

  • Все обращения к БД идут через СУБД, которая инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на файловом сервере.

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

  • При необходимости (в случае изменения данных) данные отправляются назад на файловый сервер с целью обновления БД.

  • Результат СУБД возвращает в приложение.

  • Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.


В рамках архитектуры «файл-сервер» были выполнены первые версии популярных так называемых настольных СУБД, таких, как dBase и Microsoft Access.

В литературе [362] указываются следующие основные недостатки данной архитектуры:

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

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

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

  • В БД на файл-сервере гораздо проще вносить изменения в отдельные таблицы, минуя приложения, непосредственно из инструментальных средств (например, из утилиты Database Desktop фирмы Borland для файлов Paradox и dBase); подобная возможность облегчается тем обстоятельством, что фактически у таких СУБД база данных – понятие более логическое, чем физическое, поскольку под БД понимается набор отдельных таблиц, сосуществующих в отдельном каталоге на диске. Все это позволяет говорить о низком уровне безопасности – как с точки зрения хищения и нанесения вреда, так и с точки зрения внесения ошибочных изменений.

  • Недостаточно развитый аппарат транзакций служит потенциальным источником ошибок в плане нарушения смысловой и ссылочной целостности информации при одновременном внесении изменений в одну и ту же запись.


3.3. Технология «клиент – сервер»

Использование технологии «клиент – сервер» предполагает наличие некоторого количества компьютеров, объединенных в сеть, один из которых выполняет особые управляющие функции (является сервером сети).

Так, архитектура «клиент – сервер» разделяет функции приложения пользователя (называемого клиентом) и сервера. Приложение-клиент формирует запрос к серверу, на котором расположена БД, на структурном языке запросов SQL (Structured Query Languague), являющемся промышленным стандартом в мире реляционных БД. Удаленный сервер принимает запрос и переадресует его SQL-серверу БД. SQL-сервер – специальная программа, управляющая удаленной базой данных. SQL-сервер обеспечивает интерпретацию запроса, его выполнение в базе данных, формирование результата выполнения запроса и выдачу его приложению-клиенту. При этом ресурсы клиентского компьютера не участвуют в физическом выполнении запроса; клиентский компьютер лишь отсылает запрос к серверной БД и получает результат, после чего интерпретирует его необходимым образом и представляет пользователю. Так как клиентскому приложению посылается результат выполнения запроса, по сети «путешествуют» только те данные, которые необходимы клиенту. В итоге снижается нагрузка на сеть. Поскольку выполнение запроса происходит там же, где хранятся данные (на сервере), нет необходимости в пересылке больших пакетов данных. Кроме того, SQL-сервер, если это возможно, оптимизирует полученный запрос таким образом, чтобы он был выполнен в минимальное время с наименьшими накладными расходами [22, 36]. Архитектура системы представлена на рис. 3.3.

Все это повышает быстродействие системы и снижает время ожидания результата запроса. При выполнении запросов сервером существенно повышается степень безопасности данных, поскольку правила целостности данных определяются в базе данных на сервере и являются едиными для всех приложений, использующих эту БД. Таким образом, исключается возможность определения противоречивых правил поддержания целостности. Мощный аппарат транзакций, поддерживаемый SQL-серверами, позволяет исключить одновременное изменение одних и тех же данных различными пользователями и предоставляет возможность откатов к первоначальным значениям при внесении в БД изменений, закончившихся аварийно [22, 36].


Рис. 3.3. Архитектура «клиент – сервер»
Итак, в результате работа построена следующим образом:

  • База данных в виде набора файлов находится на жестком диске специально выделенного компьютера (сервера сети).

  • СУБД располагается также на сервере сети.

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

  • На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к СУБД, расположенной на сервере, на выборку/обнов­ление информации. Для общения используется специальный язык запросов SQL, т.е. по сети от клиента к серверу передается лишь текст запроса.

  • СУБД инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на сервере.

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

  • Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.

Рассмотрим, как выглядит разграничение функций между сервером и клиентом.

  • Функции приложения-клиента:

  • Посылка запросов серверу.

  • Интерпретация результатов запросов, полученных от сервера.

  • Представление результатов пользователю в некоторой форме (интерфейс пользователя).

  • Функции серверной части:

  • Прием запросов от приложений-клиентов.

  • Интерпретация запросов.

  • Оптимизация и выполнение запросов к БД.

  • Отправка результатов приложению-клиенту.

  • Обеспечение системы безопасности и разграничение доступа.

  • Управление целостностью БД.

  • Реализация стабильности многопользовательского режима работы.

В архитектуре «клиент – сервер» работают так называемые «промышленные» СУБД. Промышленными они называются из-за того, что именно СУБД этого класса могут обеспечить работу информационных систем масштаба среднего и крупного предприятия, организации, банка. К разряду промышленных СУБД принадлежат MS SQL Server, Oracle, Gupta, Informix, Sybase, , DB2, InterBase и ряд других [362].

Как правило, SQL-сервер обслуживается отдельным сотрудником или группой сотрудников (администраторы SQL-сервера). Они управляют физическими характеристиками баз данных, производят оптимизацию, настройку и переопределение различных компонентов БД, создают новые БД, изменяют существующие и т.д., а также выдают привилегии (разрешения на доступ определенного уровня к конкретным БД, SQL-серверу) различным пользователям [362].

Рассмотрим основные достоинства данной архитектуры по сравнению с архитектурой «файл-сервер»:

  • Существенно уменьшается сетевой трафик.

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

  • Наличие специального программного средства – SQL-сервера – приводит к тому, что существенная часть проектных и програм­мистских задач становится уже решенной.

  • Существенно повышается целостность и безопасность БД.

К числу недостатков можно отнести более высокие финансовые затраты на аппаратное и программное обеспечение, а также то, что большое количество клиентских компьютеров, расположенных в разных местах, вызывает определенные трудности со своевременным обновлением клиентских приложений на всех компьютерах-клиентах. Тем не менее, архитектура «клиент – сервер» хорошо зарекомендовала себя на практике, в настоящий момент существует и функционирует большое количество БД, построенных в соответствии с данной архитектурой.
3.4. Трехзвенная (многозвенная) архитектура «клиент – сервер».

Трехзвенная (в некоторых случаях многозвенная) архитектура (N-tier или multi-tier). представляет собой дальнейшее совершенствование технологии «клиент – сервер». Рассмотрев архитектуру «клиент – сервер», можно заключить, что она является 2-звенной: первое звено – клиентское приложение, второе звено – сервер БД + сама БД. В трехзвенной архитектуре вся бизнес-логика (деловая логика), ранее входившая в клиентские приложения, выделяется в отдельное звено, называемое сервером приложений. При этом клиентским приложениям остается лишь пользовательский интерфейс. Так, в качестве клиентского приложения в описанном выше примере выступает Web-браузер.

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

Итак, в результате работа построена следующим образом:

  • База данных в виде набора файлов находится на жестком диске специально выделенного компьютера (сервера сети).

  • СУБД располагается также на сервере сети.

  • Существует специально выделенный сервер приложений, на котором располагается программное обеспечение (ПО) делового анализа (бизнес-логика) [18].

  • Существует множество клиентских компьютеров, на каждом из которых установлен так называемый «тонкий клиент» – клиентское приложение, реализующее интерфейс пользователя.

  • На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение – тонкий клиент. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к ПО делового анализа, расположенному на сервере приложений.

  • Сервер приложений анализирует требования пользователя и формирует запросы к БД. Для общения используется специальный язык запросов SQL, т.е. по сети от сервера приложений к серверу БД передается лишь текст запроса.

  • СУБД инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на сервере.

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

  • Сервер приложений возвращает результат в клиентское приложение (пользователю).

  • Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.


3.5. Краткий обзор СУБД

Многие авторы классифицируют СУБД на две большие категории: так называемые «настольные» и «серверные».


1   2   3   4   5   6   7   8   9   ...   24


написать администратору сайта