Организация удаленного доступа к распределенным базам данных
Основные понятия теории реляционных баз данных. Технология и модели "клиент-сервер". Применение CASE-средств для информационного моделирования в системах обработки данных. Использование слоя RPC для распределенной обработки данных на платформе Windows NT.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 19.06.2011 |
| Размер файла | 462,9 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Особенность технологии распределенных БД - синхронное завершение транзакций одновременно на нескольких узлах распределенной системы, то есть синхронная фиксация изменений в распределенной БД. Недостаток технологии STAR - жесткие требования к производительности и надежности каналов связи. Если БД распределена по нескольким территориально удаленным узлам, объединенным медленными и ненадежными каналами связи, а число одновременно работающих пользователей составляет десятки и выше, то вероятность того, что распределенная транзакция будет зафиксирована в обозримом временном интервале, становится чрезвычайно малой. В таких условиях обработка распределенных данных практически невозможна.
Реальной альтернативой технологии STAR является технология тиражирования данных, не требующая синхронной фиксации изменений. В действительности далеко не во всех задачах требуется обеспечение идентичности БД на различных узлах в любое время. Достаточно поддерживать тождественность данных лишь в определенные критичные моменты времени. Следовательно, можно накапливать изменения в данных в виде транзакций в одном узле и периодически копировать эти изменения на другие узлы.
Преимущества технологии тиражирования данных:
Данные всегда расположены там, где они обрабатываются - следовательно, скорость доступа к ним существенно увеличивается.
Передача только операций, изменяющих данные (а не всех операций доступа к удаленным данным, как в технологии STAR), и к тому же в асинхронном режиме позволяет значительно уменьшить трафик.
Со стороны исходной БД для принимающих БД репликатор выступает как процесс, инициированный одним пользователем, в то время как в физически распределенной среде с каждым локальным сервером работают все пользователи распределенной системы, конкурирующие за ресурсы друг с другом.
Никакой продолжительный сбой связи не в состоянии нарушить передачу изменений. Дело в том, что тиражирование предполагает буферизацию потока изменений (транзакций); после восстановления связи передача возобновляется с той транзакции, на которой тиражирование было прервано.
Технология тиражирования данных имеет и недостатки, вытекающие из ее специфики. Например, невозможно полностью исключить конфликты между двумя версиями одной и той же записи. Они могут возникнуть, когда вследствие асинхронности передачи данных два пользователя на разных узлах исправят одну и ту же запись в тот момент, пока изменения в данных из первой базы данных еще не были перенесены во вторую. Следовательно, при проектировании распределенной среды с использованием технологии тиражирования данных необходимо предусмотреть конфликтные ситуации и запрограммировать репликатор на какой-либо вариант их разрешения.
1.4 Взаимодействие с PC-ориентированными СУБД
Первоначально профессиональные СУБД создавались для мощных высокопроизводительных платформ - IBM, DEC, Helwett-Packard, Sun. Но затем, учитывая все возрастающую популярность и широкое распространение персональных компьютеров, разработчики приступили к переносу (портированию) СУБД в операционные среды desktop-компьютеров (OS/2, NetWare, UnixWare, SCO UNIX).
В настоящее время большинство компаний - поставщиков СУБД развивает три направления своих систем. Во-первых, совершенствование СУБД для корпоративных информационных систем, которые характеризуются большим числом пользователей (от 100 и выше), базами данных огромного объема (их часто называют сверхбольшими базами данных - Very Large Data Base - VLDB), смешанным характером обработки данных (решение задач оперативной обработки транзакций и поддержки принятия решений) и т.д. Это - традиционная область mainframe-систем и приближающихся к ним по производительности RISC-компьютеров.
Другое направление - СУБД, поддерживающие так называемые рабочие группы. Это направление характеризуется относительно небольшим количеством пользователей с сохранением, тем не менее, всех "многопользовательских" качеств. Системы этого класса ориентированы преимущественно на "офисные" применения, не требующие специальных возможностей. Так, большинство современных многопользовательских СУБД имеют версии системы, функционирующие в сетевой операционной системе Novell NetWare. Ядро СУБД оформлено здесь как загружаемый модуль NetWare (NetWare Loadable Module - NLM), выполняющийся на файловом сервере. База данных также располагается на файловом сервере. SQL-запросы поступают к ядру СУБД от прикладных программ, которые запускаются на станциях сети - персональных компьютерах (отметим, что, несмотря на использование файлового сервера, здесь мы имеем дело с RDA-моделью).
Наконец, новый импульс в развитии получило направление настольных (desktop) версий СУБД, ориентированных на персональное использование - преимущественно в операционной среде MS Windows (системы этого класса получили неформальное определение "light" или "local").
Стремление компаний - поставщиков СУБД иметь фактически по три варианта своих систем, покрывающих весь спектр возможных применений, выглядит для пользователей чрезвычайно привлекательно. Действительно, для специалиста исключительно удобно иметь на своем портативном компьютере локальную базу данных (постоянно используемую во время командировок) в том же формате и обрабатываемую по тем же правилам, что и стационарную корпоративную базу фирмы, куда собранные данные могут быть без труда доставлены.
В последние годы (1987-94) в нашей стране было разработано множество программ, ориентированных на использование СУБД типа PARADOX, FoxPRO, dBASE IV, Clipper. При переходе на более мощную многопользовательскую СУБД у пользователей возникает естественное желание интегрировать уже существующие разработки в эту среду. Например, может возникнуть потребность хранить локальные данные на персональном компьютере и осуществлять к ним доступ с помощью системы FoxPRO, и одновременно иметь доступ к глобальной базе данных под управлением СУБД Oracle. Организация такого доступа, когда программа может одновременно работать и с персональной, и с многопользовательской СУБД, представляет собой сложную проблему по следующей причине.
Как известно, разработчики PC-ориентированных СУБД первоначально использовали свой собственный интерфейс к базам данных, никак не учитывая требования стандарта языка SQL. Лишь впоследствии они стали постепенно включать в свои системы возможности работы с базой данных при помощи SQL. В то же время для истинно многопользовательских СУБД интерфейс SQL - фактический стандарт. При этом возникла задача согласования интерфейсов СУБД различных классов. Она может решаться несколькими способами, но большинство из них имеют частный характер. Рассмотрим наиболее общее решение этой задачи.
Специалисты фирмы Microsoft разработали стандарт Open Database Connectivity (ODBC). Он представляет собой стандарт прикладного программного интерфейса прикладных (Application Programming Interface - API) и позволяет программам, работающим в среде Microsoft Windows, взаимодействовать (посредством операторов языка SQL) с различными СУБД, как персональными, так и многопользовательскими, функционирующими в различных операционных системах. Фактически, интерфейс ODBC универсальным образом отделяет чисто прикладную, содержательную сторону приложений (обработка электронных таблиц, статистический анализ, деловая графика) от собственно обработки и обмена данными с СУБД. Основная цель ODBC - сделать взаимодействие приложения и СУБД прозрачным, не зависящим от класса и особенностей используемой СУБД (мобильным с точки зрения используемой СУБД).
Отметим, что стандарт ODBC является неотъемлемой частью семейства стандартов, облегчающих написание и обеспечивающих вертикальную открытость приложений (WOSA - Windows Open Services Architecture - открытая архитектура сервисов системы Windows).
Интерфейс ODBC обеспечивает взаимную совместимость серверных и клиентских компонентов доступа к данным. Для реализации унифицированного доступа к различным СУБД было введено понятие драйвера ODBC (представляющего собой динамически загружаемую библиотеку).
ODBC-архитектура содержит четыре компонента:
приложение;
менеджер драйверов;
драйверы;
источники данных.
Роли среди них распределены следующим образом. Приложение вызывает функции ODBC для выполнения SQL-инструкций, получает и интерпретирует результаты; менеджер драйверов загружает ODBC-драйверы, когда этого требует приложение; ODBC-драйверы обрабатывают вызовы функций ODBC, передают операторы SQL СУБД и возвращают результат в приложение; источник данных (data source) - объект, скрывающий СУБД, детали сетевого интерфейса, расположение и полное имя базы данных и т.д.
Действия, выполняемые приложением, использующим интерфейс ODBC, сводятся к следующему. Для начала сеанса работы с базой данных приложение должно подключиться к источнику данных, ее скрывающему. Затем приложение обращается к базе данных, посылая SQL-инструкции, запрашивает результаты, отслеживает и реагирует на ошибки и т.д., то есть имеет место стандартная схема взаимодействия приложения и сервера БД, характерная для RDA-модели. Важно, что стандарт ODBC включает функции управления транзакциями (начало, фиксация, откат транзакции). Завершив сеанс работы, приложение должно отключиться от источника данных.
Слой доступа к данным, подобный ODBC использует в своих продуктах компания Borland. Эта система носит название Borland Database Engine (BDE) и имеет некоторые преимущества по сравнению с ODBC.
1.5 Обработка транзакций
Транзакция представляет собой последовательность операторов языка SQL, которая рассматривается как некоторое неделимое действие над базой данных, осмысленное с точки зрения пользователя. В то же время, это логическая единица работы системы. Транзакция реализует некоторую прикладную функцию, например, перевод денег с одного счета на другой в банковской системе.
Существуют различные модели транзакций, которые могут быть классифицированы на основании различных свойств, включающих структуру транзакции, параллельность внутри транзакции, продолжительность и т.д. Чаще всего имеют в виду традиционные транзакции, характеризуемые четырьмя классическими свойствами: атомарности, согласованности, изолированности, долговечности (прочности) - ACID (Atomicity, Consistency, Isolation, Durability). Иногда традиционные транзакции называют ACID-транзакциями. Упомянутые выше свойства означают следующее:
Свойство атомарности выражается в том, что транзакция должна быть выполнена в целом или не выполнена вовсе.
Свойство согласованности гарантирует, что по мере выполнения транзакций данные переходят из одного согласованного состояния в другое - транзакция не разрушает взаимной согласованности данных.
Свойство изолированности означает, что конкурирующие за доступ к базе данных транзакции физически обрабатываются последовательно, изолированно друг от друга, но для пользователей это выглядит так, как будто они выполняются параллельно.
Свойство долговечности трактуется следующим образом: если транзакция завершена успешно, то те изменения в данных, которые были ею произведены, не могут быть потеряны ни при каких обстоятельствах (даже в случае последующих ошибок).
Расширенные транзакции допускают формирование из ACID-транзакций иерархических структур. Если конкретная модель ослабляет некоторые из требований ACID, то речь идет об ослабленной транзакции.
Возможны два варианта завершения транзакции. Если все операторы выполнены успешно, и в процессе выполнения транзакции не произошло никаких сбоев программного или аппаратного обеспечения, транзакция фиксируется.
Фиксация транзакции - это действие, обеспечивающее запись на диск изменений в базе данных, которые были сделаны в процессе выполнения транзакции. До тех пор, пока транзакция не зафиксирована, возможно аннулирование этих изменений, восстановление базы данных в то состояние, в котором она была на момент начала транзакции. Фиксация означает, что все результаты выполнения транзакции становятся постоянными. Они станут видимыми другим транзакциям только после того, как текущая транзакция будет зафиксирована. До этого момента все данные, затрагиваемые транзакцией, будут "видны" пользователю в состоянии на начало текущей транзакции.
Если в процессе выполнения транзакции произошла ошибка, база данных должна быть возвращена в исходное состояние. Откат транзакции - это действие, обеспечивающее аннулирование всех изменений данных, которые были сделаны операторами SQL в теле текущей незавершенной транзакции.
Каждый оператор в транзакции выполняет свою часть работы, но для успешного завершения всей работы в целом требуется безусловное завершение их всех. Группирование операторов в транзакции сообщает СУБД, что вся эта группа должна быть выполнена как единое целое, причем такое выполнение должно поддерживаться автоматически.
В стандарте ANSI/ISO SQL определены модель транзакций и функции операторов COMMIT и ROLLBACK. Стандарт определяет, что транзакция начинается с первого SQL-оператора, инициируемого пользователем или содержащегося в программе. Все последующие SQL-операторы составляют тело транзакции. Транзакция завершается одним из четырех возможных способов:
оператор COMMIT означает успешное завершение транзакции; его использование делает постоянными изменения, внесенные в базу данных в рамках текущей транзакции;
оператор ROLLBACK прерывает транзакцию, отменяя изменения, сделанные в базе данных в рамках этой транзакции; новая транзакция начинается непосредственно после использования ROLLBACK;
успешное завершение программы, в которой была инициирована текущая транзакция, означает успешное завершение транзакции (как будто был использован оператор COMMIT);
ошибочное завершение программы прерывает транзакцию (как будто был использован оператор ROLLBACK).
Откат и фиксация транзакций становятся возможными благодаря журналу транзакций. Он используется следующим образом.
Известно, что все операции над реляционной базой данных - это операции над строками таблиц. Следовательно, для обеспечения отката таблиц к предыдущим состояниям достаточно хранить не состояния всей таблицы, а лишь те ее строки, которые подверглись изменениям.
При выполнении любого оператора SQL, который модифицирует базу данных, СУБД автоматически заносит очередную запись в журнал транзакций. Запись состоит из двух компонентов: первый - это состояние строки до внесения изменений, второй - ее же состояние после внесения изменений. Только после занесения записи в журнал транзакций (идеология «write ahead log»), СУБД действительно модифицирует базу данных. Если после данного оператора SQL был выполнен оператор COMMIT, то в журнале транзакций делается отметка о завершении текущей транзакции. Если же после оператора SQL следовал оператор ROLLBACK, то СУБД просматривает журнал транзакций и отыскивает записи, отражающие состояние измененных строк до модификации. Используя их, СУБД восстанавливает те строки в таблицах базы данных, которые были модифицированы текущей транзакцией - таким образом аннулируются все изменения в базе данных.
Важные проблемы многопользовательских СУБД связаны с организацией с помощью механизма транзакций одновременного доступа множества пользователей к одним и тем же данным. Они кратко могут быть сформулированы как потеря изменений, незафиксированные изменения и ряд других, более сложных проблем.
Потеря изменений происходит в ситуации, когда две или несколько программ читают одни и те же данные, вносят в них какие-либо изменения и затем пытаются одновременно записать результат по прежнему месту. Разумеется, в базе данных могут быть сохранены изменения, выполненные только одной программой - другие изменения будут потеряны.
Проблема незафиксированных изменений возникает в случае, когда в процессе выполнения транзакции одной программой в данные были внесены изменения, которые тут же прочитала другая программа, однако затем в первой программе транзакция была прервана оператором ROLLBACK. Получается, что вторая программа прочитала неверные, незафиксированные данные.
Для устранения подобных проблем применяются следующие правила:
В процессе выполнения транзакции пользователь (или программа) "видит" только согласованные состояния базы данных. Пользователь (или программа) никогда не может получить доступ к незафиксированным изменениям в данных, достигнутым в результате действий другого пользователя (программы).
Если две транзакции, A и B, выполняются параллельно, то СУБД полагает, что результат будет такой же, как если бы:
транзакция A выполнялась первой, а за ней была выполнена транзакция B;
транзакция B выполнялась первой, а за ней была выполнена транзакция A.
Это так называемая сериализация транзакций. Фактически она гарантирует, что каждый пользователь (программа), обращающаяся к базе данных, работает с ней так, как будто не существует других пользователей (программ), одновременно с ним обращающихся к тем же данным. Для практической реализации этой дисциплины большинство коммерческих СУБД используют механизм блокировок.
Транзакции могут попасть в тупиковую ситуацию, состояние неразрешимой взаимоблокировки. Для её предотвращения СУБД периодически проверяет блокировки, установленные активными транзакциями. Если СУБД обнаруживает взаимоблокировки, она выбирает одну из транзакций, вызвавшую ситуацию взаимоблокировки, и прерывает ее. Это освобождает данные для внесения изменений конкурирующей транзакцией, разрешая тупиковую ситуацию. Программа, которая инициировала прерванную транзакцию, получает сообщение об ошибке, информирующее ее о причине прерывания (имела место тупиковая ситуация). Избежать их может и правильная стратегия внесения изменений в базу данных. Одним из наиболее простых и эффективных правил может быть следующее: все программы, которые обновляют одни и те же таблицы, должны, по мере возможности, делать это в одинаковой последовательности.
В современных СУБД предусмотрен так называемый протокол двухфазовой (или двухфазной) фиксации транзакций (two-phase commit). Фаза 1 начинается, когда при обработке транзакции встретился оператор COMMIT. Сервер распределенной БД (или компонент СУБД, отвечающий за обработку распределенных транзакций) направляет уведомление "подготовиться к фиксации" всем серверам локальных БД, выполняющим распределенную транзакцию. Если все серверы приготовились к фиксации (то есть откликнулись на уведомление и отклик был получен), сервер распределенной БД принимает решение о фиксации. Серверы локальных БД остаются в состоянии готовности и ожидают от него команды "зафиксировать". Если хотя бы один из серверов не откликнулся на уведомление в силу каких-либо причин, будь то аппаратная или программная ошибка, то сервер распределенной БД откатывает локальные транзакции на всех узлах, включая даже те, которые подготовились к фиксации и оповестили его об этом.
Фаза 2 - сервер распределенной БД направляет команду "зафиксировать" всем узлам, затронутым транзакцией, и гарантирует, что транзакции на них будут зафиксированы. Если связь с локальной базой данных потеряна в интервал времени между моментом, когда сервер распределенной БД принимает решение о фиксации транзакции и моментом, когда сервер локальной БД подчиняется его команде, то сервер распределенной БД продолжает попытки завершить транзакцию, пока связь не будет восстановлена.
1.6 Средства защиты данных в СУБД
Существенным аспектом современных СУБД является защита данных. В самом общем виде требования к безопасности реляционных СУБД формулируются так:
данные в любой таблице должны быть доступны не всем пользователям, а лишь некоторым из них
некоторым пользователям должно быть разрешено обновлять данные в таблицах, в то время как для других допускается лишь выбор данных из этих же таблиц
для некоторых таблиц необходимо обеспечить выборочный доступ к ее столбцам
некоторым пользователям должен быть запрещен непосредственный (через запросы) доступ к таблицам, но разрешен доступ к этим же таблицам в диалоге с прикладной программой.
Схема доступа к данным во всех реляционных СУБД выглядит примерно одинаково и базируется на трех принципах:
Пользователи СУБД рассматриваются как основные действующие лица, желающие получить доступ к данным. СУБД от имени конкретного пользователя выполняет операции над базой данных, то есть добавляет строки в таблицы (INSERT), удаляет строки (DELETE), обновляет данные в строках таблицы (UPDATE). Она делает это в зависимости от того, обладает ли конкретный пользователь правами на выполнение конкретных операций над конкретным объектом базы данных.
Объекты доступа - это элементы базы данных, доступом к которым можно управлять (разрешать доступ или защищать от доступа). Обычно объектами доступа являются таблицы, однако ими могут быть и другие объекты базы данных - формы, отчеты, прикладные программы и т.д. Конкретный пользователь обладает конкретными правами доступа к конкретному объекту.
Привилегии (priveleges) - это операции, которые разрешено выполнять пользователю над конкретными объектами.
Таким образом, в СУБД авторизация доступа осуществляется с помощью привилегий. Установление и контроль привилегий - задача администратора базы данных.
Привилегии устанавливаются и отменяются специальными операторами языка SQL - GRANT (ПЕРЕДАТЬ) и REVOKE (ОТОБРАТЬ). Оператор GRANT указывает конкретного пользователя, который получает конкретные привилегии доступа к указанной таблице.
Конкретный пользователь СУБД опознается по уникальному идентификатору (user-id). Любое действие над базой данных, любой оператор языка SQL выполняется не анонимно, но от имени конкретного пользователя. Идентификатор пользователя определяет набор доступных объектов базы данных для конкретного физического лица или группы лиц. Однако он ничего не сообщает о механизме его связи с конкретным оператором SQL. Для этого в большинстве СУБД используется сеанс работы с базой данных. Для запуска на компьютере-клиенте программы переднего плана (например, интерактивного SQL) пользователь должен сообщить СУБД свой идентификатор и пароль. Все операции над базой данных, которые будут выполнены после этого, СУБД свяжет с конкретным пользователем, который запустил программу.
Некоторые СУБД (Oracle, Sybase, InterBase) используют собственную систему паролей, в других (Ingres, Informix, MS SQL Server) применяется идентификатор пользователя и его пароль из операционной системы.
Для облегчения процесса администрирования большого количества пользователей их объединяют в группы. Традиционно применяются два способа определения групп пользователей:
Один и тот же идентификатор используется для доступа к базе данных целой группы физических лиц. Это упрощает задачу администратора базы данных, так как достаточно один раз установить привилегии для этого "обобщенного" пользователя. Однако такой способ в основном предполагает разрешение на просмотр, быть может, на включение, но ни в коем случае - на удаление и обновление. Как только идентификатор (и пароль) становится известен большому числу людей, возникает опасность несанкционированного доступа к данным посторонних лиц.
Конкретному физическому лицу присваивается уникальный идентификатор. В этом случае администратор базы данных должен позаботиться о том, чтобы каждый пользователь получил собственные привилегии. Если количество пользователей базы данных возрастает, то администратору становится все труднее контролировать привилегии. В организации, насчитывающей свыше 100 пользователей, решение этой задачи потребует от него массу внимания.
Поддержка, помимо идентификатора пользователя, еще и идентификатора группы пользователей. Каждый пользователь, кроме собственного идентификатора, имеет также идентификатор группы, к которой он принадлежит. Чаще всего группа пользователей соответствует структурному подразделению организации, например, отделу. Привилегии устанавливаются не только для отдельных пользователей, но и для их групп.
Одна из проблем защиты данных возникает по той причине, что с базой данных работают как прикладные программы, так и пользователи, которые их запускают. Часто необходимость запуска некоторых прикладных программ пользователями, которые обладают различными правами доступа к данным, приводит к нарушению схемы безопасности.
Одно из решений проблемы заключается в том, чтобы прикладной программе также были приданы некоторые привилегии доступа к объектам базы данных. В этом случае пользователь, не обладающий специальными привилегиями доступа к некоторым объектам базы данных, может запустить прикладную программу, которая имеет такие привилегии.
В СУБД Ingres и Oracle это решение обеспечивается механизмом ролей (role). Роль представляет собой именованный объект, хранящийся в базе данных. Роль связывается с конкретной прикладной программой для придания последней привилегий доступа к базам данных, таблицам, представлениям и процедурам базы данных. Роль создается и удаляется администратором базы данных, ей может быть придан определенный пароль. Как только роль создана, ей можно предоставить привилегии доступа к объектам базы данных.
Современные информационные системы обеспечивают также другую схему безопасности - обязательный или принудительный контроль доступа (mandatory access control). Он основан на отказе от понятия владельца данных и опирается на так называемые метки безопасности (security labels), которые присваиваются данным при их создании. Каждая из меток соответствует некоторому уровню безопасности. Метки служат для классификации данных по уровням.
Так как данные расклассифицированы по уровням безопасности метками, конкретный пользователь получает ограниченный доступ к данным. Он может оперировать только с данными, расположенными на том уровне секретности, который соответствует его статусу. При этом он не является владельцем данных.
Эта схема безопасности опирается на механизм, позволяющий связать метки безопасности с каждой строкой любой таблицы в базе данных. Любой пользователь может потребовать в своем запросе отобразить любую таблицу из базы данных, однако увидит он только те строки, у которых метки безопасности не превышают уровень его компетенции.
Это означает, например, что строки таблицы, отмеченные как строки уровня максимальной безопасности, может увидеть только тот пользователь, у которого уровень безопасности - наивысший. Пользователи определенного уровня секретности могут видеть строки таблицы, отмеченные для их уровня безопасности, равно как и для всех уровней ниже данного. СУБД проверяет уровень безопасности пользователя и, в ответ на его запрос, возвращает только те строки таблицы, которые удовлетворяют запросу и соответствуют этому уровню.
По оценкам экспертов, концепция многоуровневой безопасности в ближайшие годы будет использована в большинстве коммерческих СУБД.
1.7 Применение CASE-средств для информационного моделирования в системах обработки данных
В условиях рынка все большее число компаний осознают преимущества использования информационных систем (ИС). Чтобы получить выгоду от использования информационной системы, ее следует создавать в короткие сроки и с уменьшенными затратами. Кроме того, информационная система должна быть легко сопровождаемой и управляемой.
Создание информационной системы предприятия - сложный и многоступенчатый процесс, который содержит фазу информационного моделирования. Информационная модель - это спецификация структуры данных и бизнес правил (правил предметной области). Для построения информационной модели предприятия используют так называемые CASE-средства.
Computer Aided Software Engineering (CASE) - это технология автоматизированного проектирования информационных систем, позволяющая значительно ускорить процесс их разработки, сократить затраты труда, а также повысить качество проектирования.
Под этим следует понимать совокупность методов и средств, применяемых в программной инженерии.
Основное отличие методов программной инженерии от непосредственного программирования, во-первых, то, что программная инженерия отделяет анализ и проектирование от программирования (кодирования) как такового. Во-вторых, программная инженерия выделяет в общем ходе разработки различные типы деятельности, выполняемые на различных фазах жизненного цикла.
Стандартный подход выделяет в жизненном цикле программной разработки несколько этапов:
анализ;
проектирование;
программирование;
тестирование;
сопровождение.
Первоначально считалось, что эти этапы проходят последовательно. В настоящее время принята модель так называемой быстрой прототипизации, в которой возвраты к началу основной последовательности происходят регулярно, с каждым циклом проектирования. Другими словами требуется одновременное выполнение всех задач всех фаз жизненного цикла, что не отменяет разделение действий в соответствии с фазами процесса проектирования.
Такое возможно только с использованием CASE-средств.
На этапах анализа и проектирования принимаются решения, которые оказывают решающее влияние на конечный продукт. Поэтому обычно CASE-средства применяют прежде всего на этих этапах.
Основной частью этапа проектирования является построение информационной модели объекта. При разработке прикладной системы по схеме “сверху - вниз”, информационная модель постепенно дополняется и детализируется.
На завершающий стадии этапа проектирования на основе информационной модели выполняется генерация объектов БД: таблиц, индексов, ключей последовательностей и т.д.
2. Реализация распределенной базы данных с удаленным доступом
В качестве примера реализации распределенной базы данных рассмотрим информационную систему для автоматизации расчетов с абонентами АО «Связьинформ» РМ.
В данной организации возникает задача учета финансовых поступлений за оказанные услуги связи. Сейчас для ее выполнения используется программный комплекс «Парус», который реализует часть необходимых функций. В последнее время возникла задача повременной тарификации и учета проведенных телефонных разговоров, что приводит к резкому увеличению объемов данных, циркулирующих в системе. Кроме того, для выработки политики тарификации услуг связи необходимо анализировать объем и структуру начислений, что требует постоянного хранения данных об оказанных услугах. С увеличением потока информации необходимо увеличить число операторских мест для занесения данных, следовательно система должна хорошо работать в многопользовательской среде. Программа «Парус» построена по идеологии настольных систем и поэтому её перенос в сетевую среду возможен только по архитектуре файл-сервера. Такой подход отличается плохой масштабируемостью и делает практически невозможной работу удаленных пользователей, Существующая система не может обрабатывать накапливаемый объем данных, поэтому возникает необходимость создания новой системы обработки информации, построенной по идеологии клиент-сервер.
Основные требования к системе таковы:
система автоматизации расчетов с абонентами должна обрабатывать данные по имеющимся клиентам;
система должна учитывать начисления по оказанным услугам;
система должна учитывать оплату, поступившую с клиента за оказанные услуги;
система должна иметь механизм регистрации изменений и возможность отката к одному из предыдущих состояний;
система должна обеспечивать возможность оперативного доступа к информации;
система должна иметь развитые механизмы обеспечения информационной безопасности (защита от несанкционированного доступа, избыточность хранения информации).
2.1 Анализ существующей системы
Для определения потребностей в построении системы расчета с абонентами и определения её структуры проведем анализ уже существующей схемы обмена данными.
Схема функционирования организации в первом приближении такова:
АО «Связьинформ» оказывает своим клиентам услуги в области связи.
Клиенты оплачивают оказанные услуги.
Внутренняя структура предприятия в самом общем виде может быть представлена следующим образом:
Имеется центральное отделение (управление связи), которое осуществляет контроль за деятельностью всего предприятия.
В каждом районе Республики Мордовия функционируют районные узлы связи (РУС) или эксплуатационно-технические узлы связи (ЭТУС), которые напрямую подчиняются управлению связи.
Существуют филиалы АО «Связьинформ», такие как ГТС, МТС, СТС и т.д.
Каждое из подразделений направляет в управлений связи ежемесячные отчеты.
Существующая система обмена информацией и её хранения такова:
Расчет за услуги связи каждый клиент проводит с РУС или ЭТУС по месту установки телефона.
В каждом из РУС или ЭТУС установлен персональный компьютер, на котором функционирует программный комплекс «Парус». В конце каждого месяца проводится расчет за услуги связи, в соответствие с которым выставляются счета клиентам.
Отчеты по проведенным расчетам пересылаются по электронной почте в управление связи.
Недостатки этой схемы проявляются в отсутствии оперативного доступа к информации по предоставленным услугам и поступившим средствам, низкой нагрузочной способности системы, невозможности анализа данных за достаточно длительный промежуток времени.
2.2 Новая схема обмена информацией
Учитывая перечисленные недостатки возникла необходимость организации единого информационного пространства для решения поставленных задач. Суть решения в следующем:
Провести установку в каждом из РУС или ЭТУС серверов для обработки и хранения данных по отдельно взятому району.
В управлении связи установить сервер, который будет хранить данные расчетов с абонентами по всей республике Мордовия.
Наладить каналы связи между районными узлами и управлением.
Построить распределенную базу данных по расчетам за услуги связи по всей Мордовии.
Разместить полученную базу на районных серверах с репликацией данных на сервер управления связи.
Для тех районов, установка в которых выделенных серверов экономически нецелесообразна, обеспечить удаленный доступ к базам данных других районов.
Рис. 2.1 - Идеология информационной системы расчетов с абонентами
Данная схема обладает следующими достоинствами по сравнению с предыдущей:
За счет использования выделенных серверов резко возрастает нагрузочная способность системы.
Из-за использования технологии клиент-сервер снижается трафик в каналах связи, что позволяет получить оперативный доступ к информации, находящейся на удаленном сервере.
Появляется возможность централизованного администрирования полученной системы.
Возможно гибкое распределение прав пользователей на доступ к данным.
За счет реализации принципа избыточности при хранении данных повышается надежность хранения. (В любой момент времени в системе существует две копии данных: одна на сервере управления связи, другая распределена между районными серверами).
Возможно практически неограниченное масштабирование системы.
2.3 Выбор операционной системы
В данное время на рынке операционных систем широко представлены несколько продуктов:
UNIX-системы
Системы семейства Novell NetWare
Системы на основе Windows NT
К достоинствам систем UNIX (Solaris, AIX, Linux, BSD UNIX, UNIX System V) относится вытесняющая многозадачность, стабильность, высокая производительность, поддержка мультипроцессорных систем и систем с массовым параллелизмом. Эти системы представлены на рынке очень давно, что позволяет говорить об их надежности. К их недостаткам относится высокая стоимость программного и аппаратного обеспечения (большинство систем функционируют на RISC платформах). Кроме того, системы на базе UNIX сложны в администрировании и слабо стандартизованы, что затрудняет построение на их основе интегрированных решений.
Системы на основе Novell NetWare построены на основе корпоративной многозадачности, что делает практически невозможным их применение в качестве серверов приложений и баз данных. Длительная транзакция со стороны одного из клиентов сервера Novell NetWare приводит к невозможности доступа других клиентов к ресурсам сервера. Все процессы на сервере выполняются в нулевом кольце защиты процессора, таким образом ошибка в одном из них с большой вероятностью приводит к краху всей системы вплоть до потери файлов. Это приводит к невозможности выполнения пользовательских процессов на сервере. В настоящее время системы на базе Novell NetWare используются в большинстве случаев как файл-серверы.
Системы Windows NT появились на рынке достаточно давно, но широкое распространение они получили только с момента выхода версии 3.5.
В них реализована вытесняющая многозадачность, что делает эти системы хорошей основой для серверов приложений. Системы на базе Windows NT отвечают требованиям уровня безопасности C2 Министерства обороны США, что позволяет их использовать в самых ответственных приложениях. Windows NT функционирует как на платформе Intel, так и на RISC платформах, что дает возможность легко наращивать мощность системы по мере увеличения потока данных. Так как в качестве клиентских мест в системе будут использоваться компьютеры под управлений Windows 95/Windows 3.11, использование Windows NT в качестве сервера позволит создать целостную информационную систему. Следует учитывать также и наличие достаточно большого количества программистов, имеющих опыт работы с Windows 95, которые могут после дополнительной подготовки разрабатывать серверные части приложений под управлением Windows NT.
Учитывая тенденции развития рынка операционных систем в качестве платформы для реализации информационной системы выбрана Windows NT 4.0.
2.4 Выбор сервера баз данных
Основные требования, предъявляемые к серверу баз данных таковы:
Хорошая масштабируемость
Высокая производительность
Легкость в администрировании
Наличие мощных инструментов для разработки приложений
Низкая цена рабочего места
В настоящее время на рынке серверов баз данных представлено множество систем. Среди них Oracle, Informix, Sybase, Open Ingres, IBM DB2, Borland InterBase, Microsoft SQL Server и др.
Одна из особенностей поставленной задачи - установка серверов баз данных в районах Республики Мордовия. При этом особую роль играет отсутствие в местах установки серверов квалифицированных администраторов, способных управлять базой данных. Таким образом, одним из основных требований к серверу баз данных наряду с высокой производительностью и хорошей масштабируемостью является простота администрирования. Кроме того, сервер должен поддерживать распределенные базы данных.
Исходя из сравнительных характеристик данных серверов баз данных в качестве платформы для реализации корпоративной информационной системы был выбран сервер Borland InterBase 4.0 для Windows NT.
Borland InterBase Workgroup Server - сервер реляционных баз данных, оптимизированный для реализации технологии upsizing (укрупнения) многопользовательских приложений.
Версия InterBase 4.0 - сервера, традиционно доступного на всех основных UNIX-платформах (IBM, Sun, HP), оптимизирована для использования на Novell NetWare и Windows NT и обладает рядом функций, обязательных для современного SQL-сервера баз данных. К таким функциям относятся наличие хранимых процедур, расширенная поддержка триггеров, декларативная ссылочная целостность и т.д. Эти функции соответствуют стандарту ANSI/ISO SQL92 или, где возможно, проекту SQL3.
Важной особенностью InterBase является поддержка технологии C/S Express. Это особенно полезно при использовании InterBase 4.0 в качестве upsizing средства, т.к. позволяет сохранить привычную навигационную нотацию файл-серверной модели при переходе к архитектуре C/S.
Возможность обеспечивать как навигационный, так и SQL доступ к данным, является уникальной и делает InterBase 4.0, привлекательным средством для построения информационных систем различного масштаба - от небольшой рабочей группы до целого предприятия.
Borland InterBase Workgroup Server обладает рядом свойств, позволяющих решать задачи оперативной обработки транзакций и обеспечивать режим поддержки принятия решений. Среди таких свойств важнейшими являются технология многоверсионности (Versioning Engine), поддержка распределенных баз данных и наличие нестандартных типов данных.
Технология многоверсионности ядра обеспечивает бесконфликтный доступ к данным за счет ведения нескольких поколений записей. Когда транзакция модифицирует запись, InterBase создает новую запись. Во многих случаях новая запись представляет собой компактную запись изменений. InterBase связывает все такие записи и образует многоверсионную запись. Когда транзакция стартует, ей доступна наиболее поздняя версия записи, созданная завершенной транзакцией.
Если в процессе работы длинной транзакции, такой как получение архивной копии базы данных, будут внесены изменения в базу данных, это не нарушит целостный вид архивной копии, так как эта транзакция имеет дело с предыдущей версией записи. Таким образом, транзакция по чтению никогда не конфликтует с транзакцией по записи.
Побочным эффектом такой архитектуры является повышенная готовность системы, т.к. в случае аппаратных сбоев осуществляется откат к предыдущему состоянию с отменой незавершенных транзакций и результата их работы по обновлению базы данных.
Предыдущие версии записей ведутся до тех пор, пока существует активная транзакция, начавшаяся до момента модификации данной версии. Версии записи, более старые, чем самая старая активная транзакция, удаляются из системы следующей транзакцией с освобождением занимаемых системных ресурсов.
Технология построения InterBase позволяет создавать распределенные базы данных и обеспечивает возможность для приложения-клиента открыть необходимое количество БД, что обеспечивается механизмом двухфазной фиксации транзакций (two-phase commit).
Помимо общепринятых типов данных, таких как алфавитно-цифровая информация, даты и т.д., InterBase обладает возможностью работы с неструктурированными данными, сохраняя их в виде объектов типа BLOB (Binary Large Objects - большие двоичные объекты). В виде BLOB может быть сохранена любая двоичная информация: изображения, оцифрованный звук, исполняемые модули программ. Особенностью реализации BLOB в InterBase является сегментированный доступ к ним, что позволяет увеличить производительность прикладных систем.
Другим нетрадиционным типом данных, допустимым в InterBase, является многомерный массив. В InterBase в качестве поля записи может быть сохранен массив произвольных данных (кроме BLOB) с размерностью от 1 до 16. Наличие такого типа данных позволяет эффективно строить приложения, работающие в финансовой, промышленной и научно-исследовательской области.
InterBase предлагает разработчику прикладных систем ряд возможностей по реализации активных функций ядра. Это позволяет перенести часть приложения с компьютера - клиента на сервер, что повышает производительность и облегчает сопровождение прикладных систем
Декларативная целостность обеспечивает непротиворечивость данных на сервере. В отличие от реализации целостности с помощью триггеров декларативная целостность проще в применении и отладке. Существуют четыре категории средств обеспечения декларативной целостности:
Unique and Primary Key (уникальный первичный ключ) - гарантирует уникальность значения ключевого поля записи;
Referential Integrity (ссылочная целостность) - гарантирует соответствие значения ключевого поля записи подчиненной таблицы значению ключевого поля в главной таблице;
Check Constraint (ограничение допустимости) - гарантирует, что правило допустимости, связанное с данным ограничением, истинно для каждой записи в таблице;
Domain (домен) - позволяет создать новые подтипы с описанием допустимых значений и значений по умолчанию.
Хранимые процедуры - хранимые процедуры InterBase соответствуют проекту ANSI/ISO SQL 3. В хранимых процедурах допустимы конструкции begin....end, if...then...else, while, for, when и т. д. Внутри хранимых процедур может быть предусмотрена обработка исключений. Исключения затем могут быть обработаны, используя оператор WHEN. Хранимые процедуры могут быть вложенными, а также рекурсивными, т.е. вызывать сами себя.
Триггеры - В InterBase возможно явное указание порядка выполнения триггеров, если триггерное условие выполняется для нескольких триггеров одновременно.
Сигнализаторы событий. InterBase полностью поддерживает механизм оповещения о событиях в базе данных.
PC-клиенты подключаются к InterBase 4.0 с помощью технологии интегрированного интерфейса к базам данных (Integrated Database Application Programming Interface - IDAPI) фирмы Borland, которая является общей технологией промежуточного уровня, используемой в таких программных продуктах Borland, как Paradox и dBASE. Сегодня IDAPI поддерживает связь c dBASE и Paradox через ориентированный на интерактивную работу интерфейс, а подключение к InterBase, Oracle и Sybase - через ориентированный на работу с наборами интерфейс SQL (Borland SQL Link).
Альтернативным способом доступа к данным InterBase может быть технология ODBC. В комплект поставки InterBase входит ODBC драйвер, а все IDAPI-приложения имеют возможность взаимодействовать с ODBC-совместимым источником данных.
С появлением InterBase 4.0 средства IDAPI поддерживают для InterBase 4.0 специальную технологию связи с базой данных, которая называется Express Link. Являясь частью технологии IDAPI фирмы Borland, Express Link, минуя собственные средства персонального приложения, обеспечивает через IDAPI прямую связь между персональными приложениями и сервером InterBase.
Подобные функциональные возможности требуют наличия двух компонентов: драйвера и сервера, который может отвечать на команды персонального приложения. С помощью InterBase 4.0 сервер базы данных поддерживает две модели взаимодействия с сервером. С использованием Express Link, InterBase 4.0 может функционировать, как подлинный сервер для клиентов Paradox и dBASE с непосредственной поддержкой в механизме базы данных таких средств, как перемещение по записям и их обновление. Через динамические и встроенные вызовы SQL InterBase 4.0 может также поддерживать операционную среду для традиционных SQL-приложений.
Таким образом, InterBase 4.0 поддерживает две интерфейсных операционных среды:
Технологию Express Link (использующую IDAPI) с поддержкой таких персональных инструментов, как dBASE, Paradox и другие продукты Windows на базе IDAPI.
SQL, позволяющую реализовать доступ на базе статических или динамических операторов SQL.
Основываясь на конкретных потребностях, приложение может свободно сочетать эти модели.
Для взаимодействия с сервером персональное приложение на PC, включая Paradox и dBASE, может вызывать администратор IDAPI. Сами функции IDAPI по характеру выполняемой ими работы подразделяются на функции перемещения и функции SQL. Вызовы SQL в IDAPI основаны на спецификации X-Open Call Level Interface, в то время как расширения вызовов персональных приложений IDAPI предназначены для реализации характерной технологии программирования персональных приложений. Для получения общей рабочей среды некоторые вызовы используются совместно как в режиме SQL, так и в режиме перемещения. Режим взаимодействия приложения с сервером InterBase 4.0 обычно определяется режимом текущего вызова IDAPI. Использование SQL или режима перемещения прозрачно для пользователя.
Для поддержки ориентированного на записи доступа обычно требуется выполнение на промежуточном уровне трансляции, преобразующей запросы персонального приложения в команды SQL. Например, чтобы открыть индексный курсор, транслирующий уровень строит оператор SQL с предложением Order By, соответствующим столбцам индекса, а затем выполняет его на сервере. Фильтрующие выражения завершаются предложением Where сгенерированного оператора SQL. Сервер реляционной базы данных эмулирует через SQL семантику данных работающего с упорядоченной информацией персонального приложения, что ведет к заметному снижению производительности.
Позволяя открывать курсоры для таблиц и индексов без использования операторов SQL, InterBase 4.0 с помощью многопользовательской среды клиент-сервер обеспечивает производительность, близкую к производительности локального персонального приложения. Это означает, что когда курсор открывается для таблицы, то записи возвращаются в естественном порядке, а когда он открывается для индекса, то они возвращаются в отсортированном порядке.
Важным аспектом дизайна InterBase 4.0 является прямая, осуществляемая на уровне механизма базы данных поддержка подобных операций перебора. Для более быстрой выборки записей из таблиц и индексов InterBase 4.0 использует специальные структуры данных, алгоритмы и протоколы. Для подготовки и выполнения таких операций операторы SQL не требуются, поэтому отпадает необходимость в промежуточных транслирующих модулях, а буферизация результирующего набора сводится с минимуму. Кроме того, к данным параллельно могут обращаться как пользователи Express Link, так и SQL.
Закладка - это метка записи относительно ее позиции среди других записей. Механизм InterBase 4.0 поддерживает закладки непосредственно на уровне сервера, позволяя использовать вызовы для установки, получения и сравнения закладок. Закладка действует в течение всего подключения к базе данных и допустима даже после закрытия исходного курсора и завершения первоначальной транзакции. Используя внутренние идентификаторы записи, InterBase 4.0 поддерживает быстрые операции с закладками.
Многие персональные приложения не используют понятия множественной транзакции и предполагают обычно, что каждая операция базы данных выполняется немедленно. Для поддержки такого представления InterBase 4.0 использует возможность автоматической фиксации, которая принудительно интерпретирует каждое обновление как полную транзакцию.
С этой целью в InterBase 4.0 поддерживается сохранение контекста курсора. Это позволяет поддерживать текущий курсор даже после завершения транзакции.
Когда сервер использует в качестве своего интерфейса исключительно SQL, он ограничен налагаемыми SQL правилами блокировок транзакций. В соответствии с правилами SQL пользователь может определить уровень выделения, но не может управлять блокировками (их установкой и отменой). Персональные приложения используют парадигмы явных и монопольных блокировок и в общем случае не применяют неявных блокировок. Более того, может потребоваться, чтобы запрашиваемые приложением блокировки сохранялись в течение транзакции, пока не будут явным образом отменены пользователем.
Для обеспечения потребностей пользователей персональных приложений PC, InterBase 4.0 поддерживает явные блокировки, но следует также и стандартной модели сервера, которая обеспечивает явные блокировки для традиционных пользователей SQL.
Подобные документы
Модели информационного процесса обработки данных. Классификация баз данных. Сеть архитектуры и технология клиент-сервер. Создание запросов к реляционным базам данных на SQL. Работа с электронными таблицами MS Excel: форматирование данных, вычисления.
контрольная работа [17,8 K], добавлен 17.01.2010Определение базы данных и банков данных. Компоненты банка данных. Основные требования к технологии интегрированного хранения и обработки данных. Система управления и модели организации доступа к базам данных. Разработка приложений и администрирование.
презентация [17,1 K], добавлен 19.08.2013Обработка распределенных данных и запросов. Многопотоковые и многосерверные архитектуры. Основные типы параллелелизма при обработке запросов. Структура компонентов поддержки удаленного доступа. Доступ к базам данных в двухзвенных моделях клиент-сервер.
презентация [123,1 K], добавлен 19.08.2013Определение понятия CASE-технологий. Использование комплексного инструментария ER/Studio для создания логической и физической модели данных, генерирования баз данных на платформе СУБД Access. Процедура добавления атрибутов и сущностей, создания связей.
контрольная работа [2,2 M], добавлен 21.12.2011Основные объекты СУБД Microsoft Access. Формирование запросов на выборку. Основные протоколы обмена в компьютерных сетях. Использование и применение архитектуры клиент-сервер или файл-сервер. Основы реляционных БД. Наиболее известные модели данных.
курсовая работа [1,3 M], добавлен 13.01.2014Основные понятия и классификация систем управления базами данных. Модели организации данных. Проектирование реляционных баз данных. Основные особенности создания и использования баз данных для информационного обеспечения управленческой деятельности.
курсовая работа [2,0 M], добавлен 20.01.2013Представление данных в памяти компьютера. Обобщенные структуры и модели данных. Методы доступа к информации. Физическая организация системы управления базами данных, структура сервера. Архитектура "клиент-сервер". Создание базы данных с помощью "Денвер".
курсовая работа [770,3 K], добавлен 17.11.2014Преимущества распределенных система обработки данных. Классификация интегрированных технологий. Модели реализации технологии "клиент-сервер". Мониторы обработки транзакций. Глобальные вычислительные и информационные сети. Виды доступа к глобальным сетям.
презентация [2,1 M], добавлен 20.11.2013Изучение особенностей информационного процесса обработки данных. Процессы, связанные с поиском, хранением, передачей, обработкой и использованием информации. Основные режимы обработки данных на ЭВМ. Организация обслуживания вычислительных задач.
реферат [130,9 K], добавлен 28.09.2014Проблема применения методов прогнозирования кадровой работы на основе использования компьютерных технологий. Концепция банка данных, сущность и функции. Отличие реляционных и объектно-ориентированных баз данных. Организация и технология обработки данных.
реферат [1,0 M], добавлен 23.09.2014
