- •Содержание
- •1. Общее представление об корпоративной информационной системе
- •2. Общая классификация архитектур информационных приложений
- •3. Средства и методологии проектирования, разработки и сопровождения файл-серверных приложений
- •4. Средства и методологии проектирования, разработки и сопровождения клиент-серверных приложений
- •5. Средства и методологии проектирования, разработки и сопровождения Intranet-приложений
- •6. Информационные приложения, основанные на использовании "складов данных" (DataWarehousing)
- •7. Глобально распределенные кис
- •Введение
- •1. Общее представление об информационной системе
- •1.1. Специфика информационных программных систем
- •1.2. Этапы развития кис
- •1.3. Задачи информационных систем
- •1.4. Проблемы построения кис
- •1.5. Требования к техническим средствам, поддерживающим кис
- •2. Общая классификация архитектур информационных приложений
- •2.1. Файл-серверные приложения
- •2.2. Клиент-серверные приложения
- •2.3. Intranet-приложения
- •2.4. Склады данных (DataWarehousing) и системы оперативной аналитической обработки данных
- •2.5. Интегрированные распределенные приложения
- •3. Средства и методологии проектирования, разработки и сопровождения файл-серверных приложений
- •3.1. Традиционные средства и методологии разработки
- •3.1.1. Системы программирования и библиотеки
- •3.1.2. Средства и методы разработки приложений на основе субд на персональных компьютерах
- •3.2. Новые средства разработки файл-серверных приложений
- •3.2.1. Общая характеристика современных средств
- •3.2.2. Примеры новых подходов
- •3.2.2.1. Пакет ms Access
- •3.2.2.2. Система Visual FoxPro
- •3.2.2.3. Среда программирования ca-Visual Objects
- •3.3. Перенос файл-серверных приложений в среду клиент-сервер
- •3.3.1. Библиотеки доступа к базам данных
- •3.3.2. Протокол odbc и его реализации
- •3.3.3. Укрупнение приложений (Upsigsing)
- •3.4. Рекомендации по использованию инструментальных средств разработки файл-серверных приложений
- •4. Средства и методологии проектирования, разработки и сопровождения клиент-серверных приложений
- •4.1. Базовые средства построения ис в архитектуре "клиент-сервер"
- •4.1.1. Вызовы удаленных процедур
- •4.1.1.1. Протокол rpc и его реализации
- •4.1.1.2. Протокол xdr
- •4.1.2. Стек протоколов tcp/ip как основа rpc
- •Семейство протоколов tcp/ip
- •4.2. Серверы баз данных как базовая системная поддержка информационной системы в архитектуре "клиент-сервер"
- •4.2.1. Понятие сервера баз данных
- •4.2.2. Базовая архитектура сервера баз данных
- •4.2.2.1. Непосредственное управление данными во внешней памяти
- •4.2.2.2. Управление буферами оперативной памяти
- •4.2.2.3. Управление транзакциями
- •4.2.2.4. Журнализация
- •4.2.2.5. Языки бд
- •4.2.3. Основные производители серверов баз данных и характеристика их продуктов
- •4.2.3.1. История и серверные продукты компании Oracle
- •4.2.3.2. История и серверные продукты компании Informix
- •4.2.3.3. Серверные продукты компании Sybase
- •4.2.3.4. Линия серверных продуктов ca-OpenIngres компании Computer Associates
- •4.2.3.5. Серверные продукты линии db2 компании ibm
- •5. Средства и методологии проектирования, разработки и сопровождения Intranet-приложений
- •5.1. Основные понятия Intranet
- •5.2. Языки и протоколы
- •5.2.1. Html
- •5.2.2. Http
- •5.2.2.1. Форма запроса клиента
- •5.2.2.2. Методы доступа
- •5.2.2.3. Ответ сервера
- •5.2.2.4. Защита сервера от несанкционированного доступа
- •5.3. Серверы Intranet
- •5.3.1.1. Типы информационных ресурсов
- •5.3.1.2. Протокол ftp
- •5.3.1.3. Сервер протокола - программа ftpd
- •5.3.2.1. Структура базы данных сервера www
- •5.3.3. Поисковые серверы
- •5.3.3.1. Архитектура современных информационно-поисковых систем World Wide Web
- •5.3.3.2. Информационные ресурсы и их представление в информационно-поисковой системе
- •5.4. Язык программирования Java
- •5.4.1. Мобильность Java
- •5.4.2. Безопасность, Java и Intranet
- •5.4.3. Миграция от средства программирования интерфейсов электронных устройств
- •5.5. Возможные архитектуры Intranet-приложений
- •5.5.1. Решения, ориентированные на клиентскую часть системы
- •5.5.2. Трехзвенные архитектуры (Web-ориентированные)
- •5.5.3. Решения, основанные на использовании языка Java
- •6. Информационные приложения, основанные на использовании "складов данных" (DataWarehousing)
- •6.1. Проблема интеграции данных
- •6.2. Подходы и имеющиеся решения
- •6.2.1. Компания ibm
- •6.2.2. Oracle
- •6.2.3. Hewlett Packard
- •6.2.4. Sybase
- •6.2.5. Informix Software
- •6.2.7. Sas Institute
- •6.2.8. Software ag
- •7. Глобально распределенные кис
- •7.1. Проблема "унаследованных систем" (Legacy Systems)
- •7.2. Объектный подход
- •7.3. Предложения omg и odmg
- •7.4. Промышленный стандарт corba
4.2.2.2. Управление буферами оперативной памяти
Серверы баз данных обычно работают с БД значительного размера; по крайней мере этот размер обычно существенно больше доступного объема оперативной памяти. Понятно, что если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти. Практически единственным способом реального увеличения этой скорости является буферизация данных в оперативной памяти. При этом, даже если операционная система производит общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для целей СУБД, которая располагает гораздо большей информацией о полезности буферизации той или иной части БД. Поэтому в развитых СУБД поддерживается собственный набор буферов оперативной памяти с собственной дисциплиной замены буферов.
Заметим, что существует отдельное направление СУБД, которое ориентировано на постоянное присутствие в оперативной памяти всей БД. Это направление основывается на предположении, что в будущем объем оперативной памяти компьютеров сможет быть настолько велик, что позволит не беспокоиться о буферизации. Пока эти работы находятся в стадии исследований.
4.2.2.3. Управление транзакциями
Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается в состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД. Если воспользоваться примером информационной системы с файлами СОТРУДНИКИ и ОТДЕЛЫ, то единственным способом не нарушить целостность БД при выполнении операции приема на работу нового сотрудника является объединение элементарных операций над файлами СОТРУДНИКИ и ОТДЕЛЫ в одну транзакцию. Таким образом, поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). Но понятие транзакции гораздо более важно в многопользовательских СУБД.
То свойство, что каждая транзакция начинается при целостном состоянии БД и оставляет это состояние целостным после своего завершения, делает очень удобным использование понятия транзакции как единицы активности пользователя по отношению к БД. При соответствующем управлении параллельно выполняющимися транзакциями со стороны СУБД каждый из пользователей может в принципе ощущать себя единственным пользователем СУБД (на самом деле, это несколько идеализированное представление, поскольку в некоторых случаях пользователи многопользовательских СУБД могут ощутить присутствие своих коллег).
С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации транзакций и сериального плана выполнения смеси транзакций. Под сериализаций параллельно выполняющихся транзакций понимается такой порядок планирования их работы, при котором суммарный эффект смеси транзакций эквивалентен эффекту их некоторого последовательного выполнения. Сериальный план выполнения смеси транзакций - это такой план, который приводит к сериализации транзакций. Понятно, что если удается добиться действительно сериального выполнения смеси транзакций, то для каждого пользователя, по инициативе которого образована транзакция, присутствие других транзакций будет незаметно (если не считать некоторого замедления работы по сравнению с однопользовательским режимом).
Существует несколько базовых алгоритмов сериализации транзакций. В централизованных СУБД наиболее распространены алгоритмы, основанные на синхронизационных захватах объектов БД. При использовании любого алгоритма сериализации возможны ситуации конфликтов между двумя или более транзакциями по доступу к объектам БД. В этом случае для поддержания сериализации необходимо выполнить откат (ликвидировать все изменения, произведенные в БД) одной или более транзакций. Это один из случаев, когда пользователь многопользовательской СУБД может реально (и достаточно неприятно) ощутить присутствие в системе транзакций других пользователей.