Слайд 1СЕТЕВЫЕ ПЛАТФОРМЫ РЕЛЯЦИОННЫХ БД
1. Файл-серверные платформы реля-ционных БД
2. Клиент-серверные
платформы ре-ляционных БД
Слайд 2ВВЕДЕНИЕ
Системы БД удобно рассмат-ривать как простую структуру, состоящую
из сервера (собст-венно СУБД) и набора клиен-тов (приложений). Клиент и
сервер зачастую выполняются на отдельных ЭВМ, обеспечивая таким образом простейший вари-ант распределенной обработки данных.
Слайд 3 В общем случае каждый сер-вер может обслуживать много
клиентов, а каждый клиент может работать со многими серверами. Если
система обе-спечивает полную прозрач-ность доступа (т.е. клиент работает так, как будто он имеет дело с одним сервером на единственном компьютере, невзирая на реальное физи-ческое положение дел), то в таком случае мы имеем распределенную БД.
Слайд 4 Основной целью данной лек-ции является рассмотрение файл-серверных и
клиент-серверных технологий в информационных системах. Как выяснится из рассмот-рения этих
технологий, кли-ент-серверные платформы обладают рядом преиму-ществ перед файл-сервер-ными платформами. Мы рас-смотрим обзор этих преиму-ществ.
Слайд 5
1. Файл-серверные платформы реляционных БД
Основной принцип реализа-ции файл-серверного
прило-жения состоит в том, что об-работка данных ведется рабо-чей станцией,
а сервер служит просто как дополнительное, доступное всем пользовате-лям дисковое устройство.
Слайд 6 Это означает, что при выпол-нении задачи вся БД
или зна-чительная ее часть прокачива-ется по сети на рабочую станцию
и там обрабатывается процессором рабочей станции. Быстродействие такой системы зависит от быстродействия дис-ка сервера, скорости передачи данных по сети, мощности процессора рабочей станции, объема ее ОЗУ и некоторых других факторов.
Слайд 7 Центральный процессор сер-вера играет второстепенную роль и должен
просто обе-спечивать передачу потока данных с сетевого канала на диск
и обратно, по возмож-ности не замедляя этот про-цесс. Главным при таком подходе является то, что практически вся БД перегоня-ется по сети на рабочую станцию для последующей обработки.
Слайд 8 Информационные системы типа файл-сервер можно строить двумя способами:
с
использованием несетевых СУБД, предназначенных для применения на отдельной ЭВМ;
с использованием
сетевых СУБД, разрабатываемых для применения в локальных вычислительных сетях (ЛВС).
Слайд 9 Под сетевой СУБД понима-ется система с произвольной моделью
данных (не обяза-тельно сетевой), ориентиро-ванная на использование в сети.
Программа несетевой СУБД и используемые ею данные могут храниться как на компьютере-сервере (КС), так и на компьютере-клиен-те (КК).
Слайд 10 Запуск и функционирование несетевой СУБД, хранящейся на КК,
и работающей с локальными данными, не отличается от обычного режи-ма
работы на отдельной ПЭВМ. Если используемые данные хранятся на КС, файловая система сетевой ОС «незаметно» для СУБД выполняет подгрузку нужного файла с удаленного компью-тера.
Слайд 11 Если несетевая СУБД используется несколькими пользователями сети, то
ее программы, а также БД или ее часть в целях
экономии дисковой памяти эффективнее хранить на КС. Хранимую на КС БД называют центральной БД (ЦБД), а хранимую на КК БД – локальной БД (ЛБД). При запуске СУБД в таком варианте на каждый КК пересылается полная копия основной программы СУБД и один или несколько файлов ЦБД.
Слайд 12
Рисунок 1 – Система типа файл-сервер с несетевой
СУБД
Слайд 13 Из рисунка 1 следует, что после завершения работы
файлы ЦБД должны пересылаться с КК об-ратно на КС для
согласования данных. Существенным недо-статком такого применения несе-тевых СУБД является возмож-ность нарушения целостности данных при одновременной ра-боте с одной БД нескольких пользователей.
Слайд 14 Поскольку каждая копия СУБД функционирует «не зная» о
ра-боте других ее копий, то никаких мер по исключению возможных
конфликтов не принимается. При этом элементарные операции чтения-записи одних и тех же файлов, как правило, контроли-рует сетевая ОС. В качестве примеров несетевых СУБД мож-но назвать их первые версии (dBASE IV, FoxBase и др.).
Слайд 15 Сетевые СУБД не имеют указанного недостатка, так как
в них предусматривается «контроль соперничества» (concurrency control). Средства контроля позволяют
осущест-влять координацию доступа к данным, например, введе-нием блокировок к файлам, кортежам и даже отдельным атрибутам кортежей.
Слайд 16
Контроль
Рисунок 2 – Система типа файл-сервер с сетевой СУБД
Слайд 17 В сетевых СУБД с коллективным использованием файлов БД
по-прежнему вся обработка инфор-мации производится на КК, а функции КС
сводятся к предо-ставлению большой дисковой памяти. Такой подход нельзя считать эффективным, так как для обеспечения приемлемой скорости процесса обработки ин-формации КК должен обладать высоким быстродействием и иметь большую емкость ОП.
Слайд 18 Кроме того, пересылка копий файлов БД и
команд управ-ления блокировками по линиям связи существенно увеличивает нагрузку на
подсистему передачи дан-ных, что снижает общую производительность сети.
К числу других недостатков технологии «файл-сервер» можно отнести:
Слайд 19разрушение индексов в самый неподходящий момент, напр., при выполнении срочных
ра-бот (индекс – средство уско-рения операции поиска корте-жей в отношении,
а также вы-полнения других операций, использующих поиск: извле-чение, модификация, сорти-ровка и др.);
Слайд 20монопольный захват какого-либо сетевого файла одним из пользователей, делающий невозможной
общую работу с этим файлом;
затруднение соблюдения кон-фиденциальности.
Из-за этих
недостатков приме-нение файл-серверных сис-тем ограничено небольшими сетями и БД.
Слайд 21
2. Клиент-серверные платформы реляционных БД
Для сетей с большим
количе-ством пользователей более предпочтительной является технология «клиент-сервер».
Клиент-серверные платфор-мы
уверенно вытесняют плат-формы типа «файл-сервер», обладая рядом преимуществ.
Слайд 22 Технология «клиент-сервер» означает такой способ взаи-модействия программных ком-понентов,
при котором они образуют единую систему. Как видно из названия,
существу-ет некоторый клиентский процесс, требующий опреде-ленных ресурсов, а также серверный процесс, который эти ресурсы предоставляет.
Слайд 23 Информационные системы ти-па клиент-сервер отличают-ся от систем типа
файл-сервер прежде всего тем, что программы СУБД функцио-нально разделены на
две части, называемые сервером и клиентом. Между клиент-ской и серверной частями воз-можны различные варианты распределения функций.
Слайд 24 Клиент, или фронтальная программа, отвечает за ин-терфейс с
пользователем, для чего преобразует его запросы и команды запросов к
серверной части, а при полу-чении результатов выполняет обратное преобразование и отображение информации для пользователя.
Слайд 25 В роли клиента выступает поль-зовательская программа (разра-батываемая для
решения кон-кретной прикладной задачи) или готовая программа, имеющая интерфейс с
серверной про-граммой. В качестве готовых клиентских программ могут ис-пользоваться текстовые и таб-личные процессоры и даже СУБД (напр., Access, FoxPro, Paradox и др.).
Слайд 26 Сервер является основной про-граммой, выполняющей функции управления и
защиты данных в БД. В случаях, когда вызов функций сервера
выполняется на языке SQL, его называют SQL-сервером. В качестве сер-вера может использоваться ядро профессиональной реляционной СУБД или некоторый SQL-сер-вер (напр., Microsoft SQLсер-вер).
Слайд 27
Рисунок 3 – Упрощенная структура информационной
системы типа
клиент-сервер
Слайд 28 Основная часть обработки ин-формации по формированию за-просов, составлению
отчетов, представлению данных в удоб-ной для пользователя виде вы-полняется на
КК. Полные копии файлов БД из КС на КК и обрат-но (как в случае систем на базе сетевых СУБД) не пересылаются, поскольку для организации пол-ноценного взаимодействия, как правило, достаточно иметь на КК необходимые в данный момент времени кортежи БД.
Слайд 29 Все это существенно снижает трафик в сети, ослабляет
требо-вания к ресурсам КК, позволяет создавать более эффективные и надежные
информационные сис-темы. Часто на КС, кроме дан-ных, хранят программы обработ-ки этих данных и запросы. Это обеспечивает увеличение скоро-сти обработки данных, а также эффективность хранения и адми-нистрирования программ и запро-сов общего пользования в одном месте (на КС).
Слайд 30ПОНЯТИЯ ТРИГГЕРА И КУРСОРА
Хранимые на КС программы (процедуры)
обработки дан-ных называют хранимыми процедурами. Разновиднос-тью хранимой процедуры яв-ляется так
называемый триг-гер. Триггер (триггерная процедура) автоматически вы-зывается при возникновении определенных событий в БД.
Слайд 31 В качестве событий могут быть следующие: операции вставки,
обновления и удале-ния отдельных кортежей, ат-рибутов и др. Примером триг-гера
является программа, за-пускающая процесс посылки сообщения по электронной почте при достижении раз-мера БД (количества корте-жей предельного значения).
Слайд 32 В БД сервера некоторых систем можно хранить и
сами запросы, называемые храни-мыми командами. Совокуп-ность хранимых команд – это
поименованная совокупность команд, получаемых в резуль-тате компиляции SQL-запро-са. Хранимые команды вы-полняются значительно быст-рее, чем соответствующий SQL-запрос.
Слайд 33 Основная причина ускорения состоит в том, что при
выпол-нении хранимых команд не требуется синтаксический раз-бор запросов. Дополнитель-ное ускорение
выполнения запросов может быть полу-чено в тех случаях, когда сервер БД не просто сохра-няет коды команд запросов, а производит оптимизацию со-храняемого кода.
Слайд 34 С хранимыми процедурами и командами связано понятие курсора,
отличающееся от привычного понятия курсора как указателя текущей пози-ции на
экране монитора. В разных СУБД это близкие , но несколько отличающиеся по-нятия. Наиболее широко это понятие трактуется в СУБД SQLBase. Здесь курсор озна-чает следующее:
Слайд 35идентификатор сеанса связи пользователя с СУБД;
идентификатор хранимых команд и процедур;
идентификатор
результирую-щего множества;
указатель текущей строки в результирующем множестве, обрабатываемом клиентским приложением.
Слайд 36Стандартный интерфейс ODBC
При построении информаци-онных систем типа клиент-сервер
возникает проблема доступа со стороны СУБД или приложений, разработанных в
одной среде, к данным, по-рожденным другой СУБД.
Слайд 37 В среде Windows эта проблема решается с помощью
стандарт-ного интерфейса ODBC (Open Database Connectivity – совмес-тимость открытых баз
данных) фирмы Microsoft. Основное его назначение заключается в обес-печении унифицированного до-ступа к локальным и удаленным базам данных различных про-изводителей. Схема доступа к БД с помощью ODBC показана на следующем слайде.
Слайд 39 Доступ приложения к данным происходит путем вызова на
язы-ке SQL стандартных функций ин-терфейса ODBC. На компьютере-клиенте при этом
должна функ-ционировать ОС MS Windows с интерфейсом ODBC. Взаимо-действие приложения с данными производится с помощью менед-жера (диспетчера) драйверов, который подключает необходи-мый драйвер в соответствии с форматом данных СУБД.
Слайд 40 Драйвер СУБД, используя се-тевые средства, как правило, коммуникационные
модули кон-кретной СУБД, передает SQL-запросы серверу СУБД. Резуль-таты выполнения запросов
на сервере либо передаются об-ратно в приложение (клиенту), либо сервер производит моди-фикацию содержимого БД. Кли-ент принимает переданные сер-вером данные, форматирует их и предоставляет пользователю.
Слайд 41Преимущества архитектуры клиент-сервер перед
архитектурой файл-сервер
Обработка сервером запроса
включает в себя проверку полномочий клиента, обеспе-чение требований целостнос-ти, собственно
выполнение запроса и передача клиенту необходимых результатов.
Слайд 42 При этом сервер занимается такими проблемами как под-держка
параллельности ра-боты многих клиентов, которая включает в себя, в первую
оче-редь, согласование данных, од-новременно предоставляемых и изменяемых разными клиента-ми. Подобная архитектура об-ладает следующими преиму-ществами:
Слайд 43обеспечивается более широкий доступ к существующим БД;
повышается общая производи-тельность системы.
Поскольку клиенты и сервер находятся на разных компьютерах, их процессы
способны выполнять приложения параллельно. При этом настройка производительности сервера упро-щается, если на компьютере, вы-деленном под сервер, выполняется только работа с БД;
Слайд 44сокращается нагрузка на ком-пьютерную сеть. Это проис-ходит прежде всего за
счет того, что в ответ на запрос клиента сервер возвращает
ему готовые результаты за-проса, а не все данные, необходимые для их получе-ния;
Слайд 45существует тенденция к сниже-нию стоимости аппаратного обес-печения, так как наиболее
ресур-соемкими операциями для любой СУБД является выполнение ре-ляционных запросов. В
случае клиент-серверной платформы все они выполняются на сервере, сле-довательно, высокие аппаратные требования предъявляются те-перь в первую очередь к компью-теру, выделенному под сервер;
Слайд 46появляется возможность ис-пользования специализиро-ванного аппаратного обеспе-чения для сервера, которое может
быть сконструировано именно для работы на сер-вере БД. Это очень
сущест-венный аспект повышения об-щей производительности ра-боты системы;
Слайд 47клиент-серверные системы, как показывают проведенные экспе-рименты и сравнительный ана-лиз, будут
работать с вполне приемлемой скоростью с БД такого объема и
с таким числом одновременных соединений, с ко-торыми файл-серверная система работать не сможет в том смысле, что ее функциональность, в том числе и быстродействие, станут неприемлемыми для коммерче-ских приложений;
Слайд 48клиент-серверные системы имеют встроенный механизм работы с транзакциями, в том
числе и их отката. В файл-серверных системах меха-низм управления транзак-циями
представляет собой блокировку всей БД до за-вершения выполнения крити-ческих по времени операций одной из рабочих станций.
Слайд 49 Откат возможен только при сохранении работоспособности рабочей станции,
иницииро-вавшей транзакцию.
В клиент-серверной системе этот механизм значительно более
сложный. Он устроен так, что даже выход из строя рабочей станции не столь опа-сен для целостности БД.
Слайд 50 Кроме того, клиент-серверная система ведет так называемый журнал
транзакций. По сути БД хранится в виде ее начального содержимого
и модификаций, записанных в журнал транзак-ций. Это позволяет производить архивирование БД во время работы всей системы, при этом процесс архивирования легко поддается автоматизации.
Слайд 51ЗАКЛЮЧЕНИЕ
На основе изучения двух сетевых архитектур реляци-онных
БД можно сделать следующие выводы относи-тельно преимуществ системы клиент-сервер.
1. Главный аргумент связан с возможностью организации па-раллельной обработки данных, что повышает производитель-ность системы.
Слайд 52 2. Машина сервера может быть изготовлена по специальному
заказу только для работы с СУБД («машина баз данных»). Такое
решение позволяет до-полнительно повысить произ-водительность СУБД.
3. Машина клиента может представлять собой персональ-ную рабочую станцию, макси-мально приспособленную к по-требностям конкретного конеч-ного пользователя.
Слайд 53 4. К одной и той же машине сервера
могут иметь доступ несколько разных машин кли-ентов. Поэтому одна БД
мо-жет совместно использовать-ся несколькими различными клиентскими системами.
Отметим, что работа сервера и клиента на отдельных машинах отвечает принципам работы многих предприятий.
Слайд 54 Вполне типичный способ функ-ционирования отдельных пред-приятий (напр., банков)
заклю-чается в использовании многих компьютеров, причем данные для одной части
предприятия хранятся на одном компьютере, а данные для другой части - на другом. Поэтому, вообще говоря, каждая машина может выступать в роли сервера для одних пользователей и в роли клиента – для других.
Слайд 55ЛИТЕРАТУРА
1. Дейт, К., Дж. Введение в системы баз
данных, 7-е изд.: Пер.с англ. – М.: Издатель-ский дом «Вильямс».
– 2001. – 1072 с.
2. Мирошниченко Г. А. Реля-ционные базы данных: прак-тические приемы оптималь-ных решений. – СПб.: БХВ-Петербург. – 2005. – 400 с.