- •Базы данных
- •1. Введение в базы данных
- •1.1. Базы данных и информационные системы
- •1.2. Архигсюура информационной системы
- •1.3. Системы управления базами данных
- •1.4. Локальные информационные системы
- •1.5. Способы разработки и выполнения приложений
- •1.6. Схема обмена данными при работе с бд
- •2. Модели и типы данных
- •2.1. Иерархическая модель
- •Сотоудники
- •2.2. Сетевая модель
- •2.3. Реляционная модель
- •2.4. Постреляционная модель
- •2.5. Многомерная модель
- •1996 1994 Петров Смирнов Яковлев
- •2.6. Объектно-ориентированная модель
- •2.7. Типы данных
- •3. Реляционная модель данных
- •3.1. Определение реляционной модели
- •3.2. Индексирование
- •3.3. Связывание таблиц
- •3.4. Контроль целостности связей
- •3.5. Теоретические языки запросов
- •I аспределенное Удаленное Распределен- Удаленн! 1йдо- Распределен- предстаеление представление ная функция ступ к данным наяЬд
- •4.5. Информационные системы в Интернете и интранете
- •Часть 2. I Ъоектиросанн ? и использование бд
- •7. Средства автоматизации проектирования
- •7.1. Основные определения
- •7.8. Рекомендации по применению case-систем
- •9. Дополнительные вопросы применения баз данных
- •9.1. Программно-аппаратные платформы
- •9.2. Перспективы развития субд
- •9.3. Стандартизация баз данных
- •9.4. Характеристика технологии ado.Net
- •10.1. Общая характеристика
- •10.2. Новые возможности Microsoft Access 2002
- •10.3.Средства поддержки проектирования
- •10.4. Создание основных элементов бд
- •IQdbl mdb
- •Option Compare Database Public Function funl() beep End Function
- •10.5. Работа с гиперссылками
- •10.6. Использование языка sql
- •Аргументы макрокоманды ' Инструкция sQl. Select distinctrow tof
- •10.7. Защита баз данных
- •10.9. Обслуживание баз данный
- •10.10. Репликация баз данных
- •Реплицируемые объекты
- •Реплицируемые объекты
- •10.11. Работа с мультимедиа-данными
- •Тип объекта
- •Comic Chat Boom Microsoft Graph so Music Prop pry Page 2 1 Option f ropery Page21 Ры-ndox FableВидео-клип
- •10.12. Создание файлов приложений
- •10.13. Страницы доступа к данным
- •Краткая характеристика отличий сДд от форм и отчетом
- •10.14. Разработка проекта
- •Распределение атрибутов по вариантам
- •11.1. Пользовательский интерфейс
- •11.2. Характеристика проекта
- •11.3. Компиляция и выполнение проекта
- •11.4. Разработка приложения
- •11.5. Средства интегрированной среды разработки
- •Управление параметрами среды
- •11.6. Базы данных и средства работы с ними
- •Компоненты приложений для баз данных
- •11.7. Создание таблиц базы данных
- •11.8. Создание приложения bde
- •Значения свойств компонентов
- •11.9. Работа с отчетами
- •12. Субд Visual FoxPro 8.0
- •12.1. Общая характеристика
- •12.2. Новые возможности Visual FoxPro 8.0
- •12.3. Элементы проекта
- •12.4. Интерфейс Visual FoxPro
- •12.5. Средства автоматизации разработки
- •12.6. Создание баз данных
- •12.7. Таблицы и индексы
- •12.8. Организация межтабличных связей
- •12.9. Обеспечение ссылочной целостности
- •12.10. Создание запросов
- •Variables:
- •13. Microsoft sql Server 2000
- •13.1. Характеристика sql Server
- •13.2. Язык запросов Transact-sql
- •13.3. Системные базы данных и таблицы
- •13.4. Создание баз данных
- •13.5. Работа с таблицами
- •15.1. Принципы функционирования Web-приложений
- •15.2. Архитектура Web-приложений, публикующих бд
- •15.3. Обзор Web-серверов
- •15.4. Использование Personal Web-server
- •15.5. Использование Microsoft Internet Information Server
- •15.6. Использование Apache дляMicrosoft Windows 9х/2000
- •Вы видите это вместо ожидаемой страницы?
- •15.7. Варианты создания Web-узла
- •16. Интерфейсы программирования Web-приложений
- •16.1. Общий интерфейс взаимодействия cgi
- •18. Публикация бд средствами Microsoft Access
- •18.1. Характеристика вариантов публикации
!
Компьютер-клиент [I аспределенное Удаленное Распределен- Удаленн! 1йдо- Распределен- предстаеление представление ная функция ступ к данным наяЬд
Рис. 4.1. Спектр моделей архитектуры клиент-сервер
Перечисленные способы распоеделения функции в сис темах с архитектурой клиент-сервер ил чюстрируют различные варианты: от мощного сервера, когда практически вся работа производится на нем, до мощного клиента, когда б шыная часть функций вып< шняегся на раОочей станции, а сервер обраба тывает поступающие к нему по сети SOL-вызовы.
В моделях удаленного дос тупа к данным и удаленного представл< ния производится строгое распределение функций между компьютером клиентом и компьютером-сервером. В других моделях имеет место выполнение одной из следующих функций одновременно на двух компьютерах: управления данными (модель распределенной БД), обработки информации (модель распределенной функции), представления информации (модель распределенного представления).
Рассмотрим сначала модели удаленного доступа к данным и удсигенного представления (сервера БД) как наиболее широко распространенные.
В модели удаленного доступа к данным (Remote Data Access — RDА) программы, реализующие функции представления информации и логику прикладной обработки, совмещены и выполняются на компьютере-клиенте. Обращение за сервисом управ, [ения данными происходит через среду передачи с помощью операторов языка SQL или вызовом функций специальной библиотеки API (Application Programming Interface — интерфейса прикладного профаммирования).
Основное достоинство RDA-модели состоит в большом обилии готовых СУБД, имеющих SQL-интерфейсы, и существующих инструментальных средств, обес печивающих быстрое создани» программ клиентской части. Средства разработки чаще всею поддерживают ]рафический интерфейс пользо вателя в MS Windows, стандарт интерфейса ODBC и средства автоматической генерации кода. Подавляющее большинство средств разработки использует языки четвертого поколения.
Неоостатками RDA модели гвляются, во-первых, довольно высокая загрузка системы передачи данных вследствие того, что вся логика сосредоточена в приложении, а обрабатываемые данные расположены на удаленном узле. Как уви [им далее, во время работы при ложений обычно по сети передаются целые БД.
Во-вторых, системы, п< 'строенные на основе модели RD А, неудобны с точки зрения разработки, модификации и сопровождения. Основная причина со< томт в том, что в получас мых приложениях прик ладные функции и функции представления л есно взаимосвязаны. Поэтому даже при незначительном изменении функций системы требуется переделка всей прикладной ее части, усложн: гющая разработ ку и модификацию системы
Модель сепвера БД( DataBase Server — DBS) отличаетст от предыдущей модели тем что фу нкции компы* >тера-клиента ограничиваются функциями представления ш формации, в то время как прикладные функции обеспечиваются приложением, находящимся на компьютере-сервере. Ята модель является более технологичной чем RDA-модель и применяется в таких СУБД, как Ingress, Sybase и Oracle. При атом приложения pea шлются ь виде хранимых процедур.
Процедуры обычно хранят» я в словаре БД и разделяются несколькими кли- ен гами. В общем случае хранимые процедуры могут выполняться в режимах компиляции и интерпретации.
Достоинствами модели DBS являются: возможность хорошего централизованного администрирования приложений на этапах разработт и. сопровождения и модификации, а также эффективное испо льзование вычислительных и коммуникационных ресурсов. Последнее достигается за счет того, что выполнение программ в режиме коллективного пользования требует существенно меньших затрат на пересылку данных в сети
Один из недостатков модели DBS связан с ограничениями средств разработки хранимых процедур. Основное ограничение — сильная привязка операторов хранимых процедур к конкретной СУБД Язык написания хра нимых процедур, по сути, является процедурным расширением языка SQL, и не может соперничать по выразительным средствам и функциональным возможностям с т радиционными языками третьего поколения, такими как С и Pascal. Кроме того, в большинстве СУБД нет удовлетворительных средств отладки и ле< тирования хранимых процедур, что делает их механизм опасным инструментом — неотлаженные программы могут приводить к некорректностям БД, зависаниям серверных и клиентских программ во время работ ы системы и т. п.
Другим Heooi шатком DBS-модели является низкая эффективность использования вычислительных ресурсов ЭВМ, поскольку не удается организовать управление входным потоком запросов к программам компьютера-сервера а также обеспечил ь перемещение процедур на другие компьютеры серверы.
В модели распределегного представления имеется мощный компьютер- сервер, а клиентская часть системы прак гически вырождена. Функцией клиентской части является просто отображение информации на экране монитора и евгаь с основным компьютером через локальную сеть.
СУБД подобного рода могут иметь место в сетях, поддерживающих работу так называемых Х-тпер.линалов. В них основной компьютер (хост-машина) должен иметь дост аточную мощность, чтоб] i обслуживать несколько Х-тер- миналов. X-терминал тоже должен обладать достаточно быстрым процессором и иметь достат очный объем оперативной памяти (дисковые накопители отсутствуют). Часто X-терминалы создают на базе RISC-компьютеров (restricted | reduced] instruction set computer) — компьютеров с сокращенным набором команд. Все программное обеспечение находится на хост-машине. 11рограммное обеспечение X-терминал?, выполняющее функции управления представлением и сетевые функции, загружается по сети с сервера при включении X-терминала.
Модель распределенного представления имели СУБД ранних поколений, которые работали на малых, средних и больших ЭВМ. В роли Х-терминалов выступали дисплейные станции и абонентские пункты (локальные и удаленные). В этом случае основную часть функций представления информации реашзовыва ш сами СУБД, а окончательное построение изображений на терминалах пользователя выполнялось на оконечных устпойствах.
11о модели распределенного преде гавления построены системы обслуживания пользователей БД в гетерогенной (неоднородной) среде. Серверная часть таких сис гем обычно обе< печивает некоторый уiшфицкрованный интерфейс, а клиентские час ги pea лизуют функции учета специфики оконечного оборудования или преоОразовани одного формата представления информации в другой.
Модель распределенного представления pea тиз/ет централизованную схему управления вычислительными ресурсами. Отсюда следуют ее основные достоинства — простота обслуживания и управ, [ения доступом к системе и относительная дешевизна (ввиду невысокой стоимости оконечных терминалов). Недостатками модели являются уязвимость системы при невысокой надежности центра гьного узла, а также высокие требования к серверу по производительности при большом числе клиентов.
В модели распределенной функции логика i >бработки данных распределена по двум узлам. Такую модель могут иметь ИС, в которых общая час гь прикладных функпий реализована на компыотере-ссрвере, а специфические функции обработки информации выполняются на компьютере-клиенте. Функции общего характера могут i ключать в себя стандартное обеспечение целостности данных, например, в виде хранимых процедур, а остаыыиеся прикладные функции реализуют специальную прикладную обработку. Подобную модель имеют так же ИС. испо гьзующие информацию из нескольких неоднородных БД.
Модель распределенной БД предполагает использование мощного компьютера-клиента причем данные хранятся на компьютере-клиенте и на компьютере- сервере. Взаимосвязь обеих баь данных можрт быть дзух разновидностей: а) в локальной и удаленной базах хранятся отдельные части единой БД; б) локальная и удаленная БД являются синхронизируемыми друг с другом копиями.
Достоинство, модели распределенной БД является гибкость создаваемых на ее основе ИС, позволяющих компьютеру-клиенту обрабатывать локальные и удаленные БД. При наличии механизмов координации соответствия копий система в целом, кроме того, обладает высокой живучестью, так как разрыв соединения клиента и сервера не приводит к краху системы, а ее работа может быть восстановлена с возобновлением соединения. К недостатку модели можно отнести высокие затраты при выполнении бо. гьшого числа одинаковых приложений на компьютегах-клиентах.
Трехзвенная модель распределения функций
Трехзвенная модель распределения функций представляет собой типовой вариант, при котором каждая из трех функций приложения реализуется на отдельном компьютере. Варианты распределения функций приложения на большее число компьютеров могут иметь место, но ввиду их редкого применения рассматриваться не будут.
Рассматривай гая нами модель имеет название модель с 'рвера приложений, или AS-модель (Application Server), и показана на рис. 4.2.
Рис.
4.2. ipex
шенная
модель сервера приложений
Согласно трехзвенной AS-модели, отвечающий за организацию диалога с конечным пользователем процесс, как обычно, реализует функции представления информации и взаимодействует с компонентом приложения так же, как в модели DBS. Компонент приложения, располагаясь на отдельном компьютере, в свою очередь, связан г компонентом управления данными подобно м< дели RI >А.
Цент ральным звеном AS-модели является сервер приложений. На сервере приложений реализуется несколько прикладных функций, каждая из которых оформлена как служба предоставления услуг всем требующим этого программам. Серверов приложений может быть несколько, причем каж дый из них предоставляет свой вид сервиса. Люба i программа, запрашивающая услугу у сервера приложений, является для него клиентом. Поступающие от клиентов к серверам запросы помещаются в очередь, из которой выбираются в соответствии с некоторой дисциплиной, например, по приоритетам.
Компонент, реализующий функции представления и являющийся клиентом для сервера приложений, в этой модели трактуется более широко, чем обычно. Он может служить для организации интерфейса с конечным пользователем, обеспечивать прием данных от устройств, например, датчиков, или быть произвольной программой.
Достоинством AS-модели является i ибкость и универсальное гь вследствие разделения функций приложения на три независимые составляющие. Во многих с тучаях эта модель оказывается более эффективной по сравнению с двух- звенными. Основной неоостаток модели - более высокие затраты ресурсов компьютеров на обмен информацией между компонентами приложения по сравнению с двухзвечными моделями.
Примерами программных продуктов, реализующих среду функционирования приложений на компьютерах-серверах приложений, являются ВЕА WebLogic Server (ВЬА Systems Сотр.), Inprise Application Server (Inprise Corp.) и IBM WebSphere Application Server (IBM Corp.).
Сложные схемы взаимодействия
Возможны более сложные схемы Шзимодейспщщ, например, схемы, в которых элемент, являющийся сервером для некоторого клиента, в свою очередь, выступает в роли клиента по отношению к другому серверу (рис. 4.3). Пример этого мы наблюдали в AS-модели.
Рис.
4.3. Цепочка взаи иодействий типа
клиент-сервер
Возможно также, что в распределенной вычислительной системе при работе с БД имеютсямножеа,гвент и связи (статические), когда один объект по отношению к одним яв^шется клиентом, а по отношению к другим сервером (рис. 4.4).
Рис.
4.4. Множественные связи взаимодействия
типа клиент-сервер
При рассмотрении взаимодействия объектов в динамике получаются еще более сложные схемы взаимодействия. Примером такой схемы является случай, когда в процессе работы роли объектов меняются: объект, являющийся в некоторый момент времени клиентом по отношению к другому объекту, в пос ледующем становится сервером для другого объекта
Модель монитора тран. 'акций
Как отмечалось, наибо. iee гибкой и универсальной моделью распррде тения функций СУБД является AS-модель. Она описывает взаимодействие трех ос новных элементов: клиента, сервера приложений ь сервера БД, но не затрагивает Bonpoci I организации функционирования программного обеспечения при обработке информации, в частности при выполнении транзакций. Для преодоления этого недостатка предложена модель монитора тран шкцин.
Мониторы обработки транзакций (Transaction Processing Monitor — ТРМ), или мониторы тратащпй, представляют собой программные системы категории промежуточного слоя (Middleware), обеспечивающие эффективное управление информационно-вычислительными ресурсами в распределенной вычислительной системе. Основное их назначение — < >рганизация гибкой, открытой среды для разработки и управления мобильными приложениями, оперативно обрабатывающими распределенные транзакции. Применение мониторов тран- защий наиболее эффект ивно в гетерогенных вычислительных системах.
Приложение ТРМ позволяет выполнять мает габироьание системы, поддерживать функциональную полноту и целостности приложений а также повысить производительность обработки данных при невысокой стоимости накладных расходов.
Принципы организации обработки информации с помощью монитора транзакций описываются моделью монитора транзакций X/Open DTP ( Distributed Transaction Processing — обработка распределенных транзакций). Эта модель (рис. 4.5) включает в себя три объекта: прикладную программу, менеджер ресурсов (Resource Manager - RM) и монитор, или менеджер транзакций (Transaction Manager — ТМ).
Рис.
4.5. Модель обработ ки транзакций X/Opcn
DTP
В качес тве прикладной программы может выступать произв >льн?я npoi рам- ма-ктиент RM выполняет функции сервера ресурса некоторого вида. Прикладная программаьзаимодействует с RM с помощью набора специальных функций либо посредством операторов SQL (когда сервером является сервер БД).
Интерфейс ATMI (Application Trai isaction Monitor Interface — интерфейс монитора транзакций приложения) позволяет вызывать функции ТРМ на некотором языке программирования, например С.
Функции менеджера ресурсов обычно выполняют серверы БД или СУБД. В задачах организации управления обработкой распределенных транзакций (транзакций, затрагивающих программные объекты вычислительной сети) ТМ взаимодействует с RM, который должен поддерживать протокол двухфазной фиксации транзакций (см. подр. 4.3) и удовлетворять стандарту Х/Ореп ХА. Примерами СУБД, поддерживающих про гокол двухфазной фиксации транзакции, являю- ся Oracle 7.0, Open lN( iRES и Informix-Online 5.0.
Понятие транзакции в ТРМ несколько шире, чем в СУБД, где транзакция включает в себя элемен гарные действия над данными базы. Здесь гранзак ция может охватывать и другие необходимые действия: передачу сообщения, запись информации в файл, опрос датчиков и т. д. Это значит, что ТРМ про- достав шет более мощные средства управления вычислительным процессом. Т] >анза1:ции, которые поддерживаю.' ТРМ, называют также прикладными или бизнес-транзакциями.
Модель Х/Оре n DTP не раскрывав струк гуру ТМ j «етагях, а опредет ier состав компонентов распределенной системы обпаботки информации и как эти компоненты взаимодействуют друг с другом. 1фактические реализации этой модели, естественно, могут отличаться друг от друга В числе примеров pea 1изаций мониторов транзакций можно назвать aCMS, CICS, и TUXEDO System.
Для разработчиков приложений монитооы обработки транзакций ТРМ пре- дос гавляют удобства, связанные с возможностью декомпозиции приложений но неско шким функциональным уровням со с гандартным и ] чтерфей» ами, что позволяет создавать легко модифициру< мые ИС со с тройной архитектурой.
Прикладные программы становятся практически независимыми от конкретной реализации интерфейса с пользователе л и от менеджера ресурсов. Первое означа< т. что дтя реализации функций предсгшле ния можно выбрать любое удобное и привычное для разработчика срещ тво(от языке С до какой-либо CASE-системы). Не- зависимсх ть от м( неджера ресурсов подразумевает возможно^ гь л*ко| замены од ного менеджера ресурсов на другой, лишь бы они поддерживали стандарт взаимодействия с прикладной программой (дтя СУБД — язык SQL).
Если ТРМ поддерживает множество аппаратно-программные платформ, как, например. TUXEDO System, то разраб.lti гааемые приложения становятся, кроме того, мобильными.
Сосредоточение всех прикладных функций в серверах приложений и наличие богатых возможностей управления и администрирования существенно у) (рощает обновление прикладных функций (бизнес-функцип) и контроль за их непротиворечивостью. Изменения в прикладных функциях при этом никак не отражаются на программах-клиентах.
Для пользователей распределенных систем ТРМ позволяют улучшить показатели пропускной способности и времени отклика, снизить стоимость обработки данных в оперативном режиме на основе эффектив] юй организации вычислительного процесса.
Улучш< ние показателей функционирования достига< тся благодаря осуществлению статической и динамической балансировки нагрузки Управление загрузкой состоит в запуске или остановке AS-процессов (программных ком- поне нтов AS-модели) в зависимости от заранее установленных параметров и текущего состояния системы. При необходимости ТРМ может тиражир< «ват ь копии AS-процессов на этом или других узлах сети.
Администраторы распределенных систем, имея ТРМ, получают возможность легкого масштабирования ИС и увеличения производительности обработки информации. Здесь, кроме вертика гьного и горизонтального масштабиоова ния, молено обеспечить так называемое мЛтричноё масштабипование. Суть его - введение дополнительных ресурсов в любую точку гетерогенной вычислительной среды без изменения архитектуры при чожения, рыпо тняемого в новой среде. Это означает, что без остановки серверов приложений в любо° время может быть добавлен, например, компьютер или менеджер ресурсов.
Кроме тою, администраторы систем получают возможность снизить общую стоимость программного обеспечения систем клиент-сервер. Снижение стоимости можно достигнуть прост ым уменьшением количества подключений к серверам БД.
С гоимость серверов БД (или СУБД) в сильной степени зависит от числа одновременных подключений к программе. Уменьшение количес гва подключений к серв< ру БД достигается путем мультиплексирования запросов или, что то же самое, логического преобразования потока запросов от многих источников к потоку от одного или нескольких источников. Выигрыш в стоимости и производи гельности при эффек ивной pea гизации < амих ТРМ может оказаться весьма существенным.
4.3. Управление распределенными данными
С управлением данными в распреде ленных системах связаны следующие две группы проблем: поддержка соответствия БД вносимым изменениям и обеспечение совместного доступа нескольких по. [ьзовател< й к общим данным.
Поддержка соответствия БД вносимым изменениям
В современных распределенных системах информация может храниться централизованно или децентрализованно. В первом случае проблемы идентичности представления информации для всех пользователей не существует, так как все последние изменения хранятся в одном месте. На практике чаще информация изменяется одновременно в нескольких узлах распределенной вычислительной системы. В этом случае возникает проб, [ема контроля за всеми изменениями информации и предоставления ее в достоверном виде всем пользователям.
Существуют две основные технологии децентрализованного управ, гения БД: распределенных БД (Distributed Database) и тиражирован ия, или репчи- кации, БД (Data Replication).
Распределенная БД состоит из нескольких фрагментов, размещенных на разных узлах сети и, возможно, управляемых разными СУБД. С точки зрения программ и пользователей, обращающихся к распределенной БД, последняя воспринимается как единая локальная БД (рис. 4.6).
ВД БД
Рис.
4.6. Модель распределенной БД
3anpoci
i
Информация о местоположении каждой из частей распределенной БД и другая служебная информация хранится в так называемом глобальном словаре данных. В общем случае этот словарь может храниться на одном из узлов или тоже бытг распределенным.
Для обеспечения корректного доступа к распределенной БД в современных системах чаще всего применяется протокол (метод) двухфазной фиксации транзакции (two-phase commit). Суть этого метода состоит в двухэтап- ной синхронизации выполняемых изменений на всех задействованных узлах. На первом этапе в узлах сети производятся изменения (пока обратимые) в их БД, о чем посы. [аются уведомления компоненту системы, управ тяющему обработкой распределенных транзакций.
На втором этапе, получив от всех узлов сообщения о прави тьности выполнения операций (что свидетельствует об отсу гствии сбоев и о гказов аппаратно-программного обеспечения), управляющий компонент выдает всем узлам команду фиксаций изменений. J [осле этого транзакция считается завершенной, а ее результат необратимым.
Основным достоинс твом модели распределенной БД является то, что пользователи всех узлов (при исправных коммуникационных средствах) по
лучают информацию с учетом всех пос ледних изменений Второе достоинство состоит в экономном использовании внешней памяти компьютеров, что позволяет организовывать БД больших объемов.
К недосьштпксш модели распределенной БД относится следующее: жесткие требования к производите шности и надежности каналов связи, а также большие мат раты коммуникационных и вычислительных ресурсов из-за их связывания на все время выполнения транзакций. При интенсивных обращениях к распределенной БД, большом числе взаимодействующих узлоь, низкоскоростных и ненадежных каналах связи обработка запросов по этой схеме становится практически невозможной.
Модель тиражиюования данных, в отличие от технологии распределенных БД, предполагает дублирование данных (создание точных копий) в узлах сети (рис. 4.7). Данные всегда обрабатываются как обычные локальные. Поддержку идентичности копий друг дру1у в асинхронном режиме обеспечивает компонент системы, называемый репткатппои (replicator). При этом между узлами сети могут передаваться как отдельные изменения, так и группы изменений. В течение некоторого времени копии БД могут отличаться друг от друга
БД БД
запросы
Рис. 4.7. Моделы тоажирования БД
К основным достоинства н модели i иражирования БД ( в сравнении с предыдущей моделью) относятся: более высокая скорость доступа к данным, так как они всегда есть в узле; существенное уменьшение передаваемого по каналам связи потока информации, поскольку происходит передача не всех операций доступа к данным, а только изменений в БД; повышение надежности механизмов доступа к распределенным данным, поскольку нарушение связи не приводит к потере работоспособности системы (iфедгюлагается буферизация потока изменений, позволяющая корректно возобновить работ у после восстановления связи).
Основной недостаток модели тиражирования БД заключается в том, что на неко гором интервале времени возможно «ра< хождение» копий БД. Если отмеченный недостаток некритичен для прикладных задач, то предпочтительно иметь схему с тиражированием БД.
Доступ к общим данным
При обслуживании < обращений к общим данным средства управлс ния БД должны обеспгчивать по крайней мере два основных ме тода доступа: монопольный и коллективный. Основными объектами доступа в различных системах могут быть целиком БД. отдельные таблицы, записи, поля записей. В СУБД, предоставл по- щих возможность разработки, объектами дос тупа также могут выступать спецификации отчетов и экранных форм, запросы и программы.
Монопольный доступ обычно используется в двух случаях:
во-первых, когда требуется исключить дослуп к объектам со стороны других пользователей (например, при работе с конфиденциальной информацией);
во-вторых, когда производятся omeemi твенные операции с БД, не допускающие других действий, например, изменение структуры БД.
В первом случае пользователь с помощью диалоговых средств СУБД или прик. (адной пр< (граммы устанавливает явную блокировку. Во втором случае пользователь тоже может установить явную блокировку, либо положиться на СУБД. Последняя обычно автоматически устанавливает неявную (без ведома пользователя или приложения) блокировку, если это необходимо.
В режиме коллективного доступа полная блокировка на используемые обьекты, как правило, не устанавливается. Коллективный доступ возможен, например, при одновремс ином просмот ре таб шц. Попытки по. [учить монопольный доступ к объектам коллею ивного доступа должны быть пресечены. Например, в ситуации когда один или несколько пользоьателей просматривают таблицу, а другой пользователь собирается удали гь эту же таблицу.
Для организации коллективного доступа в СУБД применяется механизм блокировок. Суть блокировки состоит в том, что на время выполнения какой-либо опенации в БД доступ к используемому объект у со стороны других потребителей временно запрещается или ограничивается. Например, при копировании таблицы она блокируется от изменения, хотя и разрешено просматривать ее содержимое.
Рассмотрим некоторый типичный набор блокир< ibok. В конкретных программах схемы блокирования объектов могут отличаться от описываемой.
Выделим четыре вида блокировок, перечисленные в порядке убывания строгости ограничений на возможные действия:
полная блокировка;
блокировка от записи;
предохраняющая блокировка от записи;
предохраняющая полная блокировка.
Ножная блокировка. Означает полное запрещение всяких операций над основными объектами (таблицами, отчетами и экранными формами). Этот вид блокировки обычно применяется при изменении структуры таблицы.
Блокировка от записи. Накл&чыиается в случаях, когда можно и< по. [ьзовать таблицу, но без чзмеш ния ее с грук [уры цли содержимого. Такая оло* ировка применяется, например, при выполнении операции слияния данных из двух таб шц.
Нр\ сохраняющая блокировка oin записи. Предохраняет объект от наложения на него со стороны других операций полной блокировки, либо блокировки от записи. Этот вид блокировки позволяет тому, кто раш ше «захватил» объект, успешно завершить модификацию объекта. Предохраняй ицая блокировка от записи совместима с аналогичной блокировкой (предохраняющей блокировкой от записи), а также с предохраняющей полной блокировкой (см. далее). Примером необходимости использования этой блокировки является режим совместного редактирования таблицы несколькими пользователями.
Предохраняющая полнен. блокировка. Предохраняет объекл от наложения на него со стороны дру1 их операций только полной блокировки Обеспечивает максимальный уровень совмес гного использования объектов. Такая блокировка может использоваться, например, для обеспечения одновременного про< мо гра несколькими пол ьзова * елям и одной таблицы. В группе пользователей, работающих с одной таблицей, эта блокировка не позволит никому изменить структуру общей таблицы.
При незавершенной операции с некоторым объектом и запросе на выпол нение новой операции с этим же объектом производится пош ттка эти операции совместить. Совмещение возможно тогда, когда совместимыми оказываются блокировки, накладываемые конкурирующими операциями.
В отношении перечисленных выше четырех блокировок действуют следующие прави па совмещения.
при наличии полной блокировки над ооъектом нельзя производить операции, приводящие хотя бы к одному из видов блокироьок (полная блокировка несовместима ни с какой другой блокировкой),
блокировка от записи совместима с аналогичной блокировкой и предохраняющей полной блокировкой;
предохраняющая блокиоовка от записи совместима с обоими видами предохраняющих блокировок;
предохраняй >щау полная блокировка совместима со всеми блокировками, кроме полной.
(Обычно в СУБД каждой из выполняемых с БД операций соответствует определенный вид блокировки, которую эта операция накладывает на объект. Пользователям современных СУБД, работающим в инлерак гивном режиме, не нужно помнить все тонкости механизма блокировки, поскольку система до< таточно «разумно» осущег гвляет автоматическое блокирование во всех случаях, когда это требуется. При этом система сама стремится предославить всем пользователям наиболее свободный доступ к объектам. При необходимости пользователь и программист могут воспользоваты я командными или языковыми средствами явного определения блокировок. Например, в СУБД Paradox для явного блокирования отдельной записи во время редактирования таблицы используется команда Record | L оск.
Тупики
Если не управлять доступом к совместно испо льзуемым объектам, то между потребил елями ресурсов могут возникать тупиковые силуации (клинчи, «смертельные объятия» или блокировки). Следует отличать понятие блокировки в смысле контроля доступа к объектам (мы придерживаемся такого термина) от блокировки в смысле тупикового события.
Существует дв'а основных вида тупиков: взаимные (deadlock) и односторонние (livelock).
Простейшим случаем взаимного тупика является ситуация, когда каждый из двух пользова гелей о ремится захватить данные, уже захваченные другим пользовате гем (рис. 4.8а). В этой ситуации пользователь-1 ждет освобождения ресурса N, в то время как пользовагель-2 ожидаеп освобождения от захвата ресурса М. Следовательно, ник го из них не может продолжить работу.
|
Пользователь 1
Пользователь
1
т
\
Требование \ ресурса
N
Захват
ресурса
Q
М
М
{Пользователь
2
а)
| Пользователь 2
б)
Рис. 4.8. Примерь1 взаимных тупиков в распределенных БД
В действительности могут возникат ь и более сложные ситуации, когда выполняются обращения трех и более пользователей к нескольким ресурсам Пример одной из таких ситуаций приведен на рис. 4.86.
Односторонний тупик возникает в случае требования получить монопольный доступ к некотором)' ресурсу как только он (танет доступным и невозможности удовлетворит и это требование.
Системы управления распределенными БД, очевидно, должны иметь соответствующие средства обнаружения или предотвращения конфликтов, а также разрешения возникающих конфликтов. Одной из наиболее сложных является задача устранения конфликтов в неоднородных системах в случае, если некоторая программа не обрабатывает или обрабатывает некорректно сигналы (уведомления) о наличии конфликтов. При этом важно не только сохранить целостность и достоверность данных в распределенных БД, но и восстановит! вычис тительный процесс, иногда пара лизующий пользователей и программы ожиданием чего-то.
Пользователи и разработчики приложений в распределенной среде должны предусматриват ь обработ ку сигналов о тупиках.
4.4. Информационные системы в локальных сетях
Локальная вычислительная сеть дает пользователю прежде всего возможность более эффективной организации групповых работ и совместного использования аппаратных ресурсов: принтеров, факсов, модемов, сканеров, дисков и т. д., а также програм мно-инф< >рмационных ресурсов, в том числе баз данных. Рассмотрим основные схемы организации работы с данными в ЛВС.
Спектр возможных схем пост роения информационной системы в Л ВС существенно зависит от возможностей используемых СОС.
Основным сервисом современных Л ВС, независимо от типа учравлс ния в них (централизованные или одноранговые), является предоставление доступа одного компьютера (компьютера-клиента) к дискам, каталогам (папкам) и файлам другого компьютера (компьютера-сервера). Так, при обращении к внешнему файлу СОС сначала передает по сети файл (часть файла) в оперативную память компьютера, а по завершении работы с ним при необходимости возвращает обновленную версию. Кроме гого, полезной функцией является возможность запуска на компьютере программ, хранящихся на другом компьютере.
Эти возможное ги примерно в равной мере предоставляются сетевыми ОС такими, как Novell NetWare 3.x (4.x), Windows NT и Windows 93/98. Более слабые сетевые пакеты и утилиты могут предоставлять доступ к информации без автоматического запуска программ. В этом случае пользователь должен сначала скопировать щхлраммы и файлы с другого компьютера на свой, после чего запустить программу.
Как и на отдельном компьютере, в ЛВС пользователь может управлять БД с помощью средств некоторой СУБД или работая с приложением. В общем случае приложение может выполняться под управлением СУБД или ее ядра, либо быть независимым и выполня гься как автономная программа. Для удобства в дальнейшем под СУБД будем понимать любой из этих вариантов.
В локальной сети персональных ЭВМ выделяют следующие три варианта создания информационной системы:
типа файл-сервер;
типа клиент-сервер;
основанные ча техн< шогии интранет;
Информационные системы типа файл-сервер можно строить двумя способами:
с использованием «< сетевых СУБД, предназначенных для применения на отдельной машине;
с использованием сетевых СУБД, разраба!ываемых для применения в ЛВС.
Под сетевой СУБД здесь понимается система с произвольной моделью данных (не обязательно сетевой), ориентированная на использование в сети.
Программы несетевой СУБД и используемые ею данные могут храниться на компьютере-сервере (КС) и на компьютере-клиенте (КК).
Запуск и функционирование несетевой СУБД, хранящейся на КК и работающей с локальными данными, не отличается от обычного р< жима работы на отдельной ПЭВМ. Если используемые данные хранятся на КС, файловая система сетевой ОС «незаметно» для СУБД выполняет подгрузку нужного фай па о удаленного компьютера. Заметим, чт« > не каждая несетевая СУБД без проблем работает в среде любой сетевой ОС.
Если несетевая СУБД используете несколькими пользователями сети, то ее npoi раммы, а также БД или ее часть в цепях экономии дисковой памяти эффективнее хранить на КС. Хранимую на КС БД будем называть центральной БД (ЦБД), а хранимую на КК БД - локальной БД (ЛБД). При запуске СУБД в таком варианте на каждый КК обычно пересылается полная копия основной програм иы СУБД и один или несколько фай лов ЦБД (рис. 4.9). После завершения работы фай ш ЦБД должны пересылаться с КК обпатно на КС для согласования данных.
СущестР"нным неоостатком такого варианта применения несетевых СУБД является возможность нарушения целостное ги данных при одновременной работе с одной БД нескольких пользовате. гей. Поскольку каж *ая копия СУБД функционирует «не зная» о работе других копий СУБД, то нт^аких мер по исключению возможных конфликтов не принимается При этом элемеь гарные операции чтения-записи одних и тех же файлов, как правило, контролирует сетевая ОС.
выполнение
—копирование
данных
—копирование
программ
—связь по управлению
Рис. 4.9. Система типа файл-сервер с несетевой СУБД
В качестве примеров несетевых СУБД можно назвать первые версии системы dBase III Plus, dBase IY и FoxBase.
Сетевые СУЬД не имеют указанного недостатка, так как в чих предусматривается «контроль соперничества» (concurrency control) Средства контроля по- .воляют осушеств. гять координацию юсгупа к данным, например, введением блокировок к файлам, записям и даже отдельным полям записей (рис, 4.10).
В сетевых СУБД с коллективным использованием файлов БД по-прежнему вся обработка информации производится на КК, а функции КС сводятся к предо- с давлению большой дисковой памяти. Такой подход нельтя считать лфф^ктивным, так как для обеспечения приемлемой скорости процесса обработки информации КК должен обладать высоким быстродействием и имегь большую емкост ь опера тивной памят и. Кроме тою, пересылка копий файлов БД и комац [ управления блокировками по линиям связи существенно увеличит лет нагрузку на подсистему передачи данных, что снижает общую производите чьность сети.
Примерами сетевых СУБД являются: FoxPro 2.5 для Windows, dBase IY, Paradox ,3.5 для DOS.
Информационные систсмы типа клиент-сервер отличаются от систем типа файл-сервер прежде всею тем, что программы СУБД функционально раз гелены на две части, называемые сервером и клиентом. Между клиентской и серверной частями системы возможны различные варианты распределения функций (подраздел 4.2).
КС
ЦБД
СУБД
\
\
/
\
/
\
/
\
Ф
\
р |
|
ЦБД s |
КК |
'\ |
V / |
|
\* |
ЛБД — |
— СУБД |
-V
/
\
/
кк
Jbj
\
ЛБД
- УБГ
выполнение
Рис. 4.10. Система типа файл-сервер с сетевой СУБД
Клиент, или фронте чъная програ чма, отвечает за интерф< йс с пользователем, для чего преобразует его запросы в команды запросов к серверной части, а при получении результатов выполняет обратное преобразование и отображение информации для пользователя.
В роли кли< нта выступает пользовате. (ы кая (ра :рабатываемая для решения конкре гной прикладной задачи npoi рамма) или гот» >вая программа, имеющая интерфейс с серверной программой. В качестве готовых клиентских программ Moiyi использоваться тек< товые процессоры, табличные процессоры и даже СУБД (например, Access, FoxPro и Paradox).
Сервер является основной программой, выполняющей функции управления и защиты данных в базе. В случаях, когда вызов функций сервера выпол няется на языке SQL, а именно так часто и происходит, его называют SQL- сервером.
В качес гве сервера может использоваться ядро профессиональной реля ционной СУБД (например, Informix 7.x и Sybase System 10) или некоторый SQL-сервер (например, Novell NetWare SQL и Microsoft SQL Server).
Структуру информационных систем типа клиент-сервер упрощенно можно представить как показано на рис. 4.11.
Основная часть обработки информации по формированию запросов, составлению отчетив. представлению данных в удобной для по. [ьзователя виде и т. д. выполняется на КК. Полные копии файлов БД из КС на КК и обратно (как в случае систем на базе сетевых СУБД) не пересылаются, п< (скольку для организации полноценною взаимодействия, как. правило, достаточно иметь на К К
UU |
КС |
контре |
)ль| сервер БД |
выполнение
\
\
\
\
/
/
■7^
/
\
/
\
КК
/
КК
_аписи
ЦБД
3ai
1иси
Miflu.
/
ЛБД
ЛБД
клиент
выполнение
Рис. 4.11. Информационная система типа клиент-сервер
необходимые r данный момент времени записи БД. Все .ото существенно снижает траффик в сети, ос габляет требования по ресурсам к КК, позволяет создавал ь более эффективные и надежные информационные системы.
В последнее время на компьютере-сервере, кроме собственно данных, хранят программы обработки данных и запросы. Э го обеспечивает увеличение скорости обработки данных (программа обработ ш либо запрос находится «рядом» с данными), а также эффективность хганения и администрирования про] рамм и запросов общего пользования в одном месте (на компьютере-сервере).
Хранимые на компьютере-сервере npoi раммы (процедуры) обработки данных называют хранимыми прощ дурами
Разновидностью хранимой процедуры является так называемый триггер Триггер (триггерная процедура) автоматически вызывается при возникновении определенных событии в БД. В качестве событий могут бы гь следующие: операции вставки, обновления и удаления отдельных записей, колонок и полей записей и другие. Примером триггера является профамма, запускающая процесс посылки сообщения по э. ie« гронной почте при достижении размера БД (количества записей) предельного значения
В Б/1 сервера некоторых систем можно хранить и сами запросы, называемые хранимыми командами. Совокупность хранимых команд — это поименованная совокупность команд, получаемых в результате компиляции SQL- запроса. Хранимые команды выполняются значительно быстрее, чем соот ветствующчй SQL-запрос. Осноьная причина ускорения состоит в том, чго при выполнении хранимых команд не требуется синтаксический разбор
5 За к. 474
запросов. Дополнительное ускорение выполнения запросов может быть получено в тех случаях, когда сервер БД не просто сохраняет коды команд запросов, а производит оптимизацию сохраняемого кода.
С хранимыми процедурами и командами связано понятие курсора, отличающееся от привычного понятия курсора как указат< ля текущей позиции на экране монитора. В разных СУБД — это близкие, но несколько отличающиеся понятия. Наиболее широко это понятие трактуется в СУБД SQLBase. Здесь курсор может означать следующее:
идентификатор сеанса связи пользователя с СУБД;
идентификатор хоанимых команд и процедур;
идентификатор результирующего множества;
указатель текущей строки в результирующем множестве, обрабатываемом клиентским приложением.
Программы сервера (основные, хранимые процедуры и триггеры) могут быть выполнены как обычные программы (Windows 95/98), либо как специально загружаемые мода'ли сетевой ОС (NLM-модули в сети Novell) Программы клиента в общем с лучае хранятся на КС или на КК, или в обоих местах.
В настоящее время среди программных продуктов существует огромное количество универ^г льных (ь смысле пригодности работы с различными серверами БД) средств разработки систем типа клиент-сервер, к числу котопых относятся: Delphi (Borland), Power Builder (Powersoft), ERwin (LogicWorks), Visual Basic (Microsoft), CA-Visual Objects (Computer Associates), SQL Windows (C.upta) и другие. Кроме того, (уществуют средства разработки в мамках определенных СУБД (например, для Orade 7 — Designer/2000). Все подобные средства, как правило, относятся к CASE-системам (раздел 7).
При построении информационных систем типа клиент-сервер возникает проблема доступа со стороны СУБД или приложений, разработанных в одной среде, к данным, порожденным другой СУБД. В среде Windows эла проблема решается с помощью стандартного интерфейса ODBC (Open Database Connectivity - совместимое] ьоткрыт ыхбазданш ix) фирмы Microsoft Основное его назначение заключаелся в обеспечении унифицированного юетупа к локальным и удаленным базам данных различных производителей.
Схема доступа приложений к базам данных с помощью ODBC показана на рис. 4.12. Доступ приложение к данным происходит путем вызова на языке SQL стандартных функций интерфейса ODBC. На компьютере-клиенте при этом долж- н; функционировать операционная система MS Windows <; интерфейсов < )DBC.
Взаимодействие приложения с данными производится с помощью менеджера (диспетчера) драйверов, который подключает необходимый драйвер в соответствии с фор! [атом данных СУБД. Драйвер СУБД, используя сетевые средства, как правило, коммуникапионные модули конкретной СУБД, передает SQL-операторы серверу СУБД. Результаты выполнения запросов на сервере передаются обратно в приложение.
Узел
В
Гвд
MS
Windows
Драйверы |
|
|
|
|
|
|
Приложение
Менеджер
СУБД
(сервер)
ODBC_
Сетевое ПО
Рис. 4.12. Схема доступа к БД с помощью ODBC
Рассмотренные схемы функционирования СУБД и внешних приложений касаю' ся наиболее типичных вариантов их построения.