18c0693f

Корпоративные базы данных - статьи

IUWA: универсальная архитектура Informix для работы в Internet/Intranet

А. Гвоздев, Informix (тел.: 755-8700, )

Основные положения

Развитие WEB приложений.

Мощные и гибкие, "разумные" ( intelligent ) WEB приложения.

IUWA - Informix Universal Web Architecture.

Продукты, инициативы и партнеры Informix в решении
проблем работы в Internet/Intranet

Примеры реализованных проектов - это работающая технология.


1996 год часто называют "годом Internet". Вполне
может быть 1997 год будет годом утверждения и реального массового
использования Internet в бизнесе. Другими словами, в 1997 году
люди начнут разрабатывать, использовать и управлять Internet/Intranet
приложениями столь же активно и эффективно как делают это сейчас
с традиционными приложениями. При этом можно говорить о множестве
требований, которым должны удовлетворять эти web-приложения. Например:

  • Обеспечить максимально простой
    доступ ко всей существующей информации;
  • Обеспечить максимально возможное использование
    уже накопленных данных и разработанных приложений/алгоритмов;
  • Снизить стоимость доставки информации;
  • Позволить бизнес процессам быть максимально гибкими;
  • Обеспечить динамическую доставку конкретной информации,
    необходимой именно данному пользователю ( customizable information
    );
  • Обеспечить адекватную поддержку новым каналам
    сбыта ( прямые продажи через Internet, one-to-one маркетинг;
  • И многое другое...

    То что все эти приложения требуют активного использования
    баз данных ни у кого не вызывает сомнений. Существовавшие решения
    использования баз данных в web-приложениях показали следующие
    проблемы, требующие решения. Это:

  • Обеспечение хорошо масштабируемой
    web-инфраструктуры;
  • Решение проблем производительности;
  • Управление быстро растущим содержимым web-узла
    и самим web-узлом;
  • Предоставление возможности настройки на каждого
    индивидуального пользователя;
  • Поддержка постоянного развития web-приложения;
  • Поддержка максимальной безопасности;


    IUWA: универсальная архитектура Informix для работы в Internet/Intranet

    Рис. 1.

    IUWA: универсальная архитектура Informix для работы в Internet/Intranet

    Рис. 2.

    Ни одна из выше названных задач не может быть эффективно

    решена при использовании технологии web-узлов 1-го и 2-го поколения
    (см. рис.1).Проблема заключается в предоставлении технологии (
    и реальных продуктов, работающих в рамках этой технологии) обеспечивающей
    максимально гибкую интеграцию баз данных в web-ориентированные
    приложения. Такую технологию и предлагает Informix с помощью IUWA
    - универсальной архитектуры для работы в WEB (рис. 2 ).

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

  • хранение всей логики web-приложений
    и полного содержания web-узла в базе данных обеспечивает максимальную
    прозрачность модификации приложений
  • масштабируемость сервера БД обеспечивает адекватную
    возможность значительного роста "мощности" web-приложения и роста
    числа пользователей
  • возможности встроенной репликации БД серверов
    Informix позволяют легко и эффективно строить распределенные web-узлы;
  • поддержка парадигмы "push computing" - т.е. интересующая
    пользователя информация доставляется ему автоматически, в режиме
    "подписки", без необходимости постоянного "плавания по Internet
    в поисках необходимой информации

    Какие конкретно продукты и программы входят в IUWA?

  • В поставку любого сервера БД
    Informix бесплатно входит web-сервер от Netscape (Enterprise или
    FastTrack) и браузер Netscape Navigator Gold
  • INFORMIX-Web DataBlade Module
  • INFORMIX-Universal Web Connect
  • Стратегия Java Anywhere, включающая продукт INFORMIX-JWORKS,
    а также означающая предоставление Java API & JDBC и поддержку


    Java на уровне сервера БД
  • Программы "INFORMIX-Universal Web Connect partners"

    "Universal Web Solution Specialists"

    "Electronic commerce partners"

    Небольшие комментарии по некоторым позициям.

    INFORMIX-Web DataBlade Module обеспечивает генерацию
    HTML страниц " на лету" на основе содержимого базы данных; поддерживает
    работу с любым браузером и web-сервером; поддерживает стандарты
    CGI, ISAPI, NSAPI, SGML; имеет мощное средство разработки и контроля
    Application Page Builder c набором готовых шаблонов.

    INFORMIX-Universal Web Connect - единая платформа,
    обеспечивающая работу единожды написанного web-приложения c любым
    из серверов, от INFORMIX Workgroup Server до INFORMIX XPS и Universal
    Server. Архитектура и механизм работы INFORMIX-Universal Web Connect
    показаны на рисунках 3 и 4. Помимо функциональности предоставляемой
    INFORMIX Web DataBlade, данный продукт обеспечивает:

  • поддержку постоянных сессий
    web-пользователей c БД;
  • механизм поддержки транзакций через web;
  • режим работы "подписка-доставка";
  • Web-DB Publisher - максимально простое в использовании
    средство, позволяющее конечным пользователям без знания HTML и
    SQL создавать и выполнять отчеты над базой данных через web. Специальный
    планировщик позволяет задать вам либо конкретное время генерации
    отчетов, либо периодичность.

    Продукт INFORMIX-JWORKS это компонентный инструментарий,
    позволяющий Вам как самостоятельно, так и в любой среде разработки
    приложений на Java (Java Workshop, Cafй, Visual J++ и др.), создавать
    приложения с полнофункциональным доступом к серверам БД Informix.
    Кроме того, виртуальная Java машина встраивается непосредственно
    в INFORMIX Universal Server.

    Коротко об участниках программы "INFORMIX-Universal
    Web Connect partners".


    КомпанияПродукт
    		Функциональность
    BluestoneSapphire/Web Среда разработки приложений для WEB
    HANT SoftwareHANTSITE Среда разработки, мониторинга и управления web-узлом
    NetDynamicsNetDynamics Studio

    App Server
    		Основанная на Java среда разработки для web
    NetObjectsFusionСреда создания и развития web-узла
    OneWaveOneWave Enterprise
    		Средство, предоставляющее возможность уже существующим клиент-сервер приложениям работать через web
    Wallop SoftwareBuild-IT Cреда управления web-узлом


    Конечно, все сказанное можно рассматривать только как короткое
    сообщение о предлагаемых Informix и его партнерами решениях. Мы
    всегда будем рады рассказать Вам подробно о заинтересовавших Вас
    продуктах, показать их в работе. Достаточно позвонить.

    IUWA: универсальная архитектура Informix для работы в Internet/Intranet

    Рис. 3.

    IUWA: универсальная архитектура Informix для работы в Internet/Intranet

    Рис. 4.

    IUWA: универсальная архитектура Informix для работы в Internet/Intranet

    Рис. 5.

    []
    []
    []

    JASMINE: объектно-ориентированная мультимедийная СУБД

    О. Арефьев, Computer Associates



    Построение виртуального предприятия

    В настоящее время фирмам нужно перерабатывать горы информации, которую невозможно хранить в традиционных базах данных. К такой информации относится видео, звук и анимация. При этом фирмы остро нуждаются в создании мощных мультимедийных приложений следующего поколения, которые можно разместить в Internet, корпоративных Intranet и в системах клиент/сервер.

    Jasmine может удовлетворить все эти потребности. Это первая и единственная промышленная объектно-ориентированная база данных, предоставляющая систему разработки мультимедиа-приложений, ориентированных на Internet/Intranet. Jasmine - это полнофункциональное интегрированное решение, открывающее бизнесу новые рынки, позволяющее повысить производительность, снизить затраты и вдохнуть новую жизнь в существующие системы

    Обзор технологии

    Уникальность продукта Jasmine объясняется согласованностью взаимодействия различных его функций. Jasmine одновременно:

    ...Объектно-ориентированный

    Представляя бизнес-данные с помощью мультимедийного интерфейса, формируя логику приложений или накапливая данные в базе данных, Jasmine сохраняет объектно-ориентированный подход. Это важно, потому что объекты могут быть спроектированы один раз и затем многократно использованы, обеспечивая быстрое создание и распространение все более и более сложных приложений. Упрощается и процесс приспособления созданных ранее систем к изменяющимся потребностям бизнеса: доработке подлежат лишь отдельные структурные блоки, которых касаются изменения. Это исключает необходимость коренной переработки прежней версии продукта и позволяет строить чрезвычайно гибкие коммерческие приложения.

    Кроме того, объектная СУБД увеличивает количество доступных и интерпретируемых данных. В то время как в прошлом компании были способны фиксировать скудные 15% от того объема данных, с котором они работали, Jasmine управляет всем пространством данных: от видео, звука, пространственных координат и карт, до молекулярных структур, временных рядов, финансовых инструментов и телекоммуникационных сетей.
    Это увеличение в качестве и количестве данных улучшает процесс принятия решений.

    ...Обеспечивающий работу с Internet/Intranet

    Система Jasmine в полной мере использует возможности интеграции Internet (или, в пределах компании,- Intranet) с широким спектром бизнес-стратегий, технологий и функций. Используя огромные возможности Internet, Jasmine уменьшает затраты на поиск заказчиков и поставщиков, геометрически расширяет рынки и облегчает организацию своевременного производства и платежей. В рамках корпоративной Intranet Jasmine способствует концентрации деловой активности на особо-важных направлениях, упрощению организации бизнеса и предоставляет возможность работникам более эффективно обмениваться информацией.

    ...Поддерживающий мультимедиа

    Благодаря многовариантности представления информации мультимедиа-системы коренным образом улучшают качество информации. Например, при их использовании в целях рекламы товаров можно создать столь привлекательный виртуальный интерфейс, что рекламируемая продукция будет представлена потенциальному заказчику с самой выгодной стороны. А это сразу приведет к увеличению объема реализации. Мультимедиа могут также использоваться корпорациями для передачи важнейшей информации акционерам для получения их поддержки. Служащие, имеющие мощь мультимедиа в своем распоряжении, повышают производительность своей работы и принимают решения лучше и быстрее. Они также тратят минимальное время на изучение новых приложений.

    ...Полнофункциональный и открытый

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

    Так как все функциональные модули Jasmine бесшовно интегрированы в целостную визуальную среду, Jasmine позволяет существенно поднять производительность труда программиста.


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

    ...Мощный и надежный

    Разработчики могут легко создавать прикладные программы, которые отражают сложности ежедневной деловой активности. Jasmine, который объединяет бизнес-процессы и данные в связную объектную модель, позволяет разработчикам решать сложные проблемы, создавая приложения путем простой компоновки типовых структурных элементов. Построенные на основе проверенных технологий Computer Associates International, Inc. (CA) и Fujitsu, приложения Jasmine постоянно демонстрируют высокие стандарты целостности, надежности и производительности, которые необходимы для критически важных бизнес-функций.

    ...Переносимый и расширяемый

    Jasmine учитывает, что разработчикам выгодно создать приложение один раз, а затем распространить в Internet или Intranet. Доступ к созданной Jasmine продукции открыт повсюду благодаря многоплатформенной Web-ориентированной исполнительной среде. Использование большого массива библиотек классов, созданных CA и Fujitsu, а также множеством независимых фирм-производителей программного обеспечения, позволит пользователям реализовать мощный потенциал Jasmine для расширения спектра приложений.

    Архитектура

    Приложения Jasmine допускают распространение: они работают на рабочих станциях клиентов, как автономных, так и на Web-браузерах, а также взаимодействуют с сервером базы данных, реализующим бизнес-логику и обеспечивающим хранение объектов мультимедиа.

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

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

    Особенности системы:

    Индустриально-мощный, многоплатформенный, объектно-ориентированный процессор базы данных

  • Высокоэффективный процессор базы данных, действующая как репозитарий для определения, администрирования и параллельного доступа к определениям классов и объектам;
  • Объектно-ориентированная база данных обеспечивает интеллектуальную поддержку для сложных структур и больших объемов данных, требуемые современными мультимедиа-приложениями, и все возможности, необходимые в современных объектных базах данных, включая многократное наследование, методы и свойства классов;
  • Богатый объектно-ориентированный язык для описания бизнес-логики на сервере, обеспечивающий все возможности современных объектно-ориентированных языков; Jasmine также поддерживает методы в C, C++ и Java;
  • Обширная библиотека классов с предопределенными классами для мультимедиа и других сервисных классов;
  • Универсальный доступ к унаследованным системам, обеспечивающий интеграцию с данными в реляционных базах данных из объектно-ориентированной оболочки;
  • Открытый интерфейс разработки приложений (API) для C и C++ и любых систем разработки приложений, поддерживающих OLE ;
  • Сервер доступен для различных UNIX-систем и Windows NT.

    Интегрированная среда разработки для создания визуальных объектно-ориентированных мультимедийных приложений

  • Система разработки с обширной совокупностью мультимедиа-классов, включающих обработку изображений, видео, звука, алгоритмически сгенерированной фоновой музыки и речевого распознавания;
  • Интеллектуальный редактор для расположения объектов на "сцене", определяющий их свойства и поведение, определяющий их взаимодействие с пользователем и устанавливающий связь объектов с базой данных;
  • Визуальные, типа "point-and-click", средства для определения классов, программирования методов и редактирования объектов;
  • Среда разработки доступна для Windows 95 и Windows NT.

    Небольшие требования к платформе для эксплуатации мультимедиа-систем, работающих или самостоятельно, или как модули расширения Web-браузеров

  • Автономный режим работы, подходящий для внутриофисных приложений, автономных императивных систем мультимедиа со свободным доступом и многих других ситуаций;
  • Работа в виде расширения к Web-браузерам, в частности как полностью интегрированного модуля расширения для Netscape Navigator; основанная на Web работа оптимизирована для ограниченной пропускной способности и обеспечивает инкрементный доступ к мультимедийным данным, интеллектуальное кэширование и сжатие их при передаче;
  • Многоплатформенное подключение к серверу: или через прямое сетевое соединение, или через соединение Internet/WEB;
  • Исполнительная среда доступна для Windows 3.1, Windows 95, Windows NT, Macintosh и платформы UNIX/Motif.

    Объектно-ориентированный процессор базы данных

    Надежная база данных

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

    Полная объектно-ориентированная функциональность



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

    Jasmine поддерживает все возможности, характерные для современных объектно-ориентированных баз данных:
  • множественное наследование;
  • свойства экземпляров и классов;
  • методы экземпляров и классов;
  • собственная поддержка наборов с помощью методов для них.

    Мощный объектно-ориентированный язык

    Методы определяются в мощном объектно-ориентированном языке с собственным синтаксисом для обработки объектов базы данных, поиска в базе данных и навигации наборов. Благодаря этому языку снимаются барьеры, разделявшие ранее программирование и базу данных: методы работают в базе данных под полным контролем систем управления транзакциями и защиты информации.

    Jasmine поддерживает методы, созданные в языках С и С++, что позволяет использовать накопленный опыт программирования и предоставляет возможность повторного использования существующей логики. Jasmine предусматривает также поддержку методов, разрабатываемых для Java - одного из важнейших средств создания приложений для Internet.

    Широкая библиотека классов

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

    Будучи полезными инструментами сами по себе, встроенные классы также обеспечивают основу для расширения, выступая в качестве предков для последующих классов, создаваемых для нужд конкретных приложений. Кроме основных классов, поддерживаемых CA, разработчики третьих фирм также поставляют библиотеки классов, что позволяет обеспечить мощную основу для разработки приложений.

    Интеграция с реляционными базами данных

    Jasmine предусматривает интегрированную поддержку дополнительных СУБД, в том числе реляционных систем, подобных CA-OpenIngres, Oracle, Sybase, Informix, SQLServer, а также СУБД для больших ЭВМ, таких как CA-IDMS, CA-Datacom, DB2. Благодаря представлению данных в виде объектов, такая интеграция позволяет применять методы, разработанные для объектов Jasmine, ко всем данным, хранящимся в разработанных ранее приложениях. Разумеется, новые приложения могут быть установлены и подключены к общей информационной системе "незаметно для пользователя", без изменения структуры существующих элементов.

    Особенно тесно взаимодействует Jasmine с CA-OpenIngres, поддерживая бесшовное управление транзакциями, защиту информации, управление дублированием данных в среде CA-OpenIngres и Jasmine.

    Гибкие API-интерфейсы

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

    База данных Jasmine поддерживает API-интерфейсы для доступа к объектам из языков С, С++ и SmallTalk. Средства ActiveX также обеспечивают подключение баз данных к Visual Basic и другим системам разработки приложений, поддерживающим ActiveX.

    Автоматический HTML-визуализатор

    Jasmine предоставляет автоматический HTML-визуализатор, обеспечивающий для текстов и форм доступ к объектам Jasmine, их связям и методам из стандартного Web-браузера. HTML-визуализатор не обладает всеми возможностями собственных средств мультимедиа Jasmine, однако позволяет выполнять настройку внешнего представления по шаблонам, разработанным на инструментальных средствах HTML.

    Среда разработки приложений

    Интегрированная среда разработки



    Интегрированная среда разработки функционирует на рабочей станции Windows (Windows 95 и Windows NT). Система предоставляет инструментарий для просмотра и редактирования объектов и классов в базе данных, а также для создания и редактирования мультимедиа-приложений.

    Просмотр и редактирование классов

    Браузер классов используется для идентификации и редактирования классов и их методов. С его помощью обеспечивается визуальное представление всех классов в базе данных, их отношения наследования, атрибуты и методы. База данных содержит объекты различных классов, как тех, которые могут быть представлены в мультимедиа-приложениях, так и тех, которые остаются при этом "в тени" и используются как скрытые объекты.

    Редактор методов используется для определения методов - программ, принадлежащих к одному из классов и выполняемых на сервере. Методы определяются с помощью объектно-ориентированного языка, обладающего всеми возможностями, характерными для современных систем программирования, в том числе встроенной поддержкой навигации совокупностей объектов.

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

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

    Разработка мультимедиа-приложения

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

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

    Размещение объектов на сцене

    Все классы, объекты и запросы отображаются в окне "Add Object". Вы можете разместить их путем простой буксировки на сцену.

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

    Определение взаимодействия и поведения

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

    События включают все случаи от нажатия клавиши до "задержки" курсора мыши, истечение таймеров, начало и конец мультипликации и видео, поступление сообщений посланные от других объектов. Объекты могут уметь производить большое число различных действий, включая показ графики, прогон мультипликации, звука или видео, изменение сцены и посылку сообщений другим объектам.

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

    Система также обеспечивает вычисление выражений, логику условий и циклов всякий раз, когда это требуется. Но, реально, сложная бизнес-логика не принадлежит внешнему мультимедиа-интерфейсу и выполняется методами серверной части приложения с использованием всей мощи и устойчивости к ошибкам объектно-ориентированного сервера и его объектно-ориентированного языка.

    Исполнительная среда

    Исполнительная среда Jasmine представляет собой оболочку для выполнения частей приложений, относящихся к машине клиента. Среда, в частности, управляет анимацией и другими мультимедиа-средствами, координирует взаимодействие пользователя с внутренними функциями, обеспечивает своевременное получение мультимедиа-ресурсов из базы данных, а также взаимодействует с сервером при реализации соответствующих методов.

    Исполнительная среда может функционировать в двух режимах:

    Автономный

    В данном режиме мультимедиа-приложения выполняются на компьютере так же, как и другие приложения клиент/сервер. Этот режим наиболее часто используется для создания уникальной среды для пользователя в виде законченного приложения для специальных целей. Примерами таких приложений являются электронные каталоги на CD-ROM и автономные императивные системы мультимедиа со свободным доступом.

    В такой конфигурации исполнительная среда взаимодействует с сервером с помощью любого подходящего коммуникационного протокола;

    Интегрированный как модуль расширения в Web-браузере

    Исполнительная среда Jasmine может функционировать как модуль расширения (или другой тип подключения) в Web-браузере. Это позволяет использовать мультимедиа-приложение как "applet" (небольшое специализированное приложение) в рамках HTML-страницы. Сфера его применения может быть различна: от простейших заставок и развлекательных анимационных роликов до сложнейших систем электронной коммерции.

    В данной конфигурации исполнительная среда связывается с сетью посредством протокола HTTP, являющегося стандартом для Web. В отличие от других более ранних Web-модулей расширения, Jasmine не требует загрузки по линии связи или использования нефрагментированных анимационных роликов. Взаимодействие с сервером оптимизировано для обеспечения инкрементной загрузки, чтобы минимизировать требования к быстродействию сети и использовать механизмы кэширования WEB-браузеров, проксисов и серверов.

    Программирование



    Как в первом, так и во втором режиме исполнительная среда Jasmine доступна управлению со стороны пользователя. Web-браузеры с JavaScript или VBScript обеспечивают взаимодействие с мультимедиа-приложениями Jasmine. Кроме того, другие приложения, написанные на Visual Basic или другом языке, поддерживающем OLE-технологию, также имеют возможность доступа в среду Jasmine и управляют ею.

    С процессором Pentium Pro связано появление целого ряда новых приложений в сфере управления бизнесом. Многие из этих приложений будут разработаны на Jasmine фирмы СА - одной из первых сред разработки приложений мультимедиа, которая полностью поддерживается объектной базой данных. Сочетание процессора Pentium Pro и системы Jasmine дает предприятиям возможность развернуть у себя развитые мультимедийные приложения, в которых максимально используются быстро растущие возможности Internet.

    Дейв Хаус (Dave House), Первый вице-президент корпорации Intel, Генеральный менеджер подразделения Enterprise Server Group

    Стой, смотри и слушай! В один прекрасный день во всех базах данных будут реализованы функции Internet Commerce Enabled (ICE) продукта Jasmine. Но это будет не скоро. Сейчас в Jasmine есть необыкновенный набор функций для разработки приложений следующего поколения, обогащенных мультимедиа и нетрадиционными типами данных и полным пониманием того, что распределенным приложениям нужны продуманные контроль и управление.

    Питер Кастнер (Peter Kastner), Вице-президент, Aberdeen Group

    Sun Microsystems готова помочь предприятиям воспользоваться возможностями Internet на базе таких технологий, как Java и JavaScript. По мере роста коммерческого использования Internet повысится спрос на надежную объектно-ориентированную базу данных Jasmine, позволяющую переносить новые мультимедийные приложения в сеть.

    Скотт МакНили (Scott McNealy), Президент, Председатель совета директоров и Исполнительный директор корпорации Sun Microsystems.

    Система Jasminе олицетворяет стремление СА вести рынок за собой, а не тащиться в его хвосте.


    Возможности мультимедиа сочетаются в ней с мощной средой содержательного управления, что позволяет удовлетворить насущную потребность в "новой среде" и приложениях на базе Internet/WWW.

    Наташа Крол (Natasha Krol), Вице-президент, директор по сервису, META Group

    Программа по Jasmine для партнеров по разработке программного обеспечения: Обеспечить технологию завтрашнего дня уже сегодня

    Фирма Computer Associates финансирует программу для партнеров по Jasmine, которая позволяет ее участникам создавать бизнес-приложения, удовлетворяющие требованиям завтрашнего дня.

    Программа по Jasmine для партнеров по разработке программного обеспечения является уникальной и построена таким образом, чтобы стимулировать спрос на любое связанное с Jasmine решение независимо от того, является ли оно бизнес-приложением (критически важным и полномасштабным), специализированной библиотекой классов или дополнительным инструментальным средством для среды разработки. Партнеры получаю неограниченный доступ к организациям фирмы CA по всему миру, связанных с продажей услугами и разработкой. Обширная маркетинговая программа с помощью таких средств коммуникаций как реклама, взаимодействие с прессой, конференция CA-World, участие в международных мероприятиях и других позволяет дойти до каждого потенциального потребителя.

    Открытая архитектура Jasmine и удобные API-интерфейсы облегчают провайдерам промышленных решений и системным интеграторам адекватно реагировать на текущие и возникающие потребности бизнеса. С увеличением темпов роста производства модульных программных компонентов заказчики со своими постоянно возникающими проблемами бизнеса будут обращаться к партнерам по Jasmine за современными мощными решениями для увеличения возможностей своей существующей информационной инфраструктуры.

    Дополнительную информацию относительно Программы по Jasmine для партнеров можно получить по телефонам (095) 188-47-32, 974-70-83. Следите также за информацией на Web-сервере .

    []
    []
    []

    Кто такой Артур Секрет и как это все начиналось

    Первые попытки создания интерфейса между базой данных
    и Web сервером. Роль CGI в становлении стандарта. Протокол HTTP
    в системах браузер, Web-сервер и база данных.

    Материалы технической конференции "Корпоративные базы данных '97"


  • ПЛЕНАРНЫЕ ДОКЛАДЫ

  • С.Кузнецов, Центр Информационных Технологий, Открытые системы

  • А. Волков, Компания "Корпоративные Системы"

  • Г. Ладыженский, Jet Infosystems

  • А. Вендров, Центральный Банк РФ (Москва)

  • А. Сахаров, Oracle

  • Х. Залкин, Informix

  • ПРОЕКТЫ, МЕТОДЫ И ТЕХНОЛОГИИ


  • С. Лапин, Е. Фоминский, Г. Козлов, Е. Фоминская, Б. Позин, Компания Аргуссофт

  • В. Ляшков, ФОРС

  • А. Закис, Н. Приезжий, DataX/FLORIN

  • В. Индриков, АО ВЕСТЬ

  • А. Старыгин, МетаТехнология

  • ПЕРЕХОД К АРХИТЕКТУРЕ КЛИЕНТ-СЕРВЕР


  • Б. Вольфман, ЭЛКО Технологии

  • С. Орлик, Borland

  • CASE-СРЕДСТВА И СИСТЕМЫ БЫСТРОЙ РАЗРАБОТКИ ПРИЛОЖЕНИЙ

  • Е. Ойхман, О. Евсеев, С. Паронджанов, Компания Аргуссофт (Москва)

  • Л. Сорокин, Oracle

  • УПРАВЛЕНИЕ ДАННЫМИ В РАБОЧИХ ГРУППАХ


  • А. Чернышев, Алконсофт

  • Г. Серяков, А. Симкин, Б. Позин, Компания Аргуссофт (Москва)

  • ОРГАНИЗАЦИЯ И АДМИНИСТРИРОВАНИЕ СОВРЕМЕННЫХ СУБД


  • О. Арефьев, Computer Associates

  • А. Бачин, ИВЦ АИС (Москва)

  • ТЕХНОЛОГИИ ДОСТУПА К БАЗАМ ДАННЫХ В INTERNET


  • Б. Филимонов, РД ТеХ

  • А. Гвоздев, Informix

  • М. Елашкин, Oracle

  • А. Шуленин, Microsoft


    Менеджер хочет узнать...

  • Как найти заказы на сумму более чем $500, место доставки которых находится в пределах 50 км от заказчика

    select C.cname from customer C, order O where Within50 (C.location, O.iocation) = T and O. Amount >500

  • Как найти заказы с пометкой "срочно", РО Date которых находится в пределах 4 дней от Order Date

    select cname, orderID from order where FaxDateDiff(PO_fax,date)
    *Within50() и FaxDateDiff() являются определяемыми пользователем функциями

  • Как найти маршруты, находящиеся в пределах зоны с почтовым кодом 77056
    select R.route from route R, facility F where GeoZip (F.location) = 77056 and whithin (F.location, R.route_pts)


    Как найти маршруты, общая длина которых превышает 100 км, с пометкой 'priopity'
    select route from route where RouteLength(route_pts) > 100 and ContainsWords(route_notes,'priority') = T
    *GeoZip(), Within(), RouteLength() являются определяемыми пользователем функциями


  • Как найти компоненты от поставщика XYZ в филиалах, расположенных в пределах 77056 почтовой зоны
    select component_id from component C, facility F where GeoZip (F.location) = 77056 and C. Fname = F.fname and comp_id. Name like 'XYZ'; (comp_id is a ROW TYPE)
  • Где найти чертежи компонент, которые нуждаются в техническом обслуживании (временной ряд), помеченные "трудно"
    select schematic from component where MaintlsDue= T and ContainsWords(comp_notes,'difficult') = T;
  • Найти компоненты, находящиеся в пределах пяти метров от места утечки
    select component_id from component where DistWithin(comp_loc,(300,500))
    *GeoZip(),MaintlsDue() иDistWithin() являются определяемыми пользователем функциями

    Microsoft SQL Server и активный Internet

    А. Шуленин, Microsoft

    1. Обзор основных способов доступа

    Правилом хорошего тона при написании статей, прямо
    или косвенно затрагивающих тему Сети, стало введение, содержащее
    философский анализ природы данного общественного явления и причин
    столь взрывного роста его популярности. В силу априори ограниченного
    объема пространства и времени мы позволим себе отступить от этого
    правила и перейдем сразу к более прозаическим вопросам практики
    создания Internet/Intranet приложений для работы с Microsoft SQL
    Server.

    Internet действительно неожиданно бурно ворвался
    в устоявшуюся жизнь разработчиков клиент-серверных приложений.
    Однако первоначальный шок довольно быстро прошел, как только наступило
    осознание нехитрого в общем-то факта, что структура Интернет/интранет
    приложений имеет много общего с традиционной платформой "клиент-сервер".
    Правильнее говоря, World Wide Web также основывается на клиент-серверной
    архитектуре. В самом деле, Web-браузер является типичным клиентским
    front-end'ом, основное отличие которого от клиентских мест, построенных
    с помощью Visual C++, Visual Basic, Visual FoxPro и других средств
    разработки, состоит в более гибко настраиваемой функциональности,
    которая может определяться даже во время выполнения программы.
    При этом не требуется ни перекомпиляции, ни переустановки модулей,
    что уже само по себе является нетривиальной задачей в больших
    и сложных клиент-серверных системах масштаба корпорации. Правда,
    первоначально браузеры использовались только как средства форматирования
    статического текста. Однако активно развивающийся в Internet бизнес
    вскоре перестал довольствоваться простой публикацией рекламы предприятия
    и справочной информации о его деятельности. Например, клиент имел
    полное право хотеть выбрать из рекламного проспекта фирмы понравившиеся
    ему образцы и совершить покупку. Подобно типичному интерфейсу
    клиентского приложения на VB, VFP и т.д., сценарий работы предполагал
    заполнение клиентом некоторой формы, населенной, вообще говоря,

    различными элементами управления, отправку соответствующего запроса
    на сервер и прием результатов обработки. Таким образом, требования
    бизнеса выдвинули на первый план принципы динамического взаимодействия
    браузера и Web-сервера внутри сессии, что заставило задуматься
    как об активной роли браузера, так и о расширении функциональности
    сервера по сравнению с простым хранением и пересылкой HTML-документов.

    Первым способом повышения активности Web-страниц
    стали приложения Common Gateway Interface (CGI), поскольку спецификация
    CGI позволяет браузеру вызвать тот или иной исполняемый модуль
    или скрипт на Web-сервере, который мог обратиться с запросом к
    базе данных, построить в HTML-кодах страницу результатов и передать
    ее обратно Web-серверу, который же, в свою очередь, отсылал результаты
    браузеру. CGI-приложения могут содержать вызовы других программных
    (написанных, например, на С++) или командных (.bat, .cmd) файлов.
    С помощью CGI-cкриптов, а точнее на языке PERL (Practical Extraction
    and Reporting Language), построено немало интерактивных Web-приложений.
    К сожалению, каждый такой скрипт исполняется как иной, нежели
    Web-сервер, процесс, что быстро "съедает" ресурсы даже
    достаточно "навороченной" по сегодняшним меркам машины,
    особенно при большом количестве заходов на сервер.

    Помимо исполнения CGI-скриптов, Microsoft Internet
    Information Server (MS IIS) предоставляет разработчикам возможность
    создания с помощью соответствующего API (ISAPI) приложений в виде
    dll, запуск которых происходит в ответ на команду или выбор линка
    на Web-странице. Каждое такое приложение выполняется в адресном
    пространстве Web-сервера, что, естественно, повышает скорость
    работы и существенно экономит машинные ресурсы. В зависимости
    от сложности сайта и приложений, dll могут быть предзагружены
    одновременно с запуском сервера, либо подгружаться/выгружаться
    из памяти по мере необходимости.

    Целью настоящей статьи является рассказ о способах
    построения активных Web-страниц и средствах их взаимодействия
    с Microsoft SQL Server. К наиболее известным средствам разработки
    приложений на основе ISAPI относятся входящий в состав MS IIS
    Internet Database Connector (IDC), а также свободно распространяемый
    dbWeb. Кроме этого, мы рассмотрим простую, но достаточно мощную
    утилиту в составе самого MS SQL Server 6.5 под названием SQL Web
    Assistant. В завершение мы поговорим о развитии стратегии распределенных
    вычислений, компонентном подходе к созданию распределенных приложений
    и о концепции активных серверных страниц как наглядной реализации
    компонент доступа к MS SQL Server через Интернет/интранет. Позиционирование
    этих средств по шкале "сложность/функциональность" приводится
    на рис.1.

    Microsoft SQL Server и активный Internet

    Рис.1

    Microsoft SQL Server Web Assistant

    Microsoft SQL Server Web Assistant

    В состав Microsoft SQL Server 6.5 входит SQL Web
    Assistant (см.рис.2), с которого было бы целесообразно начать
    наше рассмотрение, так как это довольно простая в использовании
    утилита, не требующая знания HTML и серьезной практики работы
    с SQL. Web Assistant имеет интерфейс мастера (wizard), т.е. состоит
    из ряда последовательных форм с вопросами, отвечая на которые
    администратор может сэкономить время по выполнению рутинного HTML-кодирования
    и получить готовую (в HTML-кодах) страницу, содержащую результаты
    опубликования произвольного запроса к базе. Полученная страница
    не является активной в строгом смысле этого слова, так как публикуется
    при помощи push-метода (cм.рис.4), т.е. обновление происходит
    по инициативе сервера, и не допускает обновления со стороны клиента.
    Однако сервер может производить обновление (перегенерацию) страницы
    на триггерной основе или на основе расписаний задач под управлением
    SQL Executive. Мастер работает только с базами данных MS SQL Server
    и использует три хранимых процедуры sp_makewebtask, sp_runwebtask
    и sp_dropwebtask. При необходимости они могут использоваться самостоятельно
    в кодах T-SQL.

    Рассмотрим следующий простой пример. Пусть мы имеем
    некоторую базу данных MS SQL Server, содержащую таблицу rates
    с курсами валют.

    idkod
    		kurs
    1Валюта 11000.00
    2Валюта 22000.00
    3Валюта 33000.00
    4Валюта 44000.00
    5Валюта 55000.00
    6Валюта 66000.00
    7Валюта 77000.00
    8Валюта 88000.00
    9Валюта 99000.00


    Microsoft SQL Server Web Assistant

    Рис. 3

    Мы хотим публиковать на Web оперативные данные об
    изменении курсов, как только таковые будут иметь место. Для этого
    мы определяем задачу публикации:

    sp_makewebtask @outputfile
    = 'c:\rates.htm', @query = 'select kod, kurs from rates', @procname=web_rates,@resultstitle
    = 'Курсы валют', @URL = "http://www.microsoft.com",
    @reftext = 'Microsoft Home Page', @whentype=9

    Практически все значения параметров здесь интуитивно
    понятны. В пояснении нуждается только последний @whentype, который

    означает, что страница должна быть создана сразу по выполнении
    данного оператора, а также в дальнейшем по мере поступления запросов.
    Полный перечень параметров процедуры и их назначение приводится
    в руководстве по языку T-SQL.

    Далее мы можем определить триггер на все виды транзакций
    в таблице rates:

    if exists (select * from
    sysobjects where id = object_id('dbo.tr') and sysstat & 0xf
    = 8)

    drop trigger dbo.tr

    go

    create trigger tr on dbo.rates
    for insert,update,delete

    as exec sp_runwebtask
    @procname=rates

    go

    Microsoft SQL Server Web Assistant

    Рис.4

    Теперь любое изменение в таблице rates вызовет обновление
    страницы c:\rates.htm. В своей презентации на выставке UnixExpo'97
    я немного усложнил задачу и посылал запрос на MS SQL Server по
    электронной почте непосредственно в теле письма с темой SQL.

    update rates set kurs=kurs+100
    where id=1

    На MS SQL Server в этот момент была запущена утилита
    SQLMail, обеспечивающая взаимодействие с электронной почтой, и
    хранимая процедура

    sp_processmail @subject='SQL',
    @dbuse='db_rates', @set_user='dbo',

    смысл которой состоял в том, чтобы сканировать содержимое
    ящика входящих сообщений, выбирать из них непрочитанные с темой
    SQL и передавать содержащийся запрос на выполнение MS SQL Server.
    Как только письмо поступало, запрос обрабатывался и триггер инициировал
    обновление соответствующей страницы.

    2. dbWeb

    Microsoft dbWeb представляет собой шлюз между 32-битными
    ODBC-ресурсами, в качестве которых могут выступать, например,
    Microsoft SQL Server, Microsoft Access, Microsoft Visual FoxPro,
    Oracle и т.д., и MS IIS. dbWeb предусматривает создание схемы,
    содержащей описание данных и связанных с ними Web-страниц. Он
    поддерживает исполнение запросов в реальном режиме времени на
    основе "pull"-модели публикации, позволяя тем самым
    создавать активные Web-страницы.

    Microsoft SQL Server Web Assistant

    Рис.5

    Microsoft dbWeb структурно состоит из двух основных
    компонент: dbWeb Service и dbWeb Administrator (cм.рис.5). dbWeb
    Service является типичным ISAPI-приложением, которое обрабатывает


    пользовательские запросы, направляемые посетителем страницы через
    браузер, и управляет соединениями между браузером, ODBC-ресурсом
    и IIS. К функциям dbWeb Administrator относится создание HTML-страниц,
    содержащих результаты выполнения запросов на основе уже упоминавшихся
    схем, с помощью которых осуществляется управление публикуемыми
    данными. Схемы определяют сам запрос и структуру страниц. При
    этом не требуется знания HTML или ISAPI, так как в состав dbWeb
    Administrator входит интерактивный мастер-построитель схем (Schema
    Wizard), который в традиционной для любой программы-мастера манере
    позволяет задать поля поиска по методу Query-by-Example (QBE),
    выбрать поля для отображения в таблице страницы результатов и
    определить переходы из списка записей в отдельные страницы, содержащие
    развернутую информацию по текущей записи. Настройкой соответствующих
    свойств можно разрешать или запрещать операции вставки, удаления
    и редактирования. Для проверки прав пользователя используется
    система безопасности той СУБД, к которой происходит доступ. dbWeb
    имеет в своем составе широкий спектр шаблонов страниц, которые
    при необходимости могут быть легко откорректированы и настроены
    разработчиком для более полного соответствия его задачам. Таким
    образом, dbWeb не является конечным пользовательским приложением.
    Скорее его можно охарактеризовать как достаточно легкий в использовании
    инструментарий разработки, который, как всякий мастер, не поддерживает
    языка программирования и оттого, на мой взгляд, несколько проигрывает
    в функциональности рассмотренному нами ранее SQL Web Assistant,
    несмотря на возможность инициируемого посетителем обновления информации
    в базе. Тем не менее, эта программа успешно справляется с автоматизацией
    большинства рутинных операций по организации соединений и публикации
    данных из БД и покрывает, по разным оценкам, порядка 40-60% потребностей
    бизнеса среднестатистической фирмы при организации доступа к своим
    источникам данных через Internet.


    dbWeb является свободно распространяемым
    приложением и может быть установлен с Microsoft Technet, Windows
    NT Resource Kit или непосредственно с .

    3. Internet Database Connector (IDC)

    IDC является другим примером достаточно давно и успешно
    используемого ISAPI-приложения. Он входит в состав MS IIS. С помощью
    вызовов функций ODBC API IDC обеспечивает прямую связь между полями
    HTML-формы и соответствующим ODBC-достижимым источником данных,
    например, базой данных MS SQL Server, без необходимости написания
    замысловатых CGI-скриптов. Схема работы IDC показана на рис.6.

    Для доступа к данным и публикации на Web IDC использует
    файлы двух типов- .idc и .htx. Файл с расширением idc содержит
    всю необходимую информацию о соединении с источником данных, текст
    запроса, а также ссылку на соответствующий htx-файл. Файл с расширением
    htx служит шаблоном страницы, на которой будут опубликованы данные
    из базы, а также элементы оформления в виде статического текста,
    графики, видео и т.п.

    Microsoft SQL Server Web Assistant

    Рис.6

    MS IIS распознает расширение .idc как вызов httpodbc.dll,
    которая считывает http-заголовки из управляющего блока ISAPI для
    определения параметров запроса. Httpodbc.dll читает и разбирает
    idc-файл, указанный в URL. Имя источника, имя пользователя, пароль
    и пр. используются для подключения к соответствующему ресурсу
    ODBC, после чего httpodbc передает на выполнение SQL-запрос и
    получает результаты. Результаты используются для наполнения заготовки
    в виде htx-файла, после чего полученный HTML-документ MS IIS передает
    браузеру. Описанная последовательность действий иллюстрируется
    на рис.7

    Продолжим развитие нашего простого примера из п.2
    средствами IDC. Опубликуем таблицу rates с помощью файлов rates.idc
    и rates.htx

    Microsoft SQL Server Web Assistant

    Рис.7

    Rates.idc:

    Datasource: rates

    Template: rates.htx

    SQLStatement: select id,kod,kurs from rates

    Username: sa

    Rates.htx:

    "-//IETF//DTD HTML//EN">






    content="text/html;
    charset=windows-1251">

    content="Microsoft FrontPage 2.0">







    Курсы
    валют












    <%begindetail%>








    <%enddetail%>
    face="Times New Roman CYR">Код face="Times New Roman CYR">Курс

    href="http://ntalexejs/aaa/rates_edit.idc?id1=<%id%>">
    face="Times
    New Roman CYR"><%kod%>    		 face="Times New Roman CYR"><%kurs%>






    Попутно заметим, что Microsoft FrontPage предоставляет
    удобный редактор для построения заготовок и программу-мастер для
    генерации idc-файлов. Результат показан на рис.8.

    Microsoft SQL Server Web Assistant

    Рис. 8

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

    Модуль DataBlade


    Модуль DataBlade
  • Расширяет функциональность СУБД
  • Определяемые пользователем типы данных и поведение
  • Легко адаптируется самим заказчиком
  • Выбор решений



    • Модули DataBlade: географические и пространственные данные


    ECOlogic CorporationECOlogic Visualization DataBlade
    Informix Software, Inc. Informix Spatial DataBlade
    MapInfo CorporationMapInfo Geocoding DataBlade
    TelContar TelContar Global/Interval DataBlade



    Модули DataBlade: контекстный поиск и документооборот


    ArborTextArborText SGML Document Objects DataBlade
    Excalibur Technologies Corporation ExcaliburReal-Time Profiling DataBlade Excalibur Text DataBlade
    IsoQuest IsoQuest Name Tag DataBlade
    Open Text CorporationOpen Text LiveLink Document Managment DataBlade
    Personal Library SoftwarePLS Text DataBlade Verity Text DataBlade
    Verity,Inc.Verity Text Extender DataBlade



    Модули DataBlade: мультимедийные данные


    Excalibur Technologies Corporation Excalibur Face Recognition

    Excalibur Image DataBlade

    Excalibur Scene Change DataBlade
    Informix Software, Inc. Informix Video Foundation DataBlade
    MuscleFish LLC MuscleFishAudio Information Retrieval DataBlade
    NEC CorporationNEC TigerMark DataBlade
    Virage,Inc.Visual Information Retrieval DataBlade
    Vxtreme,Inc.Vxtreme VideoDataBlade



    Модули DataBlade: Web/Electronic Commerce


    Informix Software, Inc. Informix Web DataBlade
    Mortice Kern Systems,Inc,MKS Content Management DataBlade
    Open Market, Inc. Open Market Internet Commerce DataBlade
    Prime Factors,Inc. Prime Factors DesCrypt DataBlade
    SLP-StatistiquesSLP Web Report DataBlade



    Объектно-ориентированные базы данных

    Datablade и картридж как инструменты создания Internet-приложений.

    Общие характеристики универсального сервера

  • Способность хранить и управлять
  • любыми данными
  • в одном объединенном источнике
  • и при этом пользоваться централизованными механизмами
  • оптимизации запросов
  • администрирования баз данных
  • архивирования и восстановления данных
  • безопасности и целостности данных
  • Пользоваться открытым, стандартным интерфейсом (т.е. SQL)
  • Масштабируемость (Scalability)
  • Дополняемость (Extensibility)

    т.е. возможность добавлять новые типы
    данных в ядро СУБД-до бесконечности
  • Производительность
  • Открытая поддержка инструментальных средств
  • Хранение и доступ к Web-страницам


    Опыт разработки систем конфигурационного управления

    Г. Серяков, А. Симкин, Б. Позин, Компания Аргуссофт (Москва)



    Необходимые сведения о
    конфигурационном управлении (КУ)

    Элементы КУ

  • Объекты, которые составляют конфигурацию
  • Состояния, которые принимают объекты
  • Действия, которые осуществляются с объектами
  • Исполнители, которые осуществляют действия

    Чем является КУ для пользователей

    Для сотрудников организации, охваченной КУ, она может различным образом (воспринимаемые особенности ранжированы от точки зрения руководителя до рядового исполнителя):
  • Контроль процесса,
  • Организация процесса,
  • Автоматизация процесса,
  • Применение людьми технических средств.

    Особенности различных систем конфигурационного управления

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

    Пример СКУ со сложностью данных (СКУ для "ЦЕНТР-МЕБИУС")

    Постановка задачи:

  • Внедрение конфигурационного управления в процессы разработки и сопровождения,
  • Документирование процессов разработки и сопровождения,
  • Реинжиниринг процессов разработки и сопровождения,
  • Построение модели версионных данных,
  • Построение схемы применения средств PVCS,
  • Инсталляция и настройка средств конфигурационного управления,
  • Разработка методики конфигурационного управления.

    Особенности задачи

  • Крупная программная система (10,000 файлов)
  • Одновременно с построением СКУ производился реинжиниринг программной системы,
  • Многоплатформенность программной системы,
  • Многомодульная структура программной системы,
  • Совместное использование компонент.

    Схема версионного хранения

    Схема версионного хранения основана на модели версионных данных, то есть формальном представлении объектов КУ в их взаимном отношении (Рис. 1).
    Опыт разработки систем конфигурационного управления
    Рис. 1.

    Пример СКУ со сложностью процессов (СКУ региона для сопровождения
    нормативно-справочной документации в масштабах региона)

    Постановка задачи

  • Выявление процессов ведения и сопровождения НСД,
  • Формализация процессов,
  • Построение схемы применения средств PVCS,
  • Построение модели данных слежения,
  • Разработка вспомогательного ПО.

    Особенности задачи

  • Территориальная распределенность
  • Включенность в ежедневный технологический процесс
  • Интеграция с почтовыми системами
  • Упрощенная модель данных.

    Схема ведения и сопровождения

    Опыт разработки систем конфигурационного управления

    Рис. 2

    Опыт разработки систем конфигурационного управления
    Рис. 3

    Опыт разработки систем конфигурационного управления
    Рис. 4

    Опыт разработки систем конфигурационного управления
    Рис. 5

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

  • Отображение актуального состояния процессов ведения и сопровождения
  • Просмотр истории процессов ведения и сопровождения
  • Ручная коррекция состояния
  • Генерация отчетов
  • Автоматизированная регистрация событий конфигурационного управления с помощью сообщений почтовой системы

    []
    []
    []

    Пример дополняемости


    create table customer(
    		Пример дополняемости
    ЖЖЖcname

    caddress

    start_year
    		varchar(30),

    varchar(40),

    int);
    create table order(
    orderID

    cname

    amount

    date
    		int,

    varchar(30),

    money,

    date);



    create table facility(
    		Пример дополняемости
    ЖЖЖ fname

    faddress
    		 varchar(30),

    varchar(40));
    create table component(
    component_id

    description

    fname
    		 varchar(20),

    varchar(100),

    varchar(30));


    Пример расширяемости


    create table facility(
    		Пример расширяемости
    ЖЖЖ fname

    faddress

    route
    		varchar(30),

    varchar(40),

    varchar(20));
    create table route(
    route

    description
    		 varchar(20),

    varchar(100));


    Rates_edit.htx

    "-//IETF//DTD HTML//EN">







    content="text/html;
    charset=windows-1251">

    content="Microsoft FrontPage 2.0">

    Untitled<br> Normal Page





     



    method="POST"
    name="rates_edit"

    <%txtkurs%>"&id1="<%id%>"">

    face="Times New Roman CYR">Код валюты- <%kod%>




    face="Times New Roman CYR">Курс
    type="text"
    size="20" name="txtKurs" value="<%kurs%>">


    type="submit" name="B1"

    value="Передать
    изменения">








    Результат приводится на рис.9. Далее результаты редактирования
    курса передаются обратно в базу данных, т.е. файл rates_submit.idc
    будет, очевидно, содержать оператор update, а соответствующий
    .htx- переход на новую страницу или возвращение обратно на просмотр
    списка и т.д.

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

    Rates_edit.htx

    Рис.9

    4. Active Data Objects

    Когда речь заходит о компонентах ActiveX, как правило,
    неявно подразумевается клиентская часть приложения. Microsoft
    Active Server Pages (ASP)- активные серверные страницы- представляют
    собой инструмент для эффективной разработки серверных Web-приложений,
    интегрирующих в своем составе HTML-код, VBScript и компоненты
    ActiveX. Это означает, что в уже существующие наработки легко

    могут быть встроены фрагменты кода на VBScript или JavaScript,
    а также вызовы соответствующих объектов ActiveX. Как, наверное,
    известно, VBScript- это сужение хорошо знакомого языка программирования
    Visual Basic на область создания Web-страниц. Основным идейным
    отличием VBScript от VB, на мой субъективный взгляд, служит то,
    что VBScript не содержит операторов файлового ввода-вывода и вообще
    средств прямого доступа к операционной системе (напрашиваются
    параллели, если Java сопоставить с С/С++, не правда ли). Кроме
    этого, в VBScript существует только один тип переменных- variant,
    отсутствуют декларативные константы и т.п. Наличие привычного
    синтаксиса языка высокого уровня существенно упрощает создание
    HTML-страниц. См. классический пример:





    <% For i = 3 To 7 %>

    i %>>

    Hello World!


    <% Next %>





    Кроме этого, в состав среды активных серверных страниц
    (ASP Framework) входят следующие 5 основных встроенных объектов.

  • Application (приложение)- для
    разделения информации между всеми пользователями данного приложения
  • Request (запрос)- для получения тех значений,
    которые броузер клиента передает на сервер по HTTP-запросу, т.е.,
    грубо говоря, для получения информации о пользователе или от пользователя
  • Response (ответ)- для передачи информации клиенту
  • Server (сервер)- предоставляет возможность обращения
    к методам и свойствам сервера для управления средой исполнения
    ASP
  • Session (cеанс)- для хранения информации, относящейся
    к данной пользовательской сессии.

    Подробнее узнать о назначении и использовании объектов
    ASP, их методах и свойствах можно, обратившись к документации,
    например, Active Server Pages Roadmap.

    Помимо базовых объектов, ASP поддерживают многочисленные
    компоненты ActiveX, которые упрощают создание и значительно повышают
    функциональность активных Web-страниц. К ним относятся различные
    элементы управления, компоненты, создающие содержание приложения,


    компоненты ввода/вывода в файл (чего, как мы помним, не было в
    VBScript) и многие другие. Но нас в первую очередь будут интересовать
    компоненты, позволяющие организовать доступ к базам данных, или
    Active Data Objects (ADO).

    Rates_edit.htx

    Рис.10

    В отличие от хорошо известных Data Access Objects
    (DAO) или Remote Data Objects (RDO) ADO имеют менее иерархически
    строгую структуру (см.рис.10) и потому более удобны при работе
    с базами данных.

    Например, публикация нашей таблицы с курсами валют
    при помощи ASP и ADO может быть выполнена следующим образом.

    Ratesado.asp

    <% if IsObject(Session("conn"))
    then

    set c=Session("conn")

    else

    set c=Server.CreateObject("ADODB.Connection")

    c.Open "rates","sa",""

    set Session("conn")=c

    end if

    set RS=c.Execute("select
    * from rates")%>

    "-//IETF//DTD HTML//EN">






    content="text/html;
    charset=windows-1251">

    content="Microsoft FrontPage 2.0">

    Курсы валют





    face="Times New Roman CYR">Курсы

    валют












    <% do while not RS.EOF
    %>







    <% RS.MoveNext

    loop %>
    face="Times New Roman CYR">Код face="Times New Roman CYR">Курс
    <%
    id1=RS("id") %>
    href="http://ntalexejs/aaa/ratesado_edit.asp?id1=<%=id1%>"><%=RS("kod")%>    		 <%=RS("kurs")%>






    Получим результат, аналогичный рис.7. Обратите внимание
    на передачу идентификатора соединения между разными скриптами
    с помощью переменных класса Session. Обновление курса валюты организуем
    следующим образом:

    Ratesado_edit.asp

    <%id1=Request.QueryString("id1")

    RS=Session("conn").Execute("select
    kod,kurs from rates where id="&id1)

    kurs1=RS("kurs")%>

    "-//IETF//DTD HTML//EN">






    content="text/html;
    charset=windows-1251">

    content="Microsoft FrontPage 2.0">

    Код валюты





    method="POST" name="frm">

    name="hid" value="<%=id1%>">Код

    валюты <%=RS("kod")%>



    Курс
    name="txtKurs"
    value="<%=kurs1%>">


    type="submit" name="B1"

    value="Передать
    изменения">








    Приведенный код вполне может быть воспроизведен,
    и если он вдруг заработает , то мы получим страницу типа той,
    что изображена на рис.9. Наконец, запрос на обновление оформим
    как отдельный asp:

    Ratesado_submit.asp

    <%Session("conn").Execute
    "update rates set kurs=" & Request.Form("txtKurs")
    & "where id=" & Request.Form("hid")

    Response.Redirect("ratesado.asp")%>

    Последний оператор осуществляет автоматический переход
    на просмотр таблицы курсов.ADO являются универсальным инструментом
    доступа к данным. Вы можете без изменений использовать интерфейс
    ADO из данного примера при работе с базами данных на VB, Visual
    FoxPro и т.д. Наконец, с помощью ADO, в свою очередь, могут быть
    построены пользовательские компоненты, для обращения к серверу
    баз данных как со стороны "толстого" (Win32), так и
    со стороны тонкого (Internet Browser) клиента. Функции обеспечения
    целостности транзакций, сервисы безопасности и согласованной работы
    компонент в распределенном приложении может взять на себя Microsoft
    Transaction Server (cм.рис.11), но это уже тема совсем другого
    рассказа.

    Rates_edit.htx

    Рис.11



    []
    []

    Rates_edit.idc

    Datasource: rates

    Template: rates_edit.htx

    SQLStatement: select id, kod, kurs from rates where
    id=%id1%

    Username: sa

    Развитие электронной коммерции

    Проблемы безопасности и целостности транзакций и
    невозможность их обеспечения с помощью стандартных протоколов.
    Лавинный рост сложности создаваемых приложений. Миграция корпоративных
    приложений к технологии Intranet. Кризис жанра.

    Современные задачи администрирования баз данных Oracle

    А. Бачин, ИВЦ
    АИС (Москва)

    Мне представляется, что с появлением Pesonal Oracle
    и Oracle7 Workgroup Server существенно меняются взгляды на вопросы
    и задачи администрирования баз данных Oracle. С одной стороны,
    как в старые добрые времена Oracle5 под управлением MS-DOS, конечный
    пользователь Pesonal Oracle снова становится владельцем базы данных
    в целом с возложением на себя всей ответственности администрирования.
    С другой стороны, в персональных и небольших групповых системах
    функции "классического" администрирования значительно
    упростились. Этому способствует повышение надежности вычислительных
    средств, их производительности, резкое увеличение емкости дисков.
    Так что не будет большим преувеличением сказать, что:

    а) пользователь Pesonal Oracle (группа пользователей
    Oracle7 Workgroup Server) не вырабатывает всей производительности
    вычислительной установки;

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

    Поэтому классические задачи администрирования базы
    данных Oracle: настойка производительности и реализация плановых
    процедур резервирования и восстановления как бы уходят в тень.
    Если к этому еще добавить наличие дружественных графических интерфейсов
    основных административных функций (включая мониторинг и дефрагментацию)
    под различными Windows'ами, то может создаться впечатление об
    уходе профессии администратора базы данных (АБД) Oracle, как таковой.

    Но позволю себе высказать как бы афоризм: "Сотня
    домашних кошек не заменят одного тигра (в джунглях) и - наоборот."
    Не кажется ли Вам, что в настоящее время мы поднялись на определенный
    уровень развития, и необходимо немного оглядеться и хорошенько
    на нем освоиться перед штурмом следующих вершин. И если во многих,
    особенно в только начинающих развиваться, малых и средних системах
    баз данных еще какое-то время можно остаться на уровне "классического"

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

    Можно с уверенностью сказать, что в настоящее время
    определился квалификационный уровень знаний по системе Oracle
    , на котором базируются различные с ней связанные специальности.
    Такой квалификацией, на мой взгляд, является понимание архитектуры
    взаимодействия ресурсов: собственно пользователей, их информационных
    объектов, распределения дисковой памяти, деятельности процессов
    Oracle в операционной среде. Это - как бы общий язык, на котором
    должны общаться все имеющие отношение к Oracle. (Важно повторить,
    что этот язык универсален, не зависит от платформы. Конкретные
    особенности платформ имеют значение только для АБД.)

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

    "Ниже" этого уровня - специалисты-потребители
    информации и различного рода операторы, работающие с готовыми
    приложениями и полностью сопровождаемые разработчиками, администраторами,
    системными интеграторами.

    "В бок" - разработчики приложений, архитекторы
    и администраторы данных (по систематизации Т.Кокса ), поскольку
    у них имеются собственные функции и задачи, наборы инструментария,
    а также свое собственное место в жизненном цикле базы данных.
    Необходимо их тесное взаимодействие с АБД в процессах привязки
    проектов и приложений к реалиям среды конкретной базы данных.
    Возрастание количества внедренных в информационной системе приложений
    вызывает качественные изменения во внутренней структуре конкретной
    базы данных (советую обратиться к статье М.Гохмана ).

    "В другую сторону" - собственно администраторы


    баз данных Oracle, для которых основными задачами становятся все
    более углубленное изучение как архитектуры и новых возможностей
    системы Oracle, консультирование пользователей всех уровней по
    этим вопросам, так и участие в проектировании распределенной базы
    данных, а также управление общими для системы ресурсами, распределенными
    транзакциями, связями баз данных, дополнительными процессами в
    операционной среде, параллельными экземплярами Oracle, ... Начало
    же должно быть вполне классическим - "20 заповедей начинающего
    Администратора Базы Данных" . (И эти классические задачи,
    наверно, всегда будут с нами!)

    Таким образом, по моему мнению, на нашем отечественном
    уровне развития современными задачами администрирования баз данных
    Oracle являются:

  • углубленное изучение функционирования,
    динамической производительности базы данных ;
  • построение корпоративной (общей для многих пользователей)
    базы данных, которая является вместилищем вновь внедряемых в информационную
    систему приложений;
  • управление многими десятками и сотнями прописанных
    в базе пользователей, определение их полномочий, ограничений,
    ролей (см. также );
  • построение эффективных систем обеспечения безопасности,
    разграничения доступа, регистрации и прослеживания (audit) событий
    данных;
  • освоение опций параллельных запросов и параллельных
    серверов;
  • сопровождение распределенных (различного уровня)
    баз данных, начиная с динамики пульсирования журналов моментальных
    копий (snapshot log) до мониторинга и восстановления распределенных
    транзакций;
  • подготовка к созданию и сопровождению баз данных
    очень большого объема (VLDB).

    Большинство из перечисленных задач так или иначе
    связаны с сетевой проблематикой. И это не случайно. Опять же по
    моему мнению, следующий уровень административной деятельности
    будут составлять управление многопротокольными преобразователями,
    web- и multimedia- серверами, серверами data warehouse, что без
    освоения сегодняшнего сетевого уровня сделать будет очень затруднительно.

    А впереди Oracle8! При заявленной гарантии переносимости
    всех проблемных разработок что он с собой принесет АБД, сейчас,
    наверно, никто не скажет.
    Литература

    1. Steven M. Bobrowski "Mastering Oracle7 &
    Client/Server Computing", SYBEX, San Francisco, 1994; русский
    перевод - С.Бобровски "Oracle7 и вычисления клиент-сервер",
    "ЛОРИ", 1995).

    2. Tom Cox "Some Thoughts on Data Administrators,
    DBAs, and Data Architects", ORACLE INTEGRATOR, vol.7, No.2,
    march/april 1996; русский перевод - "ORACLE MAGAZINE/РУССКОЕ
    ИЗДАНИЕ", вып. 1, лето 1996)

    3. Mark Gokman "Data: To Share Or Not To Share",
    SELECT, vol.3, No.2, january 96; русский перевод - "Мир
    Oracle", вып. 4, 1996)

    4. Richard J. Niemiec "20 Tips for the bigining
    DBA", SELECT, vol. 2, No 4, July 95; русский перевод - "Мир
    Oracle", вып. 7, 1995)

    5. Dave Ensor "Getting information rather than
    data from V$ objects" (BMC Software. Доклад на конференции
    EOUG-96; русский перевод - "Мир Oracle", вып. 4, 1996)

    6. Kevin M. Loney "System-Level Roles in ORACLE7.
    Going Beyond CONNECT, RESOURCE, and DBA", ORACLE MAGAZINE,
    summer 1994; русский перевод - "Мир Oracle", вып. 3,
    1995)

    []
    []
    []

    Sybase SQL Anywhere Professional

    А. Чернышев, Алконсофт

    Содержание доклада

  • Sybase SQL Anywhere Professional 5.5 общий обзор

    Состав. Исторические корни. Назначение. Возможности. Характеристики. Ниша Sybase SQL Anywhere на рынке.

  • Собственно SQL сервер

    Устройство. Варианты конфигурации.

    Характеристики и возможности.

    Совместимость. Мобильность. Переносимость. Ограничения формальные и реальные. Быстродействие и оптимизация.

    Практическое использование и замеченные недостатки

    Интерфейсы со средствами разработки приложений. Использование Sybase SQL Anywhere для персональной работы и как сервера рабочей группы. Использование Sybase SQL Anywhere в филиалах при использовании в центральном офисе более мощного SQL сервера. Использование Sybase SQL Anywhere при разработке тиражируемых решений. Использование Sybase SQL Anywhere для дистрибуции БД на CD.

  • Репликация данных в Sybase SQL Anywhere

    Когда и зачем требуется репликация данных.

    Организация подписки

    Возможные схемы репликации

    Репликация между двумя серверами SQL Anywhere. Репликация в 'большой' Sybase.

    Состав компонент для репликации данных.

  • Доступ к данным из Internet, организация Web-узлов

    Компонент NetImpact Dynamo?.

    Назначение. Схема работы. Использование.

  • Утилиты администрирования Sybase SQL Anywhere

    Краткие сведения о Sybase SQL Anywhere Professional 5.5

    Sybase SQL Anywhere является дальнейшим развитием линии SQL-СУБД Watcom.

    Sybase SQL Anywhere - полноценная SQL СУБД, работающая как в технологии клиент-сервер, так и в локальном варианте. Обеспечивает полную поддержку механизма транзакций, ANSI стандарта SQL89 уровня 2 и IBM SAA стандарта. Sybase SQL Anywhere поддерживает также entry level SQL92. Полностью реализованы механизмы декларативной ссылочной целостности с каскадированием, механизмы триггеров и хранимых процедур.

    Sybase SQL Anywhere отличает, наряду с простотой изучения и использования, наличие масштабируемости в широком диапазоне, что делает данную СУБД пригодной для использования как небольшими, так и значительными по числу одновременно работающих пользователей рабочими группами.
    Небольшой объем занимаемой памяти, легкость установки и администрирования позволяет использовать Sybase SQL Anywhere не только в качестве сервера БД, но и на локальном рабочем месте, а также на переносных компьютерах (notebook). Вместе с тем Sybase SQL Anywhere содержит мощный оптимизатор запросов, обеспечивающий высокую скорость доступа к данным при минимальном количестве обращений к диску.

    Sybase SQL Anywhere имеет в своем составе ?runtime? компоненты для дистрибуции баз данных в составе информационно-поисковых систем. Поставляемая база данных может быть сжата (в 2-2.5 раза) и расположена на CD. Расположенная на CD БД может быть использована для доступа только на чтение. Для выполнения операций записи SQL Anywhere создает отдельный файл (на доступном для записи носителе) для сохранения изменений сжатой БД.

    База данных - Sybase SQL Anywhere специально спроектирована для PC платформы и представляет собой настоящее 32-х разрядное приложение, оптимизированное для процессоров Intel 486 и Pentium архитектуры, при обеспечении совместимости с более старыми 386 процессорами. Sybase SQL Anywhere легко переносима и работает под управлением DOS, Windows 3.х, Windows 95, Windows NT, OS/2 и Novell NetWare, причем файлы базы данных переносятся из одной системы в другую без дополнительной обработки (т.е. просто как файлы без процесса экспорта/импорта или копирования/восстановления). Sybase SQL Anywhere поддерживает полный набор журналов транзакций, обеспечивающих автоматический процесс восстановления и отката. Используя эти журналы и специальную встроенную компоненту - SQL Remote?, можно асинхронно тиражировать (реплицировать) изменения данных между установками, например посредством электронной почты. SQL Remote? использует стандартное API к средствам электронной почты (Microsoft MAPI, Lotus VIM and Internet SMTP/POP) и позволяет автоматически синхронизировать данные удаленных пользователей с заданной частотой. Sybase SQL Anywhere совместим с Sybase SQL Server'ом и посредством поставляемого отдельно Replication Agent'а и Open Server'а Sybase может быть включен в архитектуру репликационного сервера Sybase, что позволяет тиражировать данные в Sybase, Oracle и DB/2.


    Поддерживается тиражирование всех типов данных включая BLOB.

    Помимо этого Sybase SQL Anywhere по языку совместим с Sybase Transact-SQLR и поддерживает работу Sybase Open Client через Sybase Open Server. Это позволяет строить масштабируемые в широком диапазоне приложения, одинаково работающие и с Sybase SQL Anywhere на переносном компьютере, и с мощным Sybase SQL Server'ом в локальной сети организации.

    Sybase SQL Anywhere облегчает создание высокопроизводительных приложений. Для этого поддерживаются курсоры с двунаправленным движением по выборке и возможностью обновления данных. Наличие типов данных ?BLOB?, позволяет использовать СУБД Sybase SQL Anywhere в системах мультимедиа.

    Прилагаемые ODBC драйверы высокоэффективны и поддерживают весь спектр возможностей СУБД. Кроме того, имеется возможность интегрировать базу данных и desktop-приложения Windows посредством интерфейса DDE и динамически подключаемых библиотек DLL.
    Управление (администрирование) БД в Sybase SQL Anywhere выполняется в мощной и удобной графической оболочке - SQLCentral позволяющей управлять созданием и удалением таблиц, индексов, процедур и т.д. в технологии drag-drop. В состав версии Sybase SQL Anywhere Professional 5.5 входит широко известный инструмент построения отчетов и форм InfoMaker?.

    В версии Sybase SQL Anywhere Professional 5.5 также имеются средства создания Web-узлов с динамическим доступом к БД. NetImpact Dynamo? (так называется этот продукт) позволяет строить шаблоны HTML страниц содержащих встроенные SQL запросы и фрагменты программ обрабатывающих результаты. Язык описания полностью совместим с JavaScript.

    Техническая спецификация

    Требования к аппаратной части

    Требования клиентской части: IBM PC совместимый компьютер, с необязательным, но желательным наличием устройства CD-ROM, работающий под управлением DOS версии 3.3 и выше, Windows 3.1, Windows 95, Windows NT 3.x, или OS/2 2.x. и выше. Требования к серверу СУБД: IBM PC совместимый компьютер под управлением Windows 3.x, Windows 95, Windows NT 3.x, Novell NetWare ver. 3.11 и выше, или OS/2 ver. 2.x и выше с процессором 80386 или выше и с 8 MB RAM.

    Поддерживаемые платформы:

    Windows, Windows NT, Windows95, Novell NetWare, OS/2, DOS

    Требования к сети:

    NetBIOS , TCP/IP, или Novell NetWare IPX (клиент в DOS'е поддерживает только NetBIOS и IPX)

    Объемные характеристики базы данных (максимальные значения)

    размер базы данных..........................................12 TB

    таблиц в базе данных...................................32,767

    размер таблицы...........................................1024 GB

    строк в таблице..............................ограничено только размером таблицы

    колонок в таблице........................................999

    символов в имени колонки......................128

    колонок в сложном индексе..............................999

    индексов на таблицу.........................................32,767

    Типы данных

    binary..............................................32,767 байт

    long binary..................................2,147,483,647 байт

    character......................................32,767 символов

    long varchar............................2,147,483,647 символов

    integer..........................+/- 2,147,483,647 целочисленный рад

    small integer...........................+/- 32,767 целочисленный рад

    tiny int.............................между 0 и 255 включительно

    real................................4-байтовое число с плавающей точкой

    float, double.......................8-байтовое число с плавающей точкой

    decimal, numeric...................+/- 9.99 e+/254 десятичный ряд

    money.....................между +/- 9,999,999,999,999,999.9999

    small money...........................между +/- 9,999,999.9999

    date...........................................от 0000 до 9999 года

    timestamp, datetime, small datetime....с точностью до 1/1,000 секунды

    time...................................с точностью до 1/1,000 секунды

    bit...............................битовое значение колонки только 1 или 0 Факс: (095) 918-1380, 362-5138

    Email:

    []
    []
    []

    Time Series DataBlade

    Содержит типы данных: календарь и временной ряд
    Сложные данные, сохраняемые в каждый промежуток времени
    Больше 20 встроенных функций:

    Clip, project, running average, exponential
    smoothing, on balance volume, etc.
    Бoлее чем в 100 раз быстрее, чем в реляционной СУБД
    Возможности применения:

    управлениe рискaми финансовых портфелей

    регистрация показателей приборов

    покадровый анализ видео    		Time Series DataBlade



    Universal Server: два подхода


    Universal Server: два подхода
    Universal Server: два подхода
    Различные API связываются с множеством серверовЕдиный интерфейс с объединенным сервером данных



    Universal Server: Новые типы данных


    create table customer(
    		Universal Server: Новые типы данных
    ЖЖЖ cname

    caddress

    start_year

    location
    		varchar(30),

    varchar(40),

    int,

    point);
    create table order(
    orderID

    cname

    amount

    date

    PO_fax

    order_notes

    materials

    ship_location
    		 int,

    varchar(30),

    money,

    date,

    image,

    doc,

    setof(part_type),

    point);

    Pозничная торговля


    create table facility(
    		Universal Server: Новые типы данных
    ЖЖЖ fname

    faddress

    location
    		 varchar(30),

    addr_type,

    fac_loc_t);
    create table route(
    route

    description

    route_map

    route_notes

    route_pts
    		 varchar(20),

    varchar(100),

    GeoMap,

    doc,

    setof(fac_loc_t));

    Логистика/Транспорт



    create table facility(
    		Universal Server: Новые типы данных
    ЖЖЖ fname

    faddress

    location
    		 varchar(30),

    addr_type,

    fac_loc_t);
    create table component(
    comp_id

    description

    fname

    maint_sched

    comp_loc

    comp_notes

    schematic
    		 comp_id_t,

    varchar(100),

    varchar(30),

    TimeSeries,

    point,

    doc,

    largeObject);

    Промышленность

    Корпоративные базы данных - статьи

    Архитектура программного комплекса IFS

    Состав программного комплекса IFS
    Системы, входящие в состав комплекса IFS, имеют модульный принцип построения.
    Архитектура программного комплекса IFS

    Borland IB Data Base 5 - новые возможности и рамки реализации SQL

    Сергей Орлик, Borland

    Дмитрий Кузьменко, Epsylon Technologies
    Доклад состоит из двух частей. В первой части рассматривается новая архитектура и расширеные возможности сервера IB DataBase 5:
  • Архитектура SuperServer
  • Guardian process
  • Многоверсионность - архитектура множественных поколений записей
  • Сигнализаторы событий
  • BLOb и массивы
  • UDF (Users Defined Functions) - определяемые пользователем функции
  • InterClient - JDBC-доступ к базам IB DataBase
  • Поддерживаемые платформы, CASE-средства и среды разработки
    Вторая часть доклада посвящена аспектам реализации SQL (DDL и DML) в IB DataBase 5.0 и его соответствие стандарту ANSI SQL-92:
  • Доменная архитектура метаданных
  • Декларативная ссылочная целостность
  • Триггеры
  • Хранимые процедуры
  • Доступ к UDF из DML
  • Роли
  • Работа с BLOb и массивами
    Borland Russia

    Московский офис Borland International, Inc.

    тел. (095) 238-3611

    ,

    E-mail: Epsylon Technologies

    Тел.: (095) 913-5608

    | |

    DB2 Universal Database

    Николай Игнатович, IBM
    Универсальный сервер баз данных DB2 Universal Database - это масштабируемая объектно-реляционная система управления базами данных с интегрированной поддержкой мультимедиа и Web, работающая на от персональных компьютеров и серверов на процессорах Intel с операционными системами OS/2, Windows NT до Unix станций под управлением различных версий UNIX, от однопроцессорных систем до симметричных многопроцессорных систем (SMP) и систем с массовым параллелизмом (MPP) и кластерах. Возможности расширения, заключенные в ядре базы данных, позволяют DB2 сочетает в себе ориентацию на несколько ключевых современных технологий. Это прежде всего поддержка сложных объекто-ориентированных и мультимедийных типов данных, обеспечение доступа к данных через Internet, сложные преобразования и анализ данных вместе с обеспечением высокой надежности, производительности и масштабируемости в диапазоне от однопроцессорных систем до систем с массовым параллелизмом. Эволюция Объединение версий DB2 Common Server и Parallel Edition на базе единого кода позволяет DB2 Universal Database соединить в себе производительность систем обработки транзакций в режиме on-line, объектно-реляционные расширения, усовершенствованные средства оптимизации и богатый набор реляционных возможностей DB2 Common Server с возможностями параллельной обработки и кластеризации, высокой производительностью обработки запросов и поддержкой очень больших баз данных DB2 Parallel Edition. Internet: DB2 поддерживает хранимые процедуры Java и определяемые пользователем функции, что позволяет программистам Java превратиться в создателей приложений для баз данных без особых дополнительных усилий. То же самое можно сказать и о поддержке DB2 языка программирования BASIC. Кроме того, DB2 Universal Database поддерживает специфичные для Java средства взаимодействия JDBC, а также TCP/IP. Продукт IBM Net.Data предоставляет доступ к разнородным данным Internet и позволяет создавать устойчивые соединения между DB2 и броузерами Web, благодаря чему для подключения к DB2 и обмена данными можно использовать любой броузер Web на любой платформе.
    Все это позволяет сделать реальностью идею использования сетей Internet и intranet не только для публикации информации, но и для осуществления коммерческих операций. Благодаря IBM Net.Data* и встроенной поддержке Java Database Connectivity (JDBC) DB2 Universal Database обеспечивает безопасные соединения через Internet для осуществления электронных коммерческих операций в режиме реального времени. DB2 является основой сервера IBM Net.Commerce, который уже сейчас обрабатывает постоянно растущее количество электронных коммерческих операций через World Wide Web. Интеграция: Поддержка сложных типов данных, таких как изображения, видео, аудио и текст) полностью интегрирована с базой данных посредством определяемых пользователем функций и определяемых пользователем типов данных. Она включает в себя мощные функции контекстно-зависимого поиска. Кроме того, с помощью определяемых пользователем функций (UDF) и определяемых пользователем типов данных (UDT) заказчики имеют возможность создать собственную мощную среду обработки данных, что значительно упрощает разработку приложений. Объектно-реляционные расширения (Extenders), построенные на использовании UDF и UDF, а также на базе специализированных поисковых технологий, поддерживают готовое решения для включения в базы данных таких типов данных, как изображения, видео, аудио и текст. Помимо этого, DB2 специально разрабатывалась для работы в качестве составной части различных крупных решений, включая системы:
  • доступа к разнородным данным (которые предоставляют приложениям возможность работы с данными из различных источников, как если бы они находились в одной базе данных, независимо от производителей каждой из отдельных баз данных) с помощью DataJoiner
  • информационных хранилищ данных, создаваемых с использованием IBM Visual Warehouse
  • получения новых данных на основе имеющихся с помощью средств поддержки принятия решений Intelligent Miner и аналитических функций DB2 OLAP Server, Lotus Approach и Intelligent Decision Server.
    Помимо этого, DB2 Universal Database включает в себя встроенные функции для поддержки систем аналитической обработки в реальном времени (OLAP), такие, как индексы с побитовым отображением, поддержка схемы типа звезды и функции сложной агрегации ROLLUP и CUBE. Интеграция Возможности полной интеграции всех ресурсов данных предприятия в DB2 Universal Database значительно расширены за счет различных способов поддержки других членов семейства DB2 (DB2 for OS/390, OS/400, VSE и VM).


    Средства поддержки включают в себя более тесные коммуникационные функции (новая поддержка TCP/IP, новая поддержка DRDA AS, непосредственный клиентский доступ настольных систем через DDCS), возможности работы с Web (Net.Data) и связующее ПО middleware (поддержка системы-источника и системы-приемника при репликации данных, а также централизованные средства управления системами баз данных). По мере роста организации и увеличения количества пользователей базы данных, объема базы данных и числа обрабатываемых транзакций естественным выбором для миграции была DB2 for OS/390 - благодаря своей признанной мощности, масштабируемости и высокими показателями готовности. Открытость и поддержка стандартов: Длинный перечень стандартов, поддерживаемых DB2, включает стандарты для реляционных баз данных (X/Open CLI и XA, SQL92), стандарты распределенной обработки данных (ODBC, DRDA, DCE), стандарты взаимодействия различных платформ (TCP/IP), правительственные спецификации (FIPS 127, защита данных С2) и стандарты системного управления (SNMP). Поддерживаемые DB2 платформы включают: IBM OS/2, Microsoft Windows NT и Windows 95, IBM AIX, Hewlett-Packard HP-UX, Sun Solaris Operating Environment, SCO OpenServer, а также Siemens Nixdorf SINIX. Клиенты для DB2 реализованы для любой из вышеперечисленных платформ, а также для SGI и MacOS; кроме того, в роли клиента DB2 может быть использован любой популярный броузер Web. DB2 Universal Database выделяется своими возможностями поддержки широкого диапазона различных несобственных языков (например, Java, BASIC, COBOL, C++) в качестве языка для хранимых процедур и определяемых пользователями функций. DB2 поддерживает большое количество национальных языков, в том числе для русского языка поддерживаются несколько кодовых страниц. Если клиент базы данных использует кодовую страницу отличную от кодовой страницы Стоимость: Ценовая политика IBM в отношении представляется нестандартной с том смысле что стоимость DB2 находится на уровне программных продуктов для Intel, тогда как эта база данных способна работать не только на платформах Intel, но и UNIX.


    Кроме того, такие элементы, как средства взаимодействия с Web и поддержка объектно-реляционных данных мультимедиа, поставляются вместе с сервером базы данных бесплатно. В зависимости от конкретной конфигурации Вашей системы, стоимость решения DB2 Universal Database может оказаться почти в три раза меньше, чем аналогичное решение от Oracle или Informix, и почти в 2.5 раза меньше по сравнению с Sybase. Простота в использовании: Конфигурирование коммуникационных функций и функций сетевого взаимодействия было значительно упрощено, так же как и настройка оптимальной производительности базы данных. Помимо тесно интегрированных средств управления базами данных, контроля производительности и настройки приложений, в DB2 Universal Database был включен планировщик задач и навигатор/броузер, которые значительно облегчают жизнь администраторам баз данных. Хранимые процедуры, триггеры и определяемые пользователем функции DB2 способствуют коллективному и многократному использованию функций, что значительно упрощает работу разработчиков ориентированных на базы данных приложений. Показатели готовности: Множество расширений превращают DB2 Universal Database в решение с высокими показателями готовности, обеспечивающее круглосуточную работу приложений. Сюда входит поддержка кластеризации на широком спектре различных операционных систем для разделения и дублирования рабочей нагрузки, табличное пространство с фиксацией во времени (point-in-time tablespace), восстановление на уровне таблиц и быстрый перезапуск.
    IBM

    Николай Игнатович

    Тел.: (095) 940-2000 Факс (095) 940-2070

    | |

    Горячие технологии Oracle: обзор

    Михаил Елашкин, Oracle
    Архитектура сетевых вычислений - всеобъемлющая, открытая, основанная на использовании сетей архитектура, предлагающая очень простой путь интеграции трех сегодняшних ключевых вычислительных дисциплин в единую сетецентрическую среду.
  • надежность вычислений в архитектуре клиент/сервер
  • простота развертывания работ в Internet
  • расширяемость и возможность повторного использования распределенных объектов.
    Технологии клиент-сервер с которыми знакомо большинство пользователей Oracle строятся на основе двухуровневой модели клиент (приложение на клиенте) и сервер (СУБД). Возможен и вариант т.н. трехуровневой архитектуры, когда часть вычислений переносится на т.н. сервер приложений. Проблема заключается, что логика приложений разрабатывается для каждого уровня самостоятельно и на разных языках. Поэтому если развитие информационной системы требует перераспределения тяжести вычислений (что часто происходит при развитии или масштабировании системы), то объем необходимых работ может быть весьма значительным. Oracle предлагает унифицировать все уровни за счет использования стандарта CORBA, который позволяет разрабатывать приложения на любом языке и снабдив их небольшим формальным описанием использовать где угодно. При этом понятие уровней архитектуры исчезает и мы получаем истинно сетевую вычислительную среду. При этом использование Java приобретает новый уровень, теперь Java не только язык написания небольших аплетов для украшения web страниц, а мощный переносимый язык для разработки серверных приложений и БД. Несомненно, новая парадигма требует соответствующих средств разработки одним из которых является использование Java. Oracle представляет свои новейшие разработки: Designer2000, Developer2000, AppBuilder и др. которые будут представлены в докладе. Несмотря на медленное начало некоторые нереляционные расширения СУБД находят своего потребителя. В первую очередь это относится к OLAP спрос на который растет намного быстрее возможностей Oracle СНГ по его представлению на рынке. Серьезный интерес проявляется также к полнотекстовым БД (ConText Cartridge) особенно после выхода русского приложения Russian Context Optimizer от компании Гарант Парк. Наблюдается также устойчивый рост интереса к приложениям ГИС на основе Spatial Data Cartridge, системам электронной коммерции и internet/intranet приложениям. Тенденции российского рынка говорят о том, что доля высоких технологий в нем неуклонно возрастает и компании желающие удержаться на гребне волны должны вкладывать деньги в новые технологии. Oracle

    Михаил Елашкин

    Тел.: (095) 258-4180 Факс (095) 258-4190

    E-mail:

    | |

    IFS: Примеры установок

    В настоящее время инсталлировано более 600 вариантов комплекса в различных отраслях. Это машиностроение (в том числе автомобилестроение и самолетостроение), бумажная и деревообрабатывающая промышленность, металлургия, электротехника, химия, а также фармацевтическая и пищевая промышленность. Особое место комплекс IFS занял в энергетике (как на электростанциях, так и в распределительных сетях), особенно после завершения в 1993 году разработки версии, специально предназначенной для предприятий энергетики. В этом же году начались поставки для атомных электростанций. IFS является интернациональной корпорацией, имеющей представительства в более, чем 20 странах мира. Наибольшее распространение комплекс приобрел в скандинавских странах, Японии, США. Программы IFS используются в Великобритании, Германии, Турции, Малайзии, Сингапуре, Индонезии и других странах. IFS работает в таких крупнейших, известных всему миру компаниях, как Nikon, Caterpillar, Allied Signal, Kawasaki, Volvo, NEC, Mazda, Mitsubisi, IBM, Yamaha, Hyndai, TDK, Sharp, Pharmacia&Upjohn, Casio, IKEA, SAS, Saab-Scania, Ericsson, ABB, Becker. Международное распространение IFS началось со стран Скандинавии, прежде всего с Норвегии, где первые инсталляции системы были сделаны еще в 1986 г. Сейчас система работает в этой стране в нефтедобывающей, кабельной промышленности, на норвежских атомных электростанциях, в сети сотовой связи. Получение большого заказа от Норвежской государственной железной дороги позволило компании совместно с норвежскими специалистами разработать специальную систему на базе IFS - систему IRMA, предназначенную для управления эксплуатацией подвижного состава железных дорог. На рынке стран Восточной Европы первые поставки системы были сделаны в Польше, а особенный успех, который имели инсталляции на крупных тепловых электростанциях Польши, привел к открытию в этой стране постоянного представительства компании. Cейчас число установок IFS в Польше приближается к двадцати. Внедрения IFS в России начались с 1994 года. ФОРС - официальный дистрибутор корпорации IFS в России Продажи, установки, адаптацию и внедрение комплекса IFS в России выполняет НПВП ФОРС. НПВП ФОРС

    Тел.: (095)973-40-67, 973-40-80, 973-40-81, 973-40-82

    Факс: (095)251-1073

    | |

    Иллюстрации




































  • Software AG (Московское представительство)

    125080, Москва, ул.Сурикова, 24

    Телефон: +7-095-158-9930

    Факс: +7-095-198-8661

    E-mail:

    | |

    Энергетика, промышленность, транспорт, торговля. Программный комплекс IFS

    Дмитрий Шехватов, НПВП ФОРС
    Право, такое затруднение - выбор . . .
    Н. В. Гоголь
    Сегодня многие предприятия приводят свои системы управления в соответствие новым хозяйственным отношениям. Возрастает интерес к законченным комплексным автоматизированным системам, благодаря которым информация о деятельности предприятия - производстве, закупках, сбыте, складах, бухгалтерии, финансовом планировании, эксплуатации оборудования - сразу же после ввода становится доступной для руководителей и специалистов.
    Опыт западных фирм показывает, что интегрированная система управления предприятием, соответствующая реальным рыночным отношениям, может быть построена только на основе целого комплекса современных информационных технологий: аппаратных, программных и телекоммуникационных.
    Понимая это, многие предприятия считают достаточным приобрести современную технику и мощную СУБД (такую, как ORACLE), а прикладную систему разработать своими силами.
    Не отрицая достоинств этого подхода, стоит заметить, что создание таких интегрированных систем управления заняло у крупных западных фирм 5-7 лет, а около половины подобных проектов потерпели неудачу.
    Выгодней оказывается адаптировать готовую систему. Предприятия, выбравшие такой путь, начинают значительно быстрее получать отдачу от своих вложений.
    В последнее время на российском рынке появился целый ряд зарубежных систем управления предприятием. Найти систему, наиболее полно отвечающую потребностям и возможностям конкретного предприятия, достаточно сложно. Наиболее важными критериями правильного выбора являются: функциональная полнота, надежность, технологичность, масштабируемость, модульность, возможность поэтапного внедрения, соответствие стандартам, открытость, простота локализации и объединения с другими программными комплексами, наличие исходных текстов, гибкость ценовой политики, примеры успешного внедрения на сходных производствах. К этому нужно добавить круг вопросов, связанных с внедрением и поддержкой: поставка новых версий программного обеспечения и документации, установка и адаптация системы, обучение персонала, консультации.

    И если на все вопросы получены положительные ответы - эту систему можно рассматривать как серьезную альтернативу всем другим.
    Мы уверены, что интегрированный программный комплекс управления предприятием IFS класса MRP II, разработанный шведской компанией Industrial and Financial Systems, и тот набор услуг по его внедрению и сопровождению, который предлагает предприятие ФОРС, удовлетворят самых взыскательных клиентов.
    Свойства программного комплекса IFS
    Полнота набора функций
    IFS     - это функционально полный, открытый комплекс для управления предприятием, имеющий модульную архитектуру. Набор модулей, входящих в состав комплекса, - результат четырнадцатилетней работы по созданию, внедрению и эксплуатации IFS в различных отраслях промышленности и торговли разных стран, показатель степени зрелости системы. Функции, реализованные в программном комплексе, охватывают все основные сферы деятельности современного предприятия и позволяют решать весь объем задач, возникающих в процессе управления.
    Программный комплекс поддерживает следующие сферы управления предприятием:
  • управление финансами,
  • управление поставками и сбытом,
  • управление производством,
  • управление персоналом и оборудованием,
  • управление планово-предупредительными ремонтами,
  • управление проектами.

    Модульность
    Комплекс построен как набор взаимосвязанных, но достаточно независимых модулей. Это означает, что большинство модулей может функционировать автономно, независимо от других.
    Группы модулей образуют основные системы комплекса, поддерживающие различные сферы управления. Системы являются независимыми друг от друг и связаны, при совместном функционировании, только информационно.
    Выбор конкретного состава модулей определяется потребностью предприятия. Программный комплекс можно внедрять по модульно, причем на каждом шаге процесса, получая целостный законченный комплекс.
    Интегрированность
    Все системы комплекса информационно связаны между собой, реализуя принцип "однократный ввод - многократное использование".


    Все системы комплекса выполнены в едином стиле по единой идеологии, реализуя принцип концептуальной целостности.
    Все типовые автоматизированные рабочие места реализуют принцип функциональной полноты, обеспечивая своим пользователям доступ ко всем необходимым им функциям комплекса.
    Гибкость
    При создании комплекса учитывалось, что с ним будет работать большое число пользователей - как с ограниченным опытом, так и профессионалов. Поэтому IFS предоставляет средства для создания гибкой системы меню, учитывающей подготовленность пользователей, их потребности в информации и права доступа к данным. Функциональный, информационный и регламентно-правовой состав каждого автоматизированного рабочего места (АРМа) определяется для каждого предприятия индивидуально, при внедрении комплекса.
    Все учетные и вычислительные алгоритмы комплекса в высокой степени параметризованы, что позволяет настроить их в соответствии с конкретной спецификой документооборота, учета и управления, существующей на предприятии.
    Надежность
    Программный комплекс IFS реализован на основе СУБД ORACLE и наследует от нее широко известную надежность по поддержке целостности базы данных и защите от несанкционированного доступа.
    Легкость доступа к информации в комплексе сочетается с надежной ее защитой. Постоянное изменение данных большим числом пользователей системы не влечет за собой неправильного и несанкционированного информационного использования системы. Она не только сообщает пользователю об ошибках, но и обеспечивает определенную степень защиты от них.
    С помощью средств администрирования определяется область допустимых значений для вводимых данных, осуществляется привязка определяемых полей к ранее введенным ограничениям. Этим не только достигается однократность регистрации данных, но и блокируется ввод недопустимых значений.
    Интероперабельность
    Клиентская часть программного комплекса IFS имеет графический интерфейс и работает на всех программно-аппаратных конфигурациях рабочих станций, поддерживающих или эмулирующих MS Windows.


    Имеется реализация клиентской части, работающая не только в среде "клиент-сервер", но и в терминальной конфигурации на практически любых алфавитно-символьных терминалах.
    Серверная часть программного комплекса IFS реализована средствами СУБД ORACLE Enterprise Server и работает везде, где работает СУБД ORACLE, а это более 60 платформ.
    Связь между клиентом и сервером осуществляется на основе ORACLE SQL*Net, а это означает устойчивую работу в гетерогенных сетях на практически любом стеке транспортных протоколов.
    Открытость
    Программный комплекс IFS обеспечивает непревзойденную степень открытости для адаптации, изменений, развития. Это обеспечивается за счет вхождения в комплект поставки:
  • полного комплекта функциональных моделей комплекса,
  • полного комплекта информационных моделей (диаграмм сущность-связь),
  • полного набора исходных текстов комплекса.
    Идеология системы принципиально ориентирована на открытость - возможность быстрого и эффективного внесения изменений. При проектировании и разработке комплекса использовались современные объектно-ориентированные технологии, широко применялись CASE-средства и средства визуальной разработки.
    В состав комплекса входит специальная служебная система, при помощи которой всю интерфейсную часть комплекса - термины, формы ввода данных, отчетную информацию, сообщения-подсказки, сообщения об ошибках - можно формировать на национальном языке. Переход с одного языка общения с комплексом на другой возможен непосредственно в пользовательском сеансе. Возможна одновременная работа разных пользователей на разных языках.
    Структура программного комплекса IFS
    Программный комплекс IFS разработан в современной, но не усложненной архитектуре. Архитектура комплекса соответствует трехуровневой модели клиент-сервер. Это позволяет четко отделить уровень представления, уровень логики и уровень данных друг от друга.
    Энергетика, промышленность, транспорт, торговля. Программный комплекс IFS

    Материалы 3-ей ежегодной конференции "Корпоративные базы данных'98"



  • Алексей Шуленин, Microsoft


  • Михаил Елашкин, Oracle


  • Дмитрий Шехватов, Нпвп Форс


  • С. Маклаков, Д.Матвеев, Интерфейс Ltd


  • Константин Лисянский, Дмитрий Слободяников, NCR


  • Сергей Орлик, Borland Дмитрий Кузьменко, Epsylon Technologies


  • Сергей Кузнецов, Computer Associates


  • Николай Игнатович, IBM


  • Кирилл Лисовский, IBM


  • Ольга Китова, Software AG


  • Ховард Залкин, Informix


  • Алексей Тимонин, Sybase


  • Ольга Твердова, CSBI EE


  • Илья Гусев, ТЕРН


  • Сергей Кузнецов, Центр Информационных Технологий, Валерий Артемьев, ГЦИ ЦБ РФ


  • С. Д. Коровкин, И. А. Левенец, И. Д. Ратманова, В. А. Старых, Л. В. Щавелёв




  • Новые технологии компании Sybase

    Алексей Тимонин, Sybase
    Ключевые моменты развития технологии Sybase     Для компании Sybase 1998 год является особенным. Прежде всего, сейчас корпорация обладает наиболее широким кругом программных продуктов и технологий за всю свою историю. Кроме того, для всех программных продуктов корпорации в течении последнего года были выпущены новые версии (а для некоторых - даже несколько версий), включая все СУБД, технологии репликации и доступа к данным, технологии для создания прикладных серверов, а также инструменты разработки и проектирования. Еще важнее то, что изменения происходят в рамках объявленной в весной 1997 года, единой стратегии развития технологии - Адаптивной Компонентной Архитектуры Sybase. Интересно отметить, что новая стратегия является логическим продолжением базового набора технологических решений, впервые появившихся в конце восьмидесятых годов. С самого начала своей деятельности на рынке информационных технологий (с 1988 года), корпорация Sybase сразу позиционировала себя как производителя набора технологий для создания распределенных гетерогенных информационных систем. В базовый набор технологий Sybase, которые принесли компании успех и известность на рынке в течении последующих десяти лет, входят как рад технологий реляционных СУБД, так и различные технологии интеграции для обмена данными и транзакциями между разнородными СУБД и другими (в общем случае, произвольными) источниками данных. Среди технологий интеграции, необходимо упомянуть набор открытых интерфейсов Sybase Open Client/Open Server, которые были впервые выпущены в 1988 году. В сущности, именно эти интерфейсы легли в основу всех существующих программных продуктов Sybase. Оригинальность подхода в наборе интерфейсов Open Client/Open Server состояла в том, что многие положения архитектуры "клиент-сервер" были впервые воплощены в области архитектуры СУБД. Библиотека Open Client (раннее название - DB-Library) реализует функции произвольной программы-"клиента": сформировать запрос, послать его на обработку, обработать результаты и воспроизвести их на клиентской машине.
    Запрос на обработку может быть произведен двумя способами: либо передачей текстового буфера, либо с помощью функций вызова удаленной хранимой процедуры. Библиотека Open Server, в свою очередь, реализует все необходимые функции произвольной программы-"сервера": перехват событий "подключение клиента", "отключение клиента", "приход текстового буфера", "вызов удаленной хранимой процедуры" и других. Кроме того, любая серверная программа, использующая Open Server, сразу является "многопоточной" (multithreading), т.е. при ее запуске создается один процесс операционной системы, а все клиентские подключения происходят в рамках этого же "серверного" процесса, где каждое клиентское подключение представляют собой один поток (thread). Управление же потоками, их переключение, синхронизация и прочее, уже встроено в Open Server на системном уровне. Многопоточность является важным свойством для серверной программы, потому что создание одного потока в рамках одно процесса операционной системы требует на порядок меньше ресурсов, чем создание еще одного процесса. Программы на основе Open Client и Open Server общаются между собой с помощью высокоуровнего протокола обмена данными под названием TDS (Tabular Data Stream - Табличный Поток Данных), который, как следует из названия, оптимизирован на передачу табличных данных. Уровень передачи данных является полностью независимым от сетевых протоколов передачи данных, поэтому клиентская программа может общаться с любым сервером используя распространенные транспортные протоколы (SPX/IPX, TCP/IP, DECNet, AppleTalk и другие). Также, интересной особенностью этих интерфейсов является возможность реализации асинхронного взаимодействия клиентской и серверных программ, когда прикладное серверное приложение имеет возможность вызывать процедуры на клиентской программе ("активный прикладной сервер"). В результате, клиентское приложение получило возможность не ждать окончания обработки на сервере для продолжения своей работы. На основе Open Server и была создана СУБД Sybase SQL Server, которая обладала целым рядом важных особенностей.


    SQL Server воплощал в себе подход "интеллектуальной" СУБД, которая на просто хранит данные, а также позволяет хранить прикладные правила хранения данных и прикладные алгоритмы обработки этих данных. Задачей, на которую нацеливался SQL Server, являлась быстрая обработка операций по вводу и модификации данных большим количеством пользователей. Благодаря тому, что в основе лежит Open Server, SQL Server сразу стал многопоточным. Следствием этого явилось небольшое количество памяти, необходимой для поддержки одного клиентского соединения - около 60-70К. Централизованное хранение, изменение и дополнение прикладной логики реализуется с помощью хранимых процедур, триггеров, правил (rules), значений по умолчанию (defaults). Таким образом, если не будут изменены аргументы хранимых процедур или их названия, клиентские программы никогда не узнают, что на сервере произошли какие-то изменения. Кроме того, сервер СУБД оказался не привязанным к типу клиентского приложения, благодаря тому, что, например, все правила, связанные с проверкой новых значений перед их вставкой в таблицу хранятся на самом сервере, а не встроены в код клиентской программы. Это серьезно повышает переносимость клиентских программ и повышает общую безопасность системы в целом. Кроме того, на основе Open Client/Open Server созданы различные прикладные сервера, выполняющие разнообразные функции в распределенной информационно системе: специализированный сервер для резервного сохранения и восстановления данных Backup Server, специализированный сервер для тиражирования данных Replication Server, специализированный сервер для объединения разнородных баз данных в логически единую базу - Sybase OmniCONNECT и ряд других. Все эти сервера используют единый интерфейс доступа (Open Client) и могут взаимодействовать друг с другом (с помощью вызовов удаленных хранимых процедур) независимо от аппаратной платформы и сетевого протокола. Разумеется, что разработчики информационных систем имеют возможность создавать свои собственные прикладные сервера для решения конкретных задач (например, сложных вычислений, реализации специфических алгоритмов шифрования и аутентификации, организации доступа к каким-либо датчикам или установкам и т.д.), доступ к которым осуществляется с помощью единого протокола обмена данными. С выпуском в 1993 году первой версии сервера репликации транзакций Sybase Replication Server, компания серьезно укрепила свою репутацию поставщика технологий для создания распределенных систем.


    Это произошло благодаря тому, что это была первая реализаций технологии репликации транзакций (с сохранением их целостности при их передаче через ненадежные или низкоскоростные линии связи) для СУБД, которая основывалась на чтении изменений из журнала транзакций и последующей их записью в очередь, при проблемах с линией связи. Кроме того, особенностью Replication Server, которая часто привлекает внимание разработчиков, является возможность использования в качестве источника данных для репликации не только любые СУБД Sybase, но и СУБД других известных производителей, включая Oracle или DB2/400 for AS/400. Это реализуется с помощью дополнительных репликационных агентов для соответствующей СУБД. Взгляд Sybase на разработку и развитие современных информационных систем Изменения, повсеместно происходящие в информационных технологиях, приводят к появлению новых возможностей и новых задач. Работа компаний и организаций в условиях увеличивающейся конкуренцией становиться все более и более зависящей от обработки больших объемов разнородной информации. Адаптивная Компонентная Архитектура связывает в единое целое все программные продукты Sybase и обеспечивает возможность создания современных законченных решений для информационных систем любой сложности. Эта комплексная архитектура, составной частью которой является СУБД Adaptive Server, предназначена для:
  • Помощи специалистам по информационным технологиям в решении растущего количества сложных задач, связанных с созданием промышленных информационных систем и приложений
  • Получения реальной отдачи от использования новых технологий в управлении, обеспечении целостности, безопасности и высокой производительности существующих информационных систем
  • Создании гибкой информационной архитектуры, открытой и самостоятельно адаптирующейся к изменениям
    Заложенные в Адаптивную Компонентную Архитектуру принципы адаптации приложений к существующим условиям работы делают ее наиболее гибким и надежным решением для построения систем управления базами данных на сегодняшнем рынке программного обеспечения.


    Основой такой гибкости является идеология повторного использования программных компонент. Создавая программные компоненты в виде законченных программных "блоков", вы можете быстро разрабатывать отлаженные приложения, а компоненты могут быть использованы на любом из трех уровней Адаптивной Компонентной Архитектуры - клиентском, промежуточном (прикладном) или уровне СУБД. Компоненты, используемые в Адаптивной Компонентной Архитектуре, разделяются на два вида - компоненты, (1) содержащие логику приложений и (2) данные. Эти два типа компонент могут быть представлены в следующим виде:
  • Средства разработки приложений генерируют стандартные компоненты для моделей ActiveX, CORBA и JavaBeans, что позволяет использовать открытую компонентную логику на всех уровнях системы.
  • Общий язык и средства управления позволяют выбирать подходящий оптимизированный компонент хранения данных, а, в случае необходимости, добавлять дополнительные компоненты управления данными.
    Три уровня Адаптивной Компонентной Архитектуры Sybase показаны на Рис.1. Компоненты, содержащие логику приложения и данные, могут быть размещены на любом уровне. На серверном уровне расположена СУБД Adaptive Server, которая включает в себя компоненты обработки данных Sybase - Adaptive Server Enterprise, Adaptive Server Anywhere и Adaptive Server IQ, а также компоненты для обработки сложных типов данных (текст, графические образы и другая неструктурированная информация). Новые технологии компании Sybase
    Рис.1. Адаптивная Компонентная Архитектура
    Архитектура СУБД Adaptive Server Архитектура СУБД Adaptive Server позволяет совместно использовать один или несколько компонентов обработки данных (в зависимости от специфики решаемой задачи). При этом, Adaptive Server будет поддерживать все операции с этими компонентами обработки данных, обеспечивая при этом единый интерфейс доступа (Open Client), единые языки (SQL и Java), единый инструмент администрирования (Sybase Central), а также, при необходимости, единые технологии по репликации транзакций (Replication Server, SQL Remote), обмену сообщениями (dbQueue), интеграции разнородных данных (OmniConnect), интеграцию с web-технологиями (Jaguar CTS и PowerDynamo). На Рис.2 изображены три составные части Adaptive Server:


  • Common Language Processor ( Единый синтаксический процессор) обеспечивает согласованный интерфейс обработки информации для всех источников данных. Программный уровень поддерживает как Transact-SQL(r), так и объекты Java для создания абстрактных типов данных на основе языка Java.
  • Component Integration Layer (Слой интеграции компонент) обеспечивает прозрачную обработку запросов для всех источников данных. Будущие версии Adaptive Server будут также поддерживать распределенное согласование транзакций.
  • Уровень оптимизированных источников обработки данных (optimized data stores) может включать в себя набор из различных компонентов обработки данных, каждый из которых ориентирован на обработку своих классов запросов.
    Новые технологии компании Sybase
    Рис.2. Архитектура Adaptive Server Компоненты обработки данных включают в себя:
  • Adaptive Server Enterprise, предназначенный для оперативной обработки транзакций (OLTP), систем поддержки принятия решений, а также для смешанной многопользовательской среды, в которой могут обрабатываться оба класса запросов. Основными особенностями этого продукта являются:
  • Управление приоритетами запросов (которые могут динамически меняться)
  • Продвинутая параллельная обработка как для операций обработки запросов, так и для различных системных операций, включая создание индексов, загрузку/выгрузку данных и т.д.
  • Управление лимитами ресурсов запроса (например, можно лимитировать максимальное время обработки запроса, максимально допустимое количество операций ввода/вывода или максимальное количество возвращаемых записей)
  • Продвинутое управление кэш-памятью, в результате чего, можно присваивать различные части кэш-памяти конкретным таблицам (или наборам таблиц), индексам, базам данных и т.д. Эта возможность серьезно повышает управляемость СУБД при одновременной работе многих пользователей.
    Версия Adaptive Server Enterprise, вышедшая в конце марта этого года поддерживает гибкую технологию управления блокировками, которая может происходить на уровне базы данных, таблицы, отдельной страницы таблицы или же на уровне записи.


  • Adaptive Server Anywhere для работы в мобильных и настольных системах. Adaptive Server Anywhere является преемником популярной СУБД Sybase SQL Anywhere, которая сегодня широко используется для создания информационных систем на уровне небольших рабочих групп или для объединения удаленных филиалов больших информационных систем. Популярность SQL Anywhere обеспечивают следующие ключевые особенности:
  • Поддержка все функций многопользовательской реляционной СУБД, включая поддержку транзакций, хранимых процедур, триггеров, декларативной целостности, блокировки на уровне записи и т.д.
  • Поддержка языка Sybase Transact-SQL
  • Поддержка нескольких технологии репликации - в режиме "онлайн" с помощью Replication Server, или по электронной почте, с помощью технологии SQL Remote. Важно, что с помощью обеих технологий есть возможность обмениваться транзакциями между Adaptive Server Anywhere, Adaptive Server Enterprise, предыдущих версий СУБД Sybase SQL Server, SQL Anywhere и т.д.
  • Низкие требования к оперативной памяти (самому серверу необходимо 2 MB)
  • Упрощенное сопровождение сервера (не требуется постоянное присутствие профессионального администратора БД, многие функции настраиваются автоматически)
  • Поддержка массовых операционных систем, включая DOS, Windows 3.x/95/NT, OS/2, NetWare, DOS, QNX, Macintosh, Sun Solaris, HP-UX, IBM AIX, SGI IRIX
    Дополнительно к этому, в версии Adaptive Server Anywhere 6.0, которая появляется весной этого года, будет добавлена поддержка языка Java и обеспечена поддержка многопроцессорных (SMP) систем. Кроме того, появиться поддержка новой операционной системы Windows CE (для этой платформы, требования к оперативной памяти снижены до 500K). Во второй половине года планируется выход специальной версии Adaptive Server Anywhere, которая будет полностью реализована на Java и предназначена для использования в качестве встраиваемой СУБД в различных мобильных устройствах (например, в мобильных телефонах).
  • Adaptive Server IQ представляет собой специализированный компонент предназначенный для производительной обработки сложных аналитических запросов на большом объеме данных.


    Благодаря запатентованным алгоритмам индексации данных, а также дополнительным алгоритмам хранения и сжатия данных, скорость обработки сложных запросов (которые часто состоят из различных операций объединения, агрегирования, сортировки) на Adaptive Server IQ происходит значительно быстрее, чем в обычных РСУБД (в среднем, в 5-10 раз, хотя иногда ускорение может достигать и ста раз). Дополнительно, важными особенностями этого компонента являются:
  • Поддержка языка Transact-SQL
  • Поддержка стандартных клиентских библиотек доступа Open Client, DB-Library и ODBC
  • Отсутствие жестких требований на используемую модель данных (разработчики не обязаны использовать только многомерную модель данных, например). Поддерживается обычная реляционная модель данных.
  • Возможность многопользовательской работы
  • Поддержка как различных Unix-платформ, так и Windows NT
  • Специальные компоненты управления данными для обработки неструктурированной информации, включая хранение и поиск по тексту (в том числе в форматах MS Word, Adobe Acrobat и др.), графические образы (хранение и поиск) и т.д.
    Новые возможности для разработки прикладных систем В рамках Адаптивной Компонентной Архитектуры компания Sybase разрабатывает технологию использования языка Java непосредственно в СУБД Adaptive Server. Это позволит существенно повысить открытость и продвинутость серверных программ, а также упростить внедрение и эксплуатацию прикладных систем, основывающихся на серверные программы. В тоже время, это позволит создать открытую объектно-ориентированную СУБД. Главной целью Java-инициативы компании Sybase является решение проблем, с которыми сталкиваются организации, применяющие информационные технологии Сегодня, прикладные программы состоят из кода, находящегося вне сервера СУБД и запрограммированного на языках третьего (C/C++, Java и другие) или четвертого поколений (PowerBuilder, Visual Basic и другие), а также из кода, находящегося в СУБД, в виде хранимых процедур, написанных на языке SQL. Java-инициатива компании Sybase, опираясь на принцип Java-программ ("написал один раз - работает везде "), переносит его действие на новую платформу - СУБД.


    Это позволит убрать различия между программированием клиентской и серверной частей прикладной системы. Особенности Java-инициатива компании Sybase открывает новые возможности для разработчиков прикладных систем.
  • Применение полноценного языка программирования в СУБД. Прикладной код (в виде Java-классов) будет исполняться в безопасном режиме в Adaptive Server. Для этого в Adaptive Server будет встроена виртуальная машина языка Java и внутренний интерфейс JDBC. При этом, благодаря встраиванию в сервер мощного и безопасного языка программирования, удается обойти программные ограничения хранимых процедур на языке SQL.
  • Объектные типы данных. Объекты, написанные на языке Java, могут храниться в виде значений в реляционной таблице. Это позволяет создавать и использовать произвольные типы данных.
  • Единая программная модель. Впервые прикладные программные компоненты можно будет перемещать между клиентскими программами, прикладными серверами и СУБД. На всех уровнях разработчики могут использовать единую программную модель.
    Открытость и поддержка стандартов
    Успех технологии Sybase является следствием приверженности компании к открытым стандартам. Использование языка Java в реляционной архитектуре позволит убрать барьеры при создании прикладных программ, однако новым препятствием может стать проблема стандартизации новой технологии. Компания Sybase, совместно с корпорацией JavaSoft, американским комитетом по стандартизации ANSI и консорциумом JSQL, работает над созданием стандартов по использованию языка Java в СУБД. Почему используется Java?
    Одной из важнейших целей компании Sybase является упрощение процесса разработки прикладных информационных систем предприятий, сложность которых постоянно возрастает. Мы уверены, что использование языка Java поможет достичь этой цели. Java представляет собой язык программирования для нового поколения прикладных информационных систем, который примечателен прежде всего благодаря повышению эффективности процесса разработки приложений. Компания Sybase убеждена, что язык Java позволит повысить эффективность разработки серверных приложений, а также расширить возможности серверов баз данных. Это убеждение основывается на следующих причинах:


  • Этот язык начинает широко применяться при разработке прикладных систем. Для уменьшения различий между разработкой клиентских и серверных приложений необходимо использовать единый язык программирования.
  • Этот язык имеет встроенные средства контроля безопасности исполнения программ. Язык, используемый в критически важных приложениях, которые обычно основываются на системах управления базами данных, должен иметь встроенную защиту для самой СУБД. Язык Java такую защиту обеспечивает.
  • Это объектно-ориентированный язык. Язык, который предназначен стать основой для новых объектных типов данных, должен быть объектно-ориенти-

    рованным. Java изначально проектировался как объектно-ориентированный язык.
    Компания Sybase видит два направления использования языка Java в СУБД:
  • В качестве языка программирования серверной прикладной логики, развивающий возможности традиционных SQL-ориентированных хранимых процедур.
  • В качестве средства описания и хранения объектных типов данных в СУБД.
    Следующие разделы посвящены обсуждению реализации этих двух направлений. Использование Java для программирования СУБД Современные сервера баз данных применяют SQL для достижения двух задач: доступа к данным и программирования прикладных алгоритмов. Язык SQL продолжает оставаться прекрасным языком для управления данными, однако хранимые процедуры, являющиеся расширениями языка SQL и предназначенные для программирования и хранения внутри сервера прикладного кода, имеют очевидные слабые места. Хранимые процедуры на SQL имеют очень ограниченный набор средств разработки и отладки, их невозможно вынести из сервера СУБД, а кроме того, в них отсутствует множество стандартных возможностей современных языков программирования, например использование внешних библиотек, механизмов инкапсуляции, наследования и других объектно-ориентированных особенностей. Язык Java является естественным решением для программирования прикладного кода внутри сервера СУБД. Язык SQL продолжает использоваться для доступа к данным и манипуляций над ними. Инсталляция классов в сервер Произвольная программа на Java состоит из набора классов.


    Для их использования в Adaptive Server будет необходимо провести инсталляцию Java-классов в СУБД. Классы должны быть откомпилированы в байт-код (и, тем самым, готовы для исполнения в виртуальной Java-машине) вне сервера. После инсталляции они могут исполняться (и могут быть отлажены) внутри сервера СУБД. Доступ к языку SQL из Java с помощью интерфейса JDBC Для обеспечения работы прикладного Java-кода в базе данных, необходимо обеспечить интерфейс доступа из Java к языку SQL. Совершенно аналогично тому, как операторы SQL доступны для вызова из обычных хранимых процедур, они должны быть доступны для вызова из методов, описанных на языке Java. На клиентской стороне, для включения языка SQL в Java-методы используется интерфейс JDBC. JDBC - это прикладной программный интерфейс, введенный в набор Java SDK версии 1.1.0, и предназначенный для включения операторов SQL в методы на Java. Для уменьшения различий между программированием клиентских и серверных приложений, необходимо обеспечить JDBC-доступ к SQL-операторам из методов на Java, изнутри СУБД. Именно поэтому внутренний интерфейс JDBC для Adaptive Server является ключевой особенностью Java-инициативы компании Sybase. Использование методов, упрощающих разработку под JDBC Также как ODBC, JDBC представляет собой низкоуровневый прикладной интерфейс для доступа к СУБД. Аналогично тому, как во многих средствах быстрой разработки приложений существуют собственные высокоуровневые интерфейсы, построенные на основе ODBC, существует необходимость в интерфейсах на основе JDBC, которые позволят разработчикам быть более эффективными. После того, как откомпилированные Java-классы будут инсталлированы в Adaptive Server, любые высокоуровневые инструменты и методы, генерирующие Java и JDBC-код, поддерживаются автоматически. В их числе:
  • JSQL. JSQL - это альтернативный метод включения SQL-вызовов в Java-код. Этот стандарт поддерживается консорциумом, включающий в себя компании IBM, Sybase, Oracle, Tandem.
  • По сути, JSQL реализует возможности, аналогичные возможностям встроенного SQL (Embedded SQL), но для JDBC.


    Во многих случаях писать на JSQL проще, чем непосредственно на JDBC. Дополнительным преимуществом для администраторов баз данных является сходство этого метода с написанием обычных хранимых процедур на SQL.
    Перед компиляцией, JSQL-код преобразуется препроцессором в вызовы SQL. Пользователи Adaptive Server смогут, при желании, использовать JSQL и встраивать обработанный препроцессором код в сервер СУБД.
  • RAD-инструменты Инструменты для быстрой разработки приложений (RAD-инструменты) для Java, включая инструмент Sybase PowerJ, используют Java-классы, созданные на основе вызовов JDBC, с целью обеспечения разработчиков более удобным интерфейсом. Такие классы также могут быть инсталлированы в СУБД.
  • JavaBeans это стандарт на компоненты: набор Java-классов со стандартным интерфейсом доступа. Компоненты JavaBeans могут быть установлены в сервер СУБД аналогично остальным наборам классов.
    Одной из причин появления адаптивной компонентной архитектуры Sybase является четкое понимание важности компонентной разработки прикладных систем, которое позволяет ускорить создание надежных информационных систем с помощью повторного использования уже отлаженного кода. Возможность использования компонентов JavaBeans на любых уровнях распределенной информационной системы, включая СУБД, позволит воспользоваться преимуществами языка Java при разработке корпоративных прикладных баз данных. Adaptive Server будет поддерживать исполнение компонентов кода на основе стандартов JavaBeans и Enterprise JavaBeans. Повторное использование: основная причина поддержки Java В связи с использованием виртуальной машины для исполнения методов на Java и встроенной поддержке интерфейса JDBC, один и тот же объект на языке Java (созданный непосредственно на JDBC, либо с помощью какого-либо RAD-средства, включая PowerJ) может быть использован как внутри, так и вне СУБД. В компании Sybase существует четкое убеждение, что для получения максимальных выгод от использования Java, критически важным является отсутствие особых требований для Java-классов, предназначенных для встраивания в СУБД.


    В отличии от некоторых других подходов, реализация Sybase целиком основывается на этой важнейшей особенности. Использование Java для описания объектных типов данных В дополнении к созданию прикладного кода в СУБД, использование языка Java позволяет найти решение к другим ограничениям современных реляционных СУБД. В частности, использование этого языка предоставляет средства для расширения набора имеющихся типов данных. Будучи установленным в Adaptive Server, Java-класс может быть использован в качестве типа данных для столбца таблицы. Каждое поле такой записи становиться экземпляром соответствующего Java-класса. В качестве примера возьмем простой класс на языке Java, хранящий адреса. Вы можете создать и инсталлировать в Adaptive Server класс Address, содержащий информацию об улице, городе и почтовом индексе. После этого вы можете создать столбец с типом данных Address и вставить новый адрес. Доступ к различным полям класса Address в запросах может производиться раздельно. Использование даже такого простого класса, каким является класс Address дает ряд преимуществ пользователям базы данных:
  • Благодаря хранению информации об адресе в рамках единого объекта, становиться проще контролировать ее целостность, особенно, когда это поле используется в нескольких таблицах базы данных (скажем в таблице сотрудников, таблице поставщиков, таблице клиентов и т.д.).
  • Прикладной код может быть включен в методы класса. Например, становиться возможным вставить данные только в поля Street (улица) и Postal Code (почтовый индекс), а значение поля City (город) сделать вычисляемым , на основе почтового индекса. Внешний пользователь не заметит какой-либо разницы между значением, которое храниться в базе данных, и вычисляемым значением.
  • Можно использовать наследование классов и методов. При этом допускается перегрузка методов, в зависимости от используемого класса. Например, можно создать классы US_Address и CanadianAddress, отнаследованные от базового класса Address. В каждом из этих классов могут быть разные методы проверки заполнения полей почтовый индекс, написание которого отличается для Канады и США.


    После этого, вы можете вставлять объект типа US_Address или CanadianAddress в поле типа Address.
    Возможность хранения объектов Java в реляционной СУБД является важной особенностью для корпоративных приложений. В частности, ожидается упрощение процесса внедрения и повышение количества повторно используемого кода. Доступ к Java-объектам из языка SQL Хотя интерфейс JDBC является стандартом индустрии для доступа к SQL из языка Java, в настоящее время не существует обратного стандарта, описывающего доступ к Java-объектам из SQL. Компания Sybase разработала такой интерфейс, и работает над его стандартизацией. Основным принципом разработчиков этого интерфейса являлось избежание неочевидных языковых конструкций: с тем, что бы Java-объекты и внутри операторов SQL работали так, как это ожидается. Язык Java и объектно-ориентированные СУБД Термин "объектно-реляционная СУБД" предназначен для обозначения ряда технологий, предназначенных для пользователей, которым недостаточно стандартных типов данных, имеющихся в реляционных СУБД. Одной характерной потребностью таких пользователей является возможность создания собственных базовых типов данных, которые могут быть специфичны для конкретной организации. В Sybase для этого используются Java-классы. Кроме того, существует потребность в относительно небольшом количестве специализированных типов данных, таких как текст, геоинформационные данные, временные ряды и мультимедийные данные. Эти специализированные типы данных имеют специфические требования к индексации и работе с ними. Sybase поддерживает подобные типы данных через слой интеграции компонентов обработки данных, который встроен в Adaptive Server. C помощью поддержки Java и встроенного слоя интеграции компонентов, Sybase создает объектно-реляционную СУБД, которая может быть оптимизирована для различных задач обработки данных. Возможные проблемы при использовании Java Безопасность и производительность являются наиболее частыми предметами для размышления для администраторов баз данных и отделов информационных технологий.


    Обсуждение реализации требований по безопасности и производительности в Java также являются предметом постоянной дискуссии в Java-сообществе. Вопросы безопасности Вопросы безопасности и целостности являются важнейшими для организаций, которые хранят свои данные в реляционных СУБД. Как поставщик технологий для корпоративных информационных систем, компания Sybase осознает эти требования и именно поэтому применяется архитектура Java. Например:
  • В СУБД можно использовать только те классы, которые установлены администратором базы данных.
  • Администратор имеет возможность управлять доступом из SQL к методам и полям класса.
  • Виртуальная машина, встроенная в Adaptive Server, не поддерживает операции, которые могут нарушить безопасность сервера СУБД.
  • Язык Java проектировался с учетом вопросов безопасности, поэтому он хорошо подходит на роль языка приложений, исполняющихся непосредственно в СУБД.
    Вопросы производительности Несмотря на то, что производительность Java-приложений является популярной темой для обсуждения, компания Sybase разделяет мнение многих специалистов, считающих, что подобные опасения исчезнут в течении следующего года. Аналитик Stan Doelberg из компании Forrester Research, обсуждавший недавно данную проблему, полагает, что "в течении шести месяцев проблема производительности будет снята"#. Различные разработчики компиляторов, включая соответствующее подразделение в Powersoft, продолжают работать над улучшениями языка. Пользователи Adaptive Server смогут воспользоваться этими разработками, после того, когда они установят скомпилированные Java-классы в сервер СУБД. Дополнительно, администратор СУБД сможет настраивать параметры хранения объектов в классе. Использование Java в СУБД и клиентские приложения Компания Sybase стремиться к созданию решений, которые бы позволяли сохранять сделанные существующими пользователями инвестиции в современную технологию. Уже существующие прикладные системы не должны изменяться для того, что воспользоваться новыми особенностями Adaptive Server. Java-особенности СУБД Adaptive Server доступны существующим прикладным системам, включая те, которые не используют Java, а применяют интерфейс ODBC или библиотеку Open Client.


    Клиентские приложения, использующие Java, могут использовать дополнительные возможности. Новые технологии компании Sybase
    Поддержка всех клиентских приложений Поддержка Java-архитектуры СУБД Adaptive Server для клиентских приложений, которые не используют Java, основывается на внутреннем отображении (internal mapping) языков Java и SQL. Клиентское приложение общается с сервером, используя стандартный интерфейс, например Sybase Open Client или ODBC. Доступ к полям, основанных на Java-объектах, производится с помощью стандартных операторов SQL. При этом методы Java вызываются и исполняются совершенно так же, как и обычные хранимые процедуры. На клиентском приложении в этом случае доступны только стандартные типы данных. Поддержка клиентских приложений на Java Клиентское приложение на Java сможет соединяться с Adaptive Server с помощью интерфейса JDBC. В дополнении к возможностям, которые доступны не Java-приложениям, клиентские Java-приложения смогут обмениваться объектами с Adaptive Server. Когда Java-объект запрашивается с сервера, он посылается к клиентскому приложению и исполняется на клиентской виртуальной Java-машине. Как уже подчеркивалось ранее, реализация Java архитектуры в Adaptive Server такова, что, в отличии от других технологий, классы не требуют какой-либо особой подготовки для использования в СУБД. Класс может быть использован в клиентском приложении, промежуточном сервере приложений, или же перенесен в СУБД без всяких модификаций, что упрощает создание распределенных приложений. Например, если метод city из класса Address вычисляет название города из значения поля Postal Code, то этот может быть вызван как с клиента, так и из сервера. Заключение Деятельность компании Sybase направлена на решение проблем организаций, которые создают и эксплуатируют информационные системы. Стратегия использования Java-технологии в Adaptive Server позволяет убрать искусственные барьеры, усложняющие и без того непростые задачи автоматизации. Java представляет собой новый язык программирования для разработки прикладных программ, а дополнительные технологии JavaBeans и Enterprise JavaBeans являются важными объектными моделями для создания приложений на Java.В то же время, реляционные СУБД являются наиболее широко используемым типом СУБД для решения задач бизнеса. Возможность хранить и запускать Java-объекты в реляционных СУБД открывают новые возможности для корпоративных разработчиков, а также позволяет использовать достоинства Java при разработки корпоративных прикладных информационных систем. Sybase

    Алексей Тимонин

    Тел.: (095) 956-2016 Факс (095) 956-2041

    | |

    Обзор возможностей применения ведущих СУБД для построения хранилищ данных (DataWarehouse)

    Сергей Кузнецов, Центр Информационных Технологий,

    Валерий Артемьев, ГЦИ ЦБ РФ
    Основные понятия

    Сравнение оперативных и аналитических ИС с точки зрения обеспечения данными
  • Основным источником информации, поступающей в оперативную БД является деятельность корпорации. Для проведения анализа данных требуется привлечение внешних источников информации (например, статистических отчетов). Хранилище данных должно включать как внутренние корпоративные данные, так и внешние данные.
  • Для оперативной обработки требуются свежие данные за несколько последних месяцев, для проведения достоверных анализа и прогнозирования в хранилище данных нужно иметь информацию о деятельности корпорации и состоянии рынка на протяжении нескольких лет. Объем аналитических БД как минимум на порядок больше объема оперативных.
  • Во многих крупных корпорациях одновременно существуют несколько оперативных ИС с собственными БД (по историческим причинам). Оперативные БД могут содержать семантически эквивалентную информацию, представленную в разных форматах, с разным указанием времени ее поступления, иногда даже противоречивую. Хранилище данных должно содержать единообразно представленную и согласованную информацию, максимально соответствующую содержанию оперативных БД. Необходима компонента для извлечения и "очистки" информации из разных источников.
  • Оперативные ИС создаются в расчете на решение конкретных задач. Информация из БД выбирается часто и небольшими порциями. Обычно набор запросов к оперативной БД известен уже при проектировании. Набор запросов к аналитической базе данных предсказать невозможно. Хранилища данных существуют, чтобы отвечать на нерегламентированные (ad hoc) запросы аналитиков. Можно рассчитывать только на то, что запросы будут поступать не слишком часто и затрагивать большие объемы информации. Размеры аналитической БД стимулируют использование запросов с агрегатами (сумма, минимальное, максимальное, среднее значение и т.д.).
  • Оперативные БД по своей природе являются сильно изменчивыми, что учитывается в используемых СУБД (нормализованная структура БД, строки хранятся неупорядоченно, B-деревья для индексации, транзакционность). При малой изменчивости аналитических БД (только при загрузке данных) оказываются разумными упорядоченность массивов, более быстрые методы индексации при массовой выборке, хранение заранее агрегированных данных.
  • Для оперативных ИС обычно хватает защиты информации на уровне таблиц. Информация аналитических БД настолько критична для корпорации, что требуются большая грануляция защиты(индивидуальные права доступа к определенным строкам и/или столбцам таблицы).


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

    Потоки данных в информационном хранилище
    Обзор возможностей применения ведущих СУБД для построения хранилищ данных (DataWarehouse)

    Свойства информационных хранилищ
    Уильям Инмон, считающийся основателем нового направления развития технологии БД, дал классическое определение информационного хранилища в 1990 г. Он охарактеризовал его как специальным образом администрируемую базу данных, содержимое которой имеет следующие свойства:
  • Предметная ориентация
  • Интегрированность данных
  • Инвариантность во времени
  • Неразрушаемость - cтабильность информации
  • Минимизация избыточности информации

    Предметная ориентация
    В отличие от БД в традиционных OLTP-системах, где данные подобраны в соответствии с конкретными приложениями, информация в DW ориентирована на задачи поддержки принятия решений.. Для системы поддержки принятия решений требуются "исторические" данные - факты продаж за определенные интервалы времени. Хорошо спроектированные структуры данных DW отражают развитие всех направлений бизнеса компании во времени.


    Поскольку в DW- технологии объекты данных выходят на первый план, то особые требования предъявляются к структурам БД, используемым для создания информационных хранилищ.. Принципиально отличаются и структуры баз данных для OLTP- и DW-систем. Во втором случае в них помещается только та информация, которая может быть полезной для работы систем поддержки принятия решений (DSS).
    Интегрированность данных
    Данные в информационное хранилище поступают из различных источников, где они могут иметь разные имена, атрибуты, единицы измерения и способы кодировки. После загрузки в DW данные очищаются от индивидуальных признаков, т. е. как бы приводятся к общему знаменателю. С этого момента они представляются пользователю в виде единого информационного пространства.
    Если в четырех разных приложениях пол клиента кодировался четырьмя различными способами, то в информационном хранилище будет использована единая для всех данных схема кодировки (например, f,m).
    Инвариантность во времени
    В OLTP-системах истинность данных гарантирована только в момент чтения, поскольку уже в следующее мгновение они могут измениться в результате очередной транзакции. Важным отличием DW от OLTP-систем является то, что данные в них сохраняют свою истинность в любой момент процесса чтения.
    В OLTP-системах информация часто модифицируется как результат выполнения каких-либо транзакций. Временная инвариантность данных в DW достигается за счет введения полей с атрибутом "время" (день, неделя, месяц) в ключи таблиц. В результате записи в таблицах DW никогда не изменяются, представляя собой снимки данных, сделанные в определенные отрезки времени. В DW содержатся как бы моментальные снимки данных. Каждый элемент в своем ключе явно или косвенно хранит временной параметр, например день, месяц или год.
    Неразрушаемость - cтабильность информации
    В OLTP-системах записи могут регулярно добавляться, удаляться и редактироваться. В DW-системах, как следует из требования временной инвариантности, однажды загруженные данные теоретически никогда не меняются.


    По отношению к ним возможны только две операции: начальная загрузка и чтение (доступ). Это и определяет специфику проектирования структуры базы данных для DW. Если при создании OLTP-систем разработчики должны учитывать такие моменты, как откаты транзакций после сбоя сервера, борьба с взаимными блокировками процессов (deadlocks), сохранение целостности данных, то для DW данные проблемы не столь актуальны - перед разработчиками стоят другие задачи, связанные, например, с обеспечением высокой скорости доступа к данным.
    Минимизация избыточности информации
    Поскольку информация в DW загружается из OLTP-систем, возникает вопрос, не ведет ли это к чрезмерной избыточности данных? Нет, утверждает Билл Инмон. На самом деле избыточность минимальна (около 1%!), что объясняется следующими причинами:
  • при загрузке информации из OLTP-cистем в DW данные фильтруются. Многие из них вообще не попадают в DW, поскольку лишены смысла с точки зрения использования в системах поддержки принятия решений;
  • информация в OLTP-системах носит, как правило, оперативный характер, и данные, потеряв актуальность, удаляются. В DW, напротив, хранится историческая информация, и с этой точки зрения перекрытие содержимого DW данными OLTP- систем оказывается весьма незначительным;
  • в DW хранится некая итоговая информация, которая в базах данных OLTP-систем вообще отсутствует;
  • во время загрузки в DW записи сортируются, очищаются от ненужной информации и приводят к единому формату. После такой обработки это уже совсем другие данные.

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


    Кроме того, возраст многих установленных OLTP-систем достигает 10 - 15 лет.
    Уровень доступа к данным
    Относящееся сюда ПО обеспечивает общение конечных пользователей с информационным хранилищем и загрузку требуемых данных из транзакционных систем. В настоящее время универсальным языком общения служит язык структурированных запросов (SQL).
    Загрузка и предварительная обработка
    Этот уровень включает в себя набор средств для загрузки данных из OLTP-систем и внешних источников. Выполняется, как правило, в сочетании с дополнительной обработкой: проверкой данных на чистоту, консолидацией, форматированием, фильтрацией и пр.
    Информационное хранилище
    Представляет собой ядро всей системы - один или несколько серверов БД.
    Метаданные
    Метаданные (репозиторий, "данные о данных"). Играют роль справочника, содержащего сведения об источниках первичных данных, алгоритмах обработки, которым исходные данные были подвергнуты, и т. д.
    Уровень информационного доступа
    Обеспечивает непосредственное общение пользователя с данным DW посредством стандартных систем манипулирования, анализа и предоставления данных типа MS Excel, MS Access, Lotus 1-2-3 и др.
    Уровень управления (администрирования)
    Отслеживает выполнение процедур, необходимых для обновления информационного хранилища или поддержания его состояния. Здесь программируются процедуры подкачки данных, перестройки индексов, выполнения итоговых (суммирующих) расчетов, репликации данных, построения отчетов, формирования сообщений пользователям, контроля целостности и др.
    Проблемы интеграции данных
    Остановимся на некоторых проблемах реализации хранилища данных:
  • Неоднородность программной среды
  • Распределенный характер организации
  • Повышенные требования к безопасности данных
  • Необходимость наличия многоуровневых справочников метаданных
  • Потребность в эффективном хранении и обработке очень больших объемов информации

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


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


    В системах, основанных на хранилищах данных, оказывается недостаточной защита данных в стиле языка SQL, которую обеспечивают обычные коммерческие СУБД (этот уровень защиты соответствует классу C2 в соответствии с классификацией Оранжевой Книги Министерства обороны США). Для обеспечения должного уровня защиты доступ к данным должен контролироваться не только на уровне таблиц и их столбцов, но и на уровне отдельных строк (это уже соответствует классу B1 Оранжевой Книги). Приходится также решать вопросы аутентификации пользователей, защиты данных при их перемещении в хранилище данных из оперативных баз данных и внешних источников, защиты данных при их передаче по сети.
    Необходимость наличия многоуровневых справочников метаданных
    Если роль метаданных (обычно содержащихся в таблицах-каталогах) в оперативных информационных системах достаточно ограничена, то для OLAP-систем наличие развитых метаданных и средств их предоставления конечным пользователям является одним из основных условий успешной реализации. Например, прежде, чем менеджер корпорации задаст системе свой вопрос, он должен понять, какая информация имеется, насколько она актуальна, можно ли ей доверять, сколько времени может занять формирование ответа и т.д. Для пользователя OLAP-системы требуются метаданные, по крайней мере, следующих типов:
    (1) Описания структур данных, их взаимосвязей.
    (2) Информация о хранимых на хранилище данных и поддерживаемых им агрегатах данных.
    (3) Информация об источниках данных и о степени их достоверности. Одна и та же информация могла попасть в хранилище данных из разных источников. Пользователь должен иметь возможность узнать, какой источник был выбран основным, и каким образом производились согласование и очистка данных.
    (4) Информация о периодичности обновлений данных. Желательно знать не только то, какому моменту времени соответствуют интересующие его данные, но и когда они в следующий раз будут обновлены.
    (5) Информация о владельцах данных. Пользователю OLAP-системы может оказаться полезной информация о наличии в системе данных, к которым он не имеет доступа, о владельцах этих данных и о действиях, которые он должен предпринять, чтобы получить доступ к данным.


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

    информации
    Уже сейчас известны примеры хранилищ данных, содержащих терабайты информации. По данным консалтинговой компании Meta Group, около половины корпораций, использующих или планирующих использовать хранилища данных, предполагает довести их объем до сотен гигабайт. Проблемой таких больших хранилищ является то, что накладные расходы на внешнюю память возрастают нелинейно при возрастании объема хранилища. Исследования, проведенные на основе тестового набора TPC-D, показали, что для баз данных объемом в 100 гигабайт потребуется внешняя память объемом в 4.87 раза большая, чем нужно собственно для полезных данных. При дальнейшем росте баз данных этот коэффициент увеличивается.
    Реализация хранилищ и витрин данных
    Варианты реализации хранилищ данных
  • Виртуальное хранилище данных
  • Витрины данных
  • Глобальное хранилище данных
  • Многоуровневая архитектура хранилища данных

    Виртуальное хранилище данных
    В его основе - репозиторий метаданных, которые описывают источники информации (БД транзакционных систем, внешние файлы и др.), SQL-запросы для их считывания и процедуры обработки и предоставления информации. Непосредственный доступ к последним обеспечивает ПО промежуточного слоя. В этом случае избыточность данных нулевая. Конечные пользователи фактически работают с транзакционными системами напрямую со всеми вытекающими отсюда плюсами (доступ к "живым" данным в реальном времени) и минусами (интенсивный сетевой трафик, снижение производительности OLTP-систем и реальная угроза их работоспособности вследствие неудачных действий пользователей-аналитиков).
    Витрина данных
    Витрина данных (Data Mart) по своему исходному определению - это набор тематически связанных баз данных, которые содержат информацию, относящуюся к отдельным аспектам деятельности корпорации.


    По сути дела, витрина данных - это облегченный вариант хранилища данных, содержащий только тематически объединенные данные. Целевая база данных максимально приближена к конечному пользователю и может содержать тематически ориентированные агрегатные данные. Витрина данных, естественно, существенно меньше по объему, чем корпоративное хранилище данных, и для его реализации не требуется особо мощная вычислительная техника.
    Глобальное хранилище данных
    В последнее время все более популярной становится идея совместить концепции хранилища и витрины данных в одной реализации и использовать хранилище данных в качестве единственного источника интегрированных данных для всех витрин данных. Тогда естественной становится такая трехуровневая архитектура системы:
    На первом уровне реализуется корпоративное хранилище данных на основе одной из развитых современных реляционных СУБД. Это хранилище интегрированных в основном детализированных данных. Реляционные СУБД обеспечивают эффективное хранение и управление данными очень большого объема, но не слишком хорошо соответствуют потребностям OLAP-систем, в частности, в связи с требованием многомерного представления данных.
    На втором уровне поддерживаются витрины данных на основе многомерной системы управления базами данных (примером такой системы является Oracle Express Server). Такие СУБД почти идеально подходят для целей разработки OLAP-систем, но пока не позволяют хранить сверхбольшие объемы данных (предельный размер многомерной базы данных составляет 10-40 Гбайт). В данном случае это и не требуется, поскольку речь идет о витринах данных. Заметим, что витрина данных не обязательно должна быть полностью сформирована. Она может содержать ссылки на хранилище данных и добирать оттуда информацию по мере поступления запросов. Конечно, это несколько увеличивает время отклика, но зато снимает проблему ограниченного объема многомерной базы данных.
    Наконец, на третьем уровне находятся клиентские рабочие места конечных пользователей, на которых устанавливаются средства оперативного анализа данных.


    Подходы и имеющиеся решения
    Компания IBM
    Решение компании IBM называется A Data Warehouse Plus. Целью компании является обеспечение интегрированного набора программных продуктов и сервисов, основанных на единой архитектуре. Основой хранилищ данных является семейство СУБД DB2. Преимуществом IBM является то, что данные, которые нужно извлечь из оперативной базы данных и поместить в хранилище данных, находятся в системах IBM. Поэтому естественная тесная интеграция программных продуктов.
    Предлагаются три решения для хранилищ данных:
    (1) Изолированная витрина данных. Предназначен для решения отдельных задач вне связи с общим хранилищем корпорации.
    (2) Зависимая витрина данных. Аналогичен изолированной витрине данных, но источники данных находятся под централизованным контролем.
    (3) Глобальное хранилище данных. Корпоративное хранилище данных, которое полностью централизовано контролируется и управляется. Глобальное хранилище данных может храниться централизовано или состоять из нескольких распределенных в сети рынков данных.
    Oracle
    Решение компании Oracle в области хранилищ данных основывается на двух факторах: широкий ассортимент продуктов самой компании и деятельность партнеров в рамках программы Warehouse Technology Initiative. Возможности Oracle в области хранилищ данных базируются на следующих составляющих:
  • наличие реляционной СУБД Oracle 7, которая постоянно совершенствуется для лучшего удовлетворения потребностей хранилищ данных;
  • существование набора готовых приложений, обеспечивающих возможности разработки хранилища данных;
  • высокий технологический потенциал компании в области анализа данных;
  • доступность ряда продуктов, производимых другими компаниями.

    Hewlett Packard
    Работы, связанные с хранилищами данных, выполняются в рамках программы OpenWarehouse. Выполнение этой программы должно обеспечить возможность построения хранилищ данных на основе мощных компьютеров HP, аппаратуры других производителей и программных компонентов. Основой подхода HP являются Unix-платформы и программный продукт Intelligent Warehouse, который предназначен для управления хранилищами данных.


    Основа построения хранилищ данных, предлагаемая HP, оставляет свободу выбора реляционной СУБД, средств реинжиниринга и т.д.
    NCR
    Решение компании направлено на решение проблем корпораций, у которых одинаково сильны потребности и в системах поддержки принятия решений, и в системах оперативной аналитической обработки данных. Предлагаемая архитектура называется Enterprise Information Factory и основывается на опыте использования системы управления базами данных Teradata и связанных с ней методах параллельной обработки.
    Informix Software
    Стратегия компании в отношение хранилищ данных направлена на расширение рынка для ее продукта On-Line Dinamic Parallel Server. Предлагаемая архитектура хранилища данных базируется на четырех технологиях: реляционные базы данных, программном обеспечении для управления хранилищем данных, средствах доступа к данным и платформе открытых систем. Три последние компонента разрабатываются партнерами компании. После выхода Универсального Сервера, основанного на объектно-реляционном подходе, можно ожидать, что и он будет использоваться для построения хранилищ данных.
    SAS Institute
    Компания считает себя поставщиком полного решения для организации хранилища данных. Подход основан на следующем:
  • обеспечение доступа к данным с возможностью их извлечения из самых разнообразных хранилищ данных (и реляционных, и нереляционных);
  • преобразование данных и манипулирование ими с использованием 4GL;
  • наличие сервера многомерных баз данных;
  • большой набор методов и средств для аналитической обработки и статистического анализа.

    Sybase
    Стратегия компании в области хранилищ данных основывается на разработанной ей архитектуре Warehouse WORKS. В основе подхода находится реляционная СУБД Sybase System 11, средство для подключения и доступа к базам данных OmniCONNECT и средство разработки приложений PowerBuilder. Компания продолжает совершенствовать свою СУБД для лучшего удовлетворения потребностей хранилищ данных (например, введена побитная индексация).
    Software AG
    Деятельность компании в области хранилищ данных происходит в рамках программы Open Data Warehouse Initiative. Программа базируется на основных продуктах компании ADABAS и Natural 4GL, собственных и приобретенных средствах извлечения и анализа данных, средстве управления хранилищем данных SourcePoint. SourcePoint позволяет автоматизировать процесс извлечения и пересылки данных, а также их загрузки в хранилище данных.

    Построение корпоративных аналитических

    Илья Гусев, Терн
    Компания и продукты     Предлагаемые программные продукты DSS/OLAP фирмы Business Objects позволяют создать систему Поддержки Принятия Решений (DSS) над источниками данных, отражающими произвольную предметную область. Другими словами, система может использоваться в учреждениях, банках, торговых и производственных предприятиях. Продукты DSS/OLAP BusinessObjects могут обеспечить широкий спектр конфигураций Системы Поддержки Принятия Решений - от отдельных рабочих мест DSS и приложений OLAP до централизованной системы с применением технологий Internet/Intranet. С другой стороны, BusinessObjects может быть использован для получения информации как из баз данных SQL, в том числе организованных как DataWarehouse, так и быть средством front-end для складов данных, использующих специализированные многомерные СУБД (Arbor Essbase, Oracle Express, Informix MetaCube). Продукты BusinessObjects сейчас установлены более чем в 5000 компаниях по всему миру, а оборот компании за прошлый год составляют более 100 млн $US. Высокие темпы роста продаж продуктов BusinessObjects в России свидетельствуют об исключительно хорошем соответствии возможностей этих продуктов сегодняшнему уровню требований к системам OLAP. Мы (компания ТЕРН) выбрали BusinessObjects после десяти месяцев практического сравнения аналогичных продуктов OLAP нескольких фирм на круге задач, с которыми мы сталкиваемся при внедрении систем автоматизации предприятий. Главными критериями для нас являлись: полнота семантического описания источников данных, которая давала бы возможность надежной работы с произвольными структурами баз данных, наличие понятных и, вместе с тем, развитых средств построения печатных отчетов и аналитики, простота администрирования и небольшое время внедрения. Средства OLAP BusinessObjects оказались настолько хорошо продуманными, что во многих случаях оказалось возможным не использовать выделенные хранилища данных DataWarehouse, обеспечивая при этом удобный доступ к информации в уже существующих базах. По опросу пользователей Oracle, проводимом независимым журналом Oracle Technical Journal, BusinessObjects был признан лучшим продуктом DSS/OLAP1996 года. Продукты Семантический слой Эта подсистема, которая позволяет конечным пользователям OLAP формулировать запросы к базе данных, используя свои привычные термины, имеет в BusinessObjects особенности, пока еще редкие в продуктах такого класса.
    BusinessObjects исходно ориентировал свои продукты как средство построения отчетов и OLAP для реляционных баз данных оперативных приложений, т.е. имеющих такие структуры таблиц и связей, которые оптимизированы на выполнение коротких транзакций. Такие базы, как правило, имеют большое (десятки, сотни) количество таблиц с очень сложной общей структурой связей. Аналитическую информацию здесь часто приходится извлекать из не связанных непосредственно групп таблиц. В BusinessObjects применена схема генерирования скриптов SQL по предварительно описанной программистом модели данных (Universe). Скрипты могут состоять из значительного числа операторов SELECT, которые могут сильно различаться по своей структуре. Полученные выборки синхронизируются между собой по той же модели данных. Эти особенности дают возможность корректно работать по практически произвольным структурам отношений и связей между таблицами, не ограничиваясь простейшими "звездными" или "снежиночными". Вместе с тем, семантический уровень BusinessObjects позволяет работать и с базами данных, организованными как RDBMS DataWarehouse (Informix MetaCube, Sybase IQ и др.), поскольку можно определять специфичное для этой технологии контекстное использование агрегатных таблиц и данных. Компания BusinessObjects и готовые модели данных для коммерческих приложений - SAP/R3, Oracle applications и др. Query & Reporting Формирование запросов в пользовательских терминах, их исполнение, интеграция данных из разных источников, просмотр данных с возможностями детализации и обобщения по иерархиям измерений и построение полноценных отчетов, как экранных так и печатных, должно производиться полностью в рамках одного приложения. BusinessObjects принял это требование как постулат, и поставляемый продукт Reporter с опцией Explorer это обеспечивают. Уровень подготовки специалиста, создающего отчеты, может быть примерно как у среднего пользователя Excel. Пользователь составляет запрос к источнику данных, используя подготовленный программистом каталог терминов Universe.


    Reporter автоматически преобразует этот запрос в скрипт SQL, оптимизируя количество и состав операторов SELECT, и производит выборку данных в локальный файл отчета BusinessObjects. В процессе дальнейшей работы выборка может освежаться, пополняться или редуцироваться по желанию пользователя. Данные из выборок отображаются в отчет в виде таблиц, перекрестных таблиц, графиков или отдельных ячеек. Одни и те же данные могут иметь несколько, в том числе и различных, отображений в зависимости от требований к документу. Пользователь может определять производные (вычисляемые) значения в виде контекстно-зависимых или "жестких" переменных и использовать их наравне с основными данными в локальных операциях сортировки, фильтрации, агрегирования, ranking и других основных операциях, наиболее часто используемых при составлении отчетов. Документ BusinessObjects может содержать данные, получаемые одновременно из разных источников. Для этого достаточно определить несколько запросов и, при необходимости, указать по каким полям выборки связаны между собой, задавая тем самым логическую структуру данных отчета. OLAP Средства навигации по многомерным выборкам встроены непосредственно в среду подготовки отчетов. При этом база данных - источник совсем не обязательно должна иметь многомерную структуру. Использование данных в качестве измерений, агрегируемых значений или атрибутов измерений назначается при описании логической модели данных в BusinessObjects. Аналитические приложения BusinessObjects является сервером OLE Automation, поэтому можно разрабатывать как простейшие приложения для навигации по документам, так и полномасштабные аналитические приложения OLAP. BusinessObjects - решение корпоративного масштаба Безопасность Эта функциональность обеспечивается продуктом Supervisor. При помощи Supervisor создается база данных, которая может быть открыта на любом корпоративном SQL сервере, доступном со всех рабочих мест. Администратор может определять время работы пользователя, его права по доступу к данным и функциональным возможностям системы.


    При назначении прав доступа к данным администратор может ограничить конкретного пользователя как по доступу к отдельным объектам каталогов Universe, так и по значениям данных путем прописывания соответствующих фрагментов запросов SQL в условиях WHERE. Доступная функциональность задается как назначением видимости органов управления приложением, так и запрещением отдельных операций (вплоть до копирования в Clipboard). Все операции администрирования могут производиться с одного рабочего места администратора Supervisor. Одновременно могут администрироваться более 10.000 пользователей и этому есть живые примеры (Shell, Defense Medical Logistics (US Department of Defense), Lucent). Работа в Web В 1997 году компания BusinessObjects выпустила новый продукт WebIntelligence, который позволяет обращаться к корпоративной информации, пользуясь стандартным Web броузером, имеющим встроенную виртуальную машину Java. Нетехнический пользователь может строить и просматривать отчеты, задавая произвольные запросы к базам данных опять же в терминах своего бизнеса. WebIntelligence использует те же Universe, что и другие средства BusinessObjects. Как и в предыдущих продуктах, пользователю WebIntelligence нет необходимости привлекать специалистов для проведения каких либо операций по конструированию выборок, промежуточных многомерных баз и т.д. Сохраняется возможность работы с репозиториями и способы администрирования. В WebIntelligence реализована схема тонкого клиента, работающего с удаленным сервером приложений. Средством формулирования запросов и работы с отчетом является аплет Java, код которого автоматически передается в броузер в момент первого обращения к серверу приложений. Обновления кода происходят в дальнейшем только при появлении его новых версий. Формирование выборок и построение документа производится на сервере приложений WebIntelligence, который передает изображение документа клиенту в виде страниц HTML. Сервер WebIntelligence использует стандартные средства доступа к корпоративным базам, такие как SQL*Net for Oracle, Open Client for SQL Server или ODBC. Почему пользователи выбирают BusinessObjects


  • надежный партнер, один из лидеров рынка, имеющий передовую технологию
  • поддержка практически любых структур баз данных приложений
  • работа со структурами данных, характерными для DataWarehouse и многомерными СУБД
  • генерация комплексных запросов SQL
  • возможность генерации "оптимизированных" запросов
  • одновременная интерактивная работа с множественными независимыми источниками данных
  • полная интегрированность "экранной" аналитики с подготовкой профессиональных отчетов
  • для получения новых данных не требуется привлекать специалистов IT
  • фоновая обработка отчетов и выполнение отчетов по событиям
  • публикация в Web
  • доступ из Internet/Intranet
  • простая установка, есть готовые модели данных для крупных коммерческих приложений
  • глубокий уровень и удобство администрирования с одной точки управления
  • масштабируемость от рабочей группы до корпорации
    Терн

    Илья Гусев

    Тел.: (095) 928-6078 Факс (095) 915-5860

    | |

    Реализация СУБД Teradata в архитектуре MPP (5100 и 5150)


    Реализация СУБД Teradata в архитектуре MPP (5100 и 5150)     На следующем рисунке показано использование СУБД Teradata в системе MPP, состоящей из четырех кластеров, каждый из которых состоит из четырех узлов SMP, соединенных между собой шиной BYNET. Как и в случае с однокластерной системой, на каждом узле работают несколько виртуальных процессоров AMP и несколько виртуальных процессоров PE. При этом можно либо распределить равномерно процессы по узлам, либо приписать каждому AMP или PE определенный узел. Слой передачи сообщений реализован в виде комбинации программного обеспечения PDE и BYNET. Кластеры не разделяют ни программное, ни аппаратное обеспечение. Архитектура СУБД share nothing естественно гармонирует с архитектурой системы, а возможности масштабируемости практически беспредельны. Teradata MPP
    Реализация СУБД Teradata в архитектуре MPP (5100 и 5150)
    Мощь MPP архитектуры Данная конфигурация может обрабатывать от 2 до 32 ТБ данных. Общая пропускная способность шины BYNET равна 320 МБ/сек. Для сложных запросов по поддержке принятия решений, в случае полного сканирования диска, система в данной конфигурации может выполнять до 40000 операций чтения в секунду. Строки в 163-байта располагаются в блоках по 32К, поэтому 1.6 миллиона строк могут составлять до 64 гигабайтов памяти, ежесекундно анализируемых 256 процессорами Pentium для выполнения сложных пользовательских SQL-запросов. 1.6 миллион строк в секунду - скорость впечатляющая. Вот она, мощь MPP архитектуры и СУБД Teradata! BYNET В настоящее время сеть BYNET позволяет соединять максимум 512 узлов с максимальным объемом базы данных в 128 ТБ и пропускной способностью системы 10 ГБ/сек. СУБД Teradata для ОС UNIX, выпущенная в декабре 1995 года, поддерживает базы данных объемом до 128 ТБ, поэтому как только появится оборудование для создания более крупных систем, будет проведена сертификация СУБД Teradata для работы на таком оборудовании. Теоретический предел возможностей сети BYNET составляет 4096 узлов. Благодаря современной технологии проектирования узлов, данный предел может быть реально достигнут.
    На таком количестве узлов можно разместить 16384 гигабайта памяти, 65536 процессоров и базы данных объемом в 1000 терабайт (1000 терабайт называется петабайт). Тем не менее, первый релиз данной технологии вовсе не означает достижения какого-либо технологического предела, поскольку уже в 1997 году объемы баз данных в сферах розничной торговле и телекоммуникаций превысят 70 ТБ. Петабайтные базы данных будут содержать нереляционные объекты, такие как текст, звук, видео и телеметрическую информацию. Защита инвестиций По мере роста пользовательских систем от архитектуры SMP, к кластерным системам и MPP системам, инвестиции, вложенные в аппаратное и программное обеспечение, должны быть защищены на все 100%. Например, обновление системы 5100S до системы 5100C выполняется за счет установки дополнительных узлов, рабочей станции администратора системы (AWS) и соединительной платы для существующих узлов 5100S. Аналогичным способом система 5100C обновляется до 5100M. Инвестиции, вложенные в аппаратуру 5100C, защищены на 100%. Обновление системы выполняется на месте. СУБД Teradata, работающая на 5100S - это та же самая СУБД, работающая на 5100C и на 5100M. Инвестиции в базы данных и все приложения также защищены на 100%. Гибкость СУБД Teradata позволяет добавлять в существующие системы дополнительные узлы и стойки следующего поколения. Баланс в системе поддерживается за счет распределения виртуальных процессоров по всем узлам. По мере добавления в систему более мощных узлов увеличивается и число виртуальных процессоров. Аналогичным образом первоначальные инвестиции в аппаратуру 5100 будут защищены на 100% , даже при появлении технологически новых систем. ТЕХНИЧЕСКИЕ особенности СУБД Teradata СУБД Teradata для UNIX предоставляет широкие возможности. Эти возможности рассматриваются в последующих разделах. Возможности клиента базы данных Пользовательские приложения могут работать с СУБД Teradata через интерфейс уровня вызовов CLI (Call Level Interface), Micro Teradata Director Program (MTDP) и Micro Operating System Interface (MOSI).


    Эти программные компоненты направляют операторы SQL системе управления базой данных и возвращают ответы на запросы приложению. Процедуры CLI, MTDP и MOSI хранятся в библиотеках, которые линкуются с приложением. Teradata поддерживает стандартные программные интерфейсы, такие как ODBC, JDBC и ESQL. Компоненты программного обеспечения клиента
    Реализация СУБД Teradata в архитектуре MPP (5100 и 5150)
    Возможности сервера баз данных На серверах World Mark функционирует серверная часть СУБД. Клиентское программное обеспечение поставляется для IBM MVS и VM, UNIX System V (включая 5100), DOS, Windows, OS/2, Macintosh и других платформ. Клиентские приложения направляют операторы SQL на выполнение в СУБД. Клиентские платформы подключаются к серверу либо через локальную сеть (LAN-attached clients), либо через каналы связи (channel-attached clients). Последнее относится к мэйнфреймам. Средства разработки клиентских приложений СУБД Teradata для OC UNIX состоят из препроцессоров ESQL с языков (COBOL, C и PL/I), а также программных интерфейсов CLI и Teradata Director Program. В программное обеспечение для мэйнфреймов IBM входят модули связи с CICS и IMS/DC. Кроме того разработка прикладного ПО возможна через имеющиеся драйверы ODBC и JDBC, с использованием таких средств как MS Visual Basic, MS Visual C++ и др. В программное обеспечение сервера баз данных, также входит шлюз базы данных (DBS Gateway), который преобразует внешние сетевые протоколы во внутренние протоколы сообщений СУБД. SQL Teradata SQL обеспечивает полный уровень совместимости с ANSI-стандартом языка SQL. Кроме того имеются свои собственное расширения стандарта SQL, специфичные исключительно для СУБД Teradata. Пользователь, работающий с СУБД Teradata через программу BTEQ (клиентская программа для интерактивной работы с БД), может установить для себя либо режим ANSI SQL, либо Teradata SQL. К некоторым из важных особенностей относятся:
  • Оператор ALTER TABLE, который добавляет столбцы или индексы к существующим таблицам
  • Обновляемые представления (VIEW), включая поддержку виртуальных столбцов
  • Вложенные подзапросы
  • Макросы SQL: именованные последовательности операторов SQL
  • Функции справки (HELP и SHOW), которая может показывать структуры БД, таблиц, представлений и статистические данные.
  • Функция EXPLAIN - используется следующим образом.


    Перед SQL запросом достаточно поставить слово explain, explain select ... (текст запроса). Результатом будет подробное объяснение пошагового выполнения запроса на английском языке
    Препроцессоры В СУБД Teradata входят следующие препроцессоры для языков:
  • VS COBOL, C и PL/1 для сред MVS и VM;
  • ANSI C для среды UNIX;
  • COBOL
    Интерфейс уровня вызова (Call-Level Interface - CLI) Интерфейс уровня вызова (Call-Level Interface - CLI) - это набор библиотечных функций, которые предоставляют прикладной программе интерфейс к СУБД Teradata. Вызовы CLI обычно поставляются в препроцессоре языка, но они также могут вызываться непосредственно в языках, для которых нет препроцессоров. В данный момент для большинства платформ доступен CLI версии 2 (CLIv2). Словарь метаданных В СУБД Teradata включен полностью интегрированный словарь метаданных (Data Dictionary), который позволяет пользователям получать информацию об объектах базы данных (например, таблицах и столбцах). Словарь метаданных состоит из системных таблиц и представлений, потому к нему можно обращаться с помощью стандартного языка SQL. Безопасность в Словаре данных обеспечивается с помощью механизмов представлений (VIEW) и привилегий (PRIVILEGES). Для администраторов баз данных существуют специальные представления, в которых содержится информация о доступе, использовании и владельцах. Управление транзакциями Teradata полностью поддерживает концепцию транзакций и предоставляет широкие возможности по журналированию, управлению параллельной работой, восстановлению данных и использованию контрольных точек. Защита целостности данных Целостность данных поддерживается в СУБД Teradata с помощью следующих возможностей: Управление параллельной работой Teradata предоставляет возможность блокировки на уровне базы данных, таблицы и хэш-значений для строк. Блокировки имеют четыре уровня: эксклюзивный (exclusive), на запись, на чтение и на доступ. Защита при восстановлении Данные защищены от сбоев в локальных или распределенных приложениях, от сбоев процессора или диска, а также от некорректного завершения приложения.


    Система автоматически выполняет операции по восстановлению и возобновляет работу. Резервное копирование и архивация баз данных В дополнение к возможностям по архивации в режиме "off-line", предоставляемым утилитой Архивации и Восстановления (Archive and Recovery utility) и функцией Архивации и хранения (Archive and Storage Facility), в Teradata также доступны постоянное и временное журналирование. Все операции выполняются параллельно. Журналирование Для обеспечения целостности транзакций в СУБД Teradata используется постоянное и временное журналирование. Временный журнал (Transient Journal) Во временном журнале хранятся образы строк перед тем, как они изменяются в ходе транзакции, выполняющей обновление данных. После фиксации транзакции эти образы удаляются из журнала, позволяя повторно использовать освободившееся пространство. Если транзакция не может быть завершена, то Teradata выполняет автоматический "откат" транзакции и строки таблицы БД возвращаются в первоначальное состояние, используя образы во временном журнале. Постоянный журнал (Permanent Journal) Постоянные журналы - это необязательные таблицы, в которые записываются образы строк до выполнения транзакции и/или после фиксации транзакции. В качестве дополнительной защиты допускается двойное копирование образов, даже если для журналируемых таблиц, не используется механизм защиты fallback. Постоянные журналы позволяют выполнять откат (roll back) или прокрутку таблицы или всей базы данных (roll forward) к той или иной контрольной точке. Механизм защиты данных - Fallback При необходимости СУБД Teradata может хранить две копии таблиц: основную и аварийную копию, распределенные между виртуальными процессами AMP. При нормальной работе чтение производится только из основной копии, а обновление выполняется в обеих копиях. Если при сбое первая копия становится недоступной, то для чтения и обновления используется аварийная копия. С появлением RAID и Кластеров в большинстве случаев использование аварийной копии стало излишним. Кластеры Несколько узлов 5100, 5150 или 4700 могут быть соединены в конфигурацию с разделяемым диском.


    Такая конфигурация называется кластером. При сбое любого узла в кластере все остальные узлы разделяют его нагрузку, до тех пор пока он не будет восстановлен. Это позволяет добиться сбалансированного восстановления от сбоев и избежать значительного ухудшения производительности, которое наблюдается на многих MPP-платформах с неработающими компонентами. Восстановление - операционная система не перезапускается В случае перезагрузки СУБД происходит перезапуск всех ее программных компонентов. Однако в СУБД Teradata операционная система не перезапускается, что обеспечивает более быструю перезагрузку всей системы. Во время процесса восстановления каждый виртуальный процесс AMP восстанавливает по журналу транзакций таблицы данных, а также используя т.н. системную таблицу, называемую cylinder indexes и постоянно расположенную на диске, строит таблицу master index, постоянно расположенную в оперативной памяти. Восстановление виртуальных процессов AMP выполняется параллельно и асинхронно. Обеспечение защиты данных от несанкционированного доступа. СУБД Teradata поддерживает предоставление и отмену привилегий для каждого пользователя на любую таблицу, представление, макрос или базу данных. Привилегии даются на: создание или удаление одного из данных объектов, выполнение макроса, вставку, выборку, обновление или удаление строк в таблице, а также на предоставление привилегий другим пользователям. Идентификация пользователя происходит по его логическому имени и паролю, логическое имя также используется для назначения дискового пространства. Все функции безопасности определены посредством языка Teradata SQL. Поддерживается уровень безопасности C2. Поддержка СУБД Teradata В ОС UNIX Для поддержки СУБД Teradata для ОС UNIX используются следующие основные компоненты:
  • Программа Database Window
  • Утилиты поддержки
  • Интерфейсы и утилиты для клиентов, подсоединенных через каналы связи
  • Продукты расширения для клиентов, подсоединенных по каналам связи
  • Интерфейсы и утилиты для клиентов, подсоединенных через сеть (LAN)
  • Программное обеспечение для шлюза базы данных (DBS Gateway)
  • Программное обеспечение для поддержки каналов связи


    Назначение этих компонентов объясняется в последующих разделах. Отдельное внимание уделено новым возможностям. Программа Database Window Database Window - это консольная программа для системного администрирования СУБД Teradata. Она может быть запущена в любой среде, поддерживающей Xwindows® . При запуске Database Window появляется главное окно, из которого пользователь может вызвать окно супервизора, окно сообщений базы данных или любое из окон приложений. Утилиты поддержки Далее приводится список утилит, которые используются системными инженерами, администраторами баз данных и системными администраторами. Данные утилиты предоставляют базовые функции по обслуживанию СУБД Teradata. Эти утилиты, за исключением Pdeconfig, запускаются из приложения Database Window на рабочей станции по администрированию системы (AWS). Pdeconfig запускается как приложение UNIX. Возможности, реализованные в Teradata для UNIX, выделены жирным шрифтом.
  • AbortHost - отменяет незавершенные транзакции
  • Checktable - проверяет целостность и непротиворечивость таблицу
  • Config - задает логическую конфигурацию СУБД (Виртуальные процессы AMP и виртуальные процессы PE)
  • DBSControl (Управление СУБД) - позволяет задавать для СУБД глобальные runtime флаги
  • DIP (Программа инициализации базы данных) - инициализирует базу данных
  • Vproc Manager (Диспетчер Vproc) - позволяет специально обученным сотрудникам получать статистическую информацию о Виртуальных процессрах и изменять различные параметры Виртуальных процессоров
  • Gateway Control Utility (утилита управления шлюзом) - управляет сетевыми соединениями
  • Ferret - позволяет специально обученным сотрудникам просматривать и устанавливать различные параметры, контролирующие использование дискового пространства, без разрушения данных файловой системы. После установки параметров Ferret может динамически переконфигурировать данные на диске так, чтобы они соответствовали новым параметрами.
  • Filer - позволяет специально обученным сотрудникам получать сведения, необходимые для поиска и исправления ошибок в файловой системе.


    Эту утилиту следует использовать с большой осторожностью, поскольку она иногда обходит средства безопасности при отображении или изменении параметров. (Эта программа предоставляется для использования только специалистами NCR.)
  • Pdeconfig - инициализирует PDE и конфигурирует аппаратное обеспечение для виртуальных процессов
  • QryConfig (Запрос по конфигурации) - отображает текущую логическую конфигурацию СУБД
  • QrySessn (Запрос по сеансам) - отображает информацию о статусе сеансов
  • RcvManager (Диспетчер восстановления) - отображает статус процесса восстановления данных
  • Rebuild (Построение таблицы) - восстанавливает таблицу или таблицы из аварийной копии, механизма fallback
  • Reconfig - перераспределяет данные на дисках. Выполняется автоматически при добавлении или удалении виртуальных процессов AMP
  • Showlocks - показывает блокировки на базах данных и таблицах
  • SysInit (Инициализатор системы) - позволяет специально обученным сотрудникам инициализировать системные таблицы Teradata и все пользовательские таблицы
    Базовое программное обеспечение для клиентов,

    подсоединенных через сеть (LAN)     Базовое программное обеспечение является интерфейсом между СУБД Teradata и приложением, работающим на подсоединенной через сеть клиентской платформе. В базовое программное обеспечение входят:
  • Micro Teradata Director Program (MTDP)
  • Micro Operating System Interface (MOSI) - библиотека сервисов для конкретной операционной системы и коммуникационного протокола связи. MTDP вызывает процедуры в библиотеке MOSI (вместо прямых обращений к библиотеке операционной системы) для выполнения таких системных сервисов, как обработка прерываний, обработка ввода/вывода, а также связи по сети.
  • Интерфейс уровня вызова (CLI) Версии 2
    Утилиты для клиентов, подсоединенных через сеть (LAN) В состав утилит, запускающихся на подсоединенных через сеть клиентских платформах, входят:
  • Basic Teradata Query (BTEQ) - выполнение базовых запросов к СУБД Teradata
  • FastLoad - загрузка данных в пустые таблицы.
  • Preprocessor для языка С - для платформ NCR, на которых установлен UNIX
  • Preprocessor для языка COBOL - для платформ NCR, на которых установлен UNIX


    Программный интерфейс для клиентских утилит, подсоединенных

    через сеть и программное обеспечение шлюзов     Программный интерфейс для утилит клиента и программное обеспечение шлюзов, на подсоединенных через сеть клиентских платформах, состоит из:
  • WINCLI - для IBM PC и совместимых машин, на которых установлена операционная система MS-DOS и Microsoft Windows
  • ODBC - для IBM PC и совместимых машин, на которых установлена операционная система Microsoft Windows
  • Модуль доступа OMNI для СУБД Teradata
  • Database Query Manager (Диспетчер запросов к базе данных)
    Клиентское программное обеспечение В дополнение к базовому программному обеспечению клиентов и клиентским утилитам, подключающимся через сеть, для платформ 5100/5150/4700 также доступно следующее программное обеспечение:
  • Archive Storage Facility (ASF2) - обеспечивает полную архивацию и восстановление баз данных Teradata на ленточные устройства. Это избавляет от необходимости делать архивацию через мэйнфрейм IBM. Утилита ASF2 также используется, чтобы записывать на ленты дампы памяти, которые могут быть затем проанализированы сотрудниками из службы технической поддержки.
  • FastExport - выгрузка данных из таблиц
  • MultiLoad - загрузка и обновление данных в пустых и непустых таблицах
    Программное обеспечение шлюза DBS Gateway DBS Gateway преобразует внешние сетевые протоколы во внутренние протоколы сообщений СУБД. Первая версия СУБД Teradata для UNIX на платформе 5100 поддерживает через шлюз порядка 600 сеансов. Программное обеспечение поддержки каналов связи Программное обеспечение поддержки каналов связи IBM обеспечивает соединение с мэйнфреймом IBM или другими совместимыми мэйнфреймами. Поддержка каналов на 5100 предоставляет до 8 каналов связи на узел и 120 сеансов на канал. Заключение В настоящее время Teradata является одним из лучших в мире продуктов для массивно-параллельной обработки (MPP). Это единственный продукт, имеющий четырнадцатилетнюю историю в технологиях параллельной обработки данных и единственный продукт, по-настоящему поддерживающий хранилища данных, в наиболее крупных компаниях мира.


    Это единственный продукт, поддерживающий хранилища данных с терабайтными объемами. В настоящее время, на UNIX платформе, на серверах WorldMark 4700/5100/5150 СУБД Teradata достигла выдающейся производительности в SMP-системах, наивысшей степени надежности в кластерных системах и непревзойденной мощности в MPP-системах. Масштабируемое аппаратное и программное обеспечение, а также привлекательная ценовая политика создают одно из лучших решений для предприятий, использующих DSS системы. Мы широко открыли дверь в будущее! Для тех, кто планирует внедрять средние или крупные системы хранения данных, Teradata - это единственный реальный выбор. Совсем недавно компания NCR представила новое поколение MPP серверов это модели NCR WorldMark 4700 и 5150. Обе модели представляю собой принципиально новое решение сочетая в себя традиционные для серверов компании NCR черты такие как непревзайденная производительность, масштабируемость, высокая готовность, рекордное соотношение цена/производительность и как итог беспрецедентная защита инвестиций. Обе машины используют стандартные Intel компоненты и архитектуру PCI и позволяют клиентам начать с нескольких десятков гигабайт и расти до десятков терабайт.
    NCR

    Константин Лисянский, Дмитрий Слободяников

    Тел.: (095) 961-3030 Факс (095) 961-3031

    E-mail:

    | |

    Software AG: вчера, сегодня, завтра

    Ольга Китова, Software AG
    Software AG     (г. Дармштадт, ФРГ, основана в 1969 году) - вторая по величине в Европе и Германии независимая компания, входящая в число 20 крупнейших производителей программного обеспечения в мире. Она имеет представительства и партнеров более чем в 80 странах мира. Основные направления деятельности - разработка, продажа, последующее обслуживание и сопровождение высокоэффективных программных изделий, служащих основой для интеграции информационных систем предприятия. Более 5000 больших и средних предприятий во всем мире полагаются на продукты и технологии Software AG.
    Основные изделия фирмы, объединенные открытой интегрированной архитектурой и принесшие ей мировое признание, - это тpи семейства пpогpаммных пpодуктов во главе с ADABAS, NATURAL и ENTIRE. Портфель продуктов Software AG дополняется профессиональным сервисом, вместе они покрывают весь спектр потребностей информационных систем крупных предприятий и организаций, позволяют интегрировать существующие инфраструктуры информационных технологий и новые разработки.
    NATURAL -     является ядром комплекса интегрированных средств четвёртого поколения (4GL) для разработки прикладных систем и задач в централизованной традиционной многополь-зовательской архитектуре и/или в распределенной архитектуре клиент/сервер, которые обеспечивают идентичные функциональные возможности и одинаково высокую продуктивность на серверных платформах и в среде графических рабочих станций. Семейство NATURAL включает в себя универсальную среду символьного и графического событийно-управляемого программирования NATURAL Lightstorm, генератор прикладных систем CONSTRUCT, активный словарь-репозитарий PREDICT и набор мощных CASE-инструментов для проектировщиков инфор-мационных систем.
    ENTIRE -     семейство изделий промежуточного слоя (middleware), которое обеспечивает пpозpачную работу пpикладных систем в неоднородной сетевой среде различных ЭВМ, операционных систем и баз данных, позволяет создавать вычислительные системы в шиpоком спектpе совpеменных аpхитектуp, начиная от удаленного доступа пользователей к базам данных и до многоуpовневых систем, выполняющих pаспpеделенные вычисления в pежиме клиент/сеpвеp.
    Распространив технологию DCOM фирмы Microsoft на ряд платформ UNIX и на мэйнфреймы, Software AG обеспечила возможность использования DCOM в гетерогенных вычислительных сетях масштаба предприятия, что формирует основу технологии "componentware", которая существенно повысит продуктивность разработки систем за счет повторного использования программных компонент.
    ADABAS -     высокопроизводительная система управления базами данных для больших объемов информации, обладающая очень высокой скоростью обработки транзакций, которая в совокупности с рядом дополнительных изделий, существенно расширяющих ее возможности до мультимодельной системы, позволяет строить как тpадиционные иеpаpхические, сетевые и pеляционные SQL базы данных, так и сложные текстовые информационно-поисковые и интегpиpованные системы, географические и системы обработки изображений, постpеляционные стpуктуpы для моделиpования человеческой деятельности, экспертного анализа сложных пpоизводственных процессов и т.д.
    Современные версии продуктов Software AG поддерживают Internet и Web-технологии, что позволяет предприятиям использовать существующие прикладные системы при работе в реальном масштабе времени в сетях Internet/Intranet. Продукты Software AG помогают использовать Internet для электронной коммерции - нового канала продаж, обеспечивающего дополнительные конкурентные преимущества для многих компаний.
    В феврале 1997 года Software AG объявила о выпуске BOLERO - среды разработки бизнес-приложений, основанных на Web-технологии.
    Software AG поддерживает партнерские отношения с различными компаниями-поставщиками оборудования и программного обеспечения, что позволяет покупателям быть уверенными в качестве предлагаемых решений.
    В соответствии с предварительными результатами 1997 года оборот Software AG увеличился на 14 процентов с учетом сравнимой структуры компании и составил 725 млн. DM, прибыль до выплаты налогов выросла до 50 млн. DM.
    Продукция и широкий диапазон услуг фирмы Software AG находят многообразные сферы применения.


    Это промышленность, торговля, транспорт, связь, медицина, банки и страхование, полиция и военные системы, государственное и муниципальное управление, общественные организации и многие другие области человеческой деятельности. На основе продуктов Software AG автоматизируется работа банков Chase Manhattan, Citibank и Deutsche Bank, всех полицейских служб и казначейства Великобритании, страховой компании Prudential Assurance, аппарата Белого дома США, японских компаний Japan Air Lines, Nissan и Nomura Securities, а также многих других. Информационно-поисковая система SPHINX, также созданная на основе изделий фирмы, решает задачу оперативного доступа к данным мировых информационных агентств в телекомпании ZDF (ФРГ).
    В России, СНГ и странах бывшего СССР продукция Software AG имеет почти двадцатилетний опыт использования. С 1988 года фирма официально поставляет свои изделия и реализует комплексные проекты в целом ряде организаций России, Украины, Латвии и Эстонии. В их числе: Главное управление информационных ресурсов органов государственной власти Российской Федерации, РАО "ГАЗПРОМ", Министерство путей сообщения, Министерство иностранных дел, ГК "Росвооружение", Департамент морского флота РФ и отдельные пароходства, Государственная Центральная научная медицинская библиотека, МОСКОМЗЕМ Правительства Москвы, РНЦ "Курчатовский институт", издательство "Пресса", нефтедобывающие предприятия Западной Сибири, Чебоксарский завод промышленных тракторов, Мурманский морской завод "Севморпуть", Омский шинный завод, Волжский трубный завод, концерн OTIS, аэропорт "Шереметьево", Югтокобанк Украины, торговый порт и судоремонтный завод в Ильичевске, Черноморское морское пароходство, Министерство связи Украины и другие.

    Состав программного комплекса IFS

    Модули комплекса можно объединять в различных сочетаниях с учетом специфики различных видов предприятий, образуя целостные комплексы. В зависимости от настройки и модульного состава, комплекс может использоваться на различных видах предприятий:
  • непрерывное производство
  • сборочное производство
  • проектно-ориентированное производство
  • энергетика
  • транспорт
  • оптовая торговля

    Состояние и перспективы Microsoft SQL Server

    Алексей Шуленин, Microsoft

    Новые и обновленные утилиты
  • SQL Enterprise Manager
  • Интегрирован с MMC, включает средства взуализации из Visual Data Tools (создание структуры, протягивание отношений, редактирование данных в таблицах по ходу дела, ...)
  • Больше wizard'ов, хороших и разных:
  • Создание базы, поддержка базы, управление предупреждениями (alerts), импорт/экспорт данных, тиражирование, хранимые процедуры, ...
  • Index Tuning Wizard- моделирование рабочей нагрузки (множества запросов и определение наиболее подходящих индексов. Взаимодействует с Query Optimizer. Не учитывает одновременных пользователей.
  • Нельзя администрить предыдущие версии SQL Server- они не понимают новую модель SQL-DMO
  • Использовать старый Enterprise Manager или написать свой snap-in для 4.2, 6.х


  • SQL Server Agent (бывший SQL Executive)
  • Основные понятия: jobs (бывшие tasks), operators и alerts
  • Job- последовательность шагов
  • Каждый шаг - batch на T-SQL
  • Выбор действия в зависимости от удачного / неудачного выполнения шага (выход с сообщением, переход на шаг № ...)
  • Время и частота выполнения задач планируется администратором
  • Operator - лицо, которому посылается сообщение по сети, e-mail или пэйджингу о результатах выполнения job или наступления alert
  • Назначение выполнения job и/или отправки сообщения для operator
  • на возникновение ошибки с определенным номером в определенной БД
  • на достижение порогового значения каким-либо показателем в SQL Performance Monitor
  • SQL Server Profiler (бывший SQL Trace)
  • В отличие от Trace, кот. использовал ODS, Profiler встроен в Engine и обладает большими возможностями
  • Может смотреть, что делают SP, проигрывать ранее записанную последовательность действий, имеет лучшие возможности фильтрации и группирования событий
  • SQL Query Analyzer (бывший isql/w)
  • Улучшенный Showplan и графический план выполнения запроса
  • Выделение языковых конструкций цветом
  • Настройка вида результатов для удобочитаемости (grid)
    Механизм хранения
  • Механизм хранения управляет
  • размещением данных на жестких носителях
  • распределением памяти
  • вводом / выводом
  • контролем одновременного доступа к данным
  • журналированием транзакций
  • резервным копированием и восстановлением
  • Цель - полностью отделить реляционный engine (процессор запросов) от механизма хранения
  • и заставить QP общаться с ним только через уровень OLE DB

    Базы данных и файлы
  • Понятие "device" уходит
  • Device => file, БД может лежать на нескольких файлах, обратное теперь неверно
  • БД и журнал транзакций теперь обязательно лежат на разных файлах (.mdf / .ndf и .ldf)
  • Всего три типа файлов в БД:
  • primary (.mdf)- cтартовая точка БД, содержит данные + указатели на остальные файлы, может быть только один на БД
  • secondary (.ndf)- необязателен, содержит данные, не поместившиеся в primary, в одной БД может быть много
  • log file (.ldf)- как минимум, один, содержит transaction log
  • Объекты БД не могут быть приписаны конкретному файлу, для этих целей используется группа
    Базы данных и группы файлов
  • Понятие "сегмент" уходит
  • Файлы могут объединяться в file groups для удобства размещения данных на определенные диски и администрирования
  • Группе файлов могут назначаться отдельные таблицы, индексы и данные типов text, ntext, image
  • Каждый файл может быть членом только одной группы
  • Два типа file groups
  • Default- для primary файлов, системных таблиц и файлов, для которых группа не определена. Всегда одна на БД
  • User-defined- для остальных. Может быть несколько групп на БД
  • Logи не являются частью групп и управляются отдельно от базы

    Динамическое управление размером
    Состояние и перспективы Microsoft SQL Server Новые форматы хранения
    Состояние и перспективы Microsoft SQL Server Хранение text и image
    Состояние и перспективы Microsoft SQL Server
    Полнотекстовый поиск
  • Расширения DML
  • Предикаты CONTAINS, FREETEXT, функция RELEVANCE, ...
  • SELECT publication, pub_date, writer FROM magazines WHERE CONTAINS ( article, ' Edison NEAR(WORD,20) "electric%" ' )
  • Этапы развития
  • Ноябрь 1997- OLE DB провайдер для Index Server 2.0- поиск данных в файловой системе
  • Март 1998- OLE DB провайдер для Site Server 3.0- поиск по документам на Web
  • 2-я половина 1998 г.- поиск по BLOB-полям в Sphinx
  • Возможности легко доступны из приложений
    Set rstMain = CreateObject(ADODB.RecordSet) rstMain.Open "SELECT DocAuthor,

    FileName FROM SCOPE(' DEEP TRAVERSAL OF ( "D:\Sphinx\tsql\specs") ') WHERE size > 50000", "Provider = MSIDXS;" Блокировка уровня записи


    Состояние и перспективы Microsoft SQL Server Key Range Locking
    Состояние и перспективы Microsoft SQL Server Динамическая блокировка
    Состояние и перспективы Microsoft SQL Server Log Manager
    Состояние и перспективы Microsoft SQL Server Резервное копирование
    Состояние и перспективы Microsoft SQL Server Производительность SQL Server 7.0 при on-line backup
    Состояние и перспективы Microsoft SQL Server Кое-что новое в T-SQL
  • В связи с введением распределенных запросов имя состоит из 4-х частей
  • Отложенное разрешение имен
  • Можно создать таблицу и тут же сослаться на нее в хранимой процедуре
  • Новое в поддержке курсоров
  • Тип Cursor, переменные можно передавать как параметры
  • Процедуры sp_cursor_list, sp_describe_cursor_columns / _tables
  • Процедуры управления заданиями и предупреждениями
  • sp_add_alert, sp_add_job, sp_add_operator, ...
  • Процедуры управления SQL Profiler xp_trace_*
  • Добавлены новые указания оптимизатору (hash, merge, loop, robust plan, ... ) для операторов DML
  • Новые clauses TOP, PERCENT, WITH TIES для SELECT
  • ALTER PROCEDURE (TRIGGER, VIEW) без изменения прав
  • Опция DROP COLUMN появилась в ALTER TABLE
  • Добавлены новые функции
  • Системные: ObjectProperty, ColumnProperty, DatabaseProperty, ...
  • Статистические: StDev, Var, ...
  • Секьюрные: Is_Member, Is_SrvRoleMember, ...
  • Операции над датами (+/-)
  • Новые типы данных
  • Unicode'овские nchar, nvarchar, ntext
  • длина char, varchar, binary, varbinary- до 8К
  • Тип Uniqueidentifier (GUID), поле ROWGUIDCOL и функция NewID()
  • Substring от данных TEXT и IMAGE

    Новое в безопасности
  • Улучшенная интеграция с безопасностью NT
  • Аутентификация средствами NT (как текущий пользователь- без пароля, как другой- login+pwd)
  • Mixed (возможна аутентификация средствами SQL Srv)
  • Полная поддержка пользователей, групп и ролей
  • Роли могут быть приписаны пользователям и группам NT, а также пользователям Sphinx
  • Роли могут быть вложены
  • Прикладные роли для 3-уровневых систем
  • Позволяют назначать права при доступе через приложение, а не isql
  • Гибкая гранулярность прав и системных ролей
  • Предопределенные роли ServerAdmin, SecurityOfficer, ...
  • Поддержка делегирования в NT 5.0
  • На 2-м сервере не как удаленный пользователь, а под тем же именем
  • Простое и мощное администрирование
    Новое в QP
  • Multi-index - одновременное использование нескольких индексов (в т.ч.


    над одной таблицей)
  • пересечение двух множеств RID по каждому индексу для получения результирующего множества (например, SELECT * FROM orders WHERE cust_id = 987 and order_value >= 10000- индексы по cust_id и order_value)
  • создание covering index из нескольких имеющихся, которые в отдельности не являются covering для данного запроса (covering index позволяет читать значения колонок с leaf-уровня, не залезая в саму таблицу)
  • Merge Join
  • Получить row из outer table
  • Получить row с таким же ключом из inner table
  • Если найден, далее- по inner table, если нет- по внешней
  • Выглядит как обычная nested iteration, но проходится за один шаг и потому выполняется быстрее
  • Hash Join
  • Хэш-функция - свертка ключа, на выходе- значение меньшего размера, основное требование- равномерное распределение, главное преимущество- доступ к записи за одно обращение к таблице
  • Пример - алфавитная записная книжка, первая буква- хэш-функция, буквенные секции - букеты
  • Применяется, когда не задан порядок сортировки или нет подходящих индексов
  • Прочитать меньшую таблицу, нарезать ключи и RID в букеты хэш-таблицы
  • Читать большую таблицу. Хэшировать ключ, проверить хэш-таблицу, повторить.
  • Hash aggregation (sum, ...)
  • Из входной таблицы хэшировать ключ в букет
  • Если он там уже лежит, вычислить агрегат
  • Зациклить, в конце выдать окончательный агрегат

    Оптимизация запросов
  • Запросы оптимизируются по условной стоимости
  • Учитываются факторы количества операций чтения/записи и времени работы процессора
  • А также целевые записи (напр., построить оптимальный план для выбора первых 10 записей)
  • При этом используются
  • Статистика по хранимым данным (плотности и гистограммы)
  • Индексы (например, наличие уникального индекса о чем-то говорит?)
  • Ограничения (DRI, сonstraints, nulls)
  • Constraints и разбиение данных
  • Имеем несколько таблиц: январь, февраль, март
  • Построили совокупный view- union
  • Делаем из него select за один месяц, QP ищет только в одной таблице (при условии, что на нее был определен месячный constraint)
  • Auto partitioning при вводе by value между несколькими таблицами - в следующей версии
  • Обработка массивных обновлений- QP поддерживает индексы
  • При массовых insert, update, delete изменения сортируются по индексу и применяются за один проход (на один индекс)


  • Технология используется в ВСР, DBCC

    Модель оптимизации
  • Определение самого дешевого дерева на основе пула альтернатив
  • Изменение порядка join'ов
  • (R JOIN S) JOIN T = (R JOIN T) JOIN S
  • Раннее применение условий фильтрации
  • Классы эквивалентности для колонок и другие неявные предикаты
  • Если a=b, то sort(a), очевидно, такой же, как sort(b)
  • Функциональная избыточность
  • Group(e#,ename) = group(e#)
  • ...
    Параллельная обработка запросов
  • Параллельная обработка- одновременное выполнение одного запроса несколькими процессорами
  • Асинхронный ввод/вывод, обслуживание клиентов на разных потоках не рассматривается
  • Дает преимущество только на машинах с >1 СPU
  • Запрос компилируется для параллельного выполнения, формируется параллельный план
  • Единый параллельный план для нескольких процессоров
  • К операторам последовательного плана добавлены Exchange Operators (Distribute, Gather, Repartition)
    Exchange Operator
    Состояние и перспективы Microsoft SQL Server Степень параллелизма
  • Кол-во процессоров, на которых выполняется данный шаг плана запроса
  • Может отличаться для разных шагов, например, при вычислении результирующего агрегата из промежуточных DOP=1
  • Insert / update / delete выполняются на одном потоке
  • Но их части, относящиеся к SELECT могут выполняться с DOP>1
  • Выигрывают долгоиграющие запросы с массивными агрегатами, joinами, unionами и т.д.
  • Не выигрывают OLTP-запросы
  • Число одновременных пользователей >> числа процессоров - предпочтительнее межзапросный параллелизм
    Настройка DOP
  • В конфигурации max DOP меняется от 0 до 32
  • Default=1- отключить параллельное выполнение
  • Default=0 (автоматическая настройка в зависимости от конкретного запроса
  • Учет затрат на инициализацию параллельного плана, перемещение данных между потоками
  • При высокой загрузке, росте коннектов, нехватке памяти Sphinx будет стремиться понизить DOP
  • Сost threshold of parallelism- генерировать параллельные планы только для запросов с более высокой стоимостью (конфигурация 0-32767, default=5)
  • Showplan показывает Exchange-итераторы
  • DOP каждого конкретного запроса можно видеть в SQL Profiler


    Сравнение производительности QP
    Состояние и перспективы Microsoft SQL Server Универсальный доступ к данным
  • Данные хранятся по-разному, а нужны зачастую все и сразу
  • Руководитель сидит в MS Project, хочет прочитать переписку (e-mail), поднять документ (файловая система) увидеть баланс (СУБД), послушать музыку...
  • Качать это все в базу всякий раз, чтобы воспользоваться ее механизмами обработки?
  • Потом обратно, а источники уже могли независимо измениться... Целостность?
  • QP СУБД заведомо не оптимизирован под новые типы
  • Выход - не универсальное хранение, а универсальная обработка
  • Никто, лучше самих данных, не знает, как их обрабатывать
  • OLE DB - набор стандартных интерфейсов: что должна уметь делать компонента обработки данных
  • Аналогия с ODBC, но для данных произвольной природы
  • OLE DB является "родным" интерфейсом Sphinx
  • QP общается с Data Storage через OLE DB
  • DB-Lib эмулируется средствами OLE DB и больше развиваться не будет
    Универсальный доступ к данным (3)
    Состояние и перспективы Microsoft SQL Server Гетерогенные запросы
    Состояние и перспективы Microsoft SQL Server Распределенные операции в Sphinx
    Состояние и перспективы Microsoft SQL Server Sphinx и Data Warehousing
    Состояние и перспективы Microsoft SQL Server Объектная модель службы преобразования данных
    Состояние и перспективы Microsoft SQL Server Понятие пакета DTS
    Состояние и перспективы Microsoft SQL Server DTS Designer в Sphinx
    Состояние и перспективы Microsoft SQL Server Microsoft Data Cube Service
  • Базовая архитектура:
  • Кэшировать не дисковые страницы, а результаты запросов и метаданные
  • Мгновенный ответ на кэшированные запросы
  • Алгоритмы выведения пропущенных данных и преобразования запросов
  • Агрегация, фильтрация, комбинирование
  • Эффективное распределение обработки запросов и промежуточных вычислений между клиентом и сервером
  • Объединяет серверные и настольные платформы
  • Унифицирует доступ к многомерным данным из Excel, Plato, SQL Server ...
    Microsoft

    Алексей Шуленин

    Тел.: (095) 967-8585 Факс (095) 967-8500

    |

    SQLBase 7.0. Новая версия - новые возможности

    С. Маклаков, Д.Матвеев, Интерфейс Ltd
    В конце 1997 года корпорацией Centura Software была выпущена новая версия сервера баз данных SQLBase 7.0. Седьмая версия SQLBase, в период бета-тестирования имевшая название "Voyager", является небольшой по объему базой данных, используемой для создания информационных систем, в том числе ориентированных на Web. SQLBase сервер, используемый с информационными системами или web-приложениям позволяет создавать надежные системы обработки данных, не требующие сложного администрирования и способные удовлетворить большинство потребностей пользователя. Наиболее важной особенностью SQLBase 7.0 является легкость перехода от предыдущих версий, а так же простота обучения. Имеющиеся встроенные диспетчеры, обеспечивающие полную интеграцию с Microsoft Windows NT и Novell NetWare, универсальный механизм репликации с любыми серверами баз данных и API для построения Java-приложений делают SQLBase 7.0 неплохим выбором для разработчиков. SQLBase 7.0 позволяет создавать Web-приложения, использующие доступ к базам данных, с этой целю в SQLBase 7.0 встроены новые особенности репликации в новой компоненте SQLExchange. SQLBase 7.0 поддерживает репликацию для всех СУБД, в частности двунаправленную репликацию со всеми основными источниками данных в дополнение к поддержке ODBC-3. В настоящее время, растет популярность Java, как основного языка для разработки Web-приложений. Java-апплетам, как клиентским, так и серверным требуется доступ к базам данных, и SQLBase 7.0 имеет JDBC-драйверы, позволяющие организовать подобный доступ. Уровень-4 JDBC-драйверов позволяет создавать очень простые клиентские Java-приложения, связанные с встроенной базой данных, основанной на SQLBase. SQLBase существует в следующих разновидностях:
    (а) Многопользовательский многозадачный 32-битный сервер баз данных для

    Windows NT и 95, (b) Однопользовательский многозадачный 32-битный сервер баз данных для

    Windows NT и 95, (c) Однопользовательский 16-битный сервер базы данных для Windows 3.1 и 3.11.

    Рассмотрим основные нововведения новой версии Встроенные диспетчеры, обеспечивающие управляемый запуск, закрытие и работа в неявном режиме. Большое количество разработчиков воспользуются преимуществом высокой программируемости и встраиваемости SQLBase, позволяющей пользователям не знать о существовании сервера. SQLBase теперь предоставляет улучшенный API-механизм для программного запуска и закрытия локального сервера SQLBase, а также возможность определить видимы ли в процессе работы программные пиктограммы и экраны статуса. Стопроцентный сервис Windows NT. Centura Software рассматривает платформы Microsoft и Novell NetWare как основные операционные системы для готовых приложений. По этой причине в состав SQLBase включtys расширения и новые возможности по улучшению поддержки этих операционных систем. Чтобы улучшить безопасность, надежность и самообслуживание под Windows NT, сервер SQLBase может запускаться как NT-сервис. SQLBase может теперь быть сконфигурирован так, что будет автоматически запускаться, когда загружается NT-сервер, без наличия подключенного пользователя. Это существенно повышает безопасность и надежность эксплуатации баз данных. В ситуациях, когда необходим перезапуск NT ( типа сбоя по питанию или обрыва сети ), SQLBase станет доступным автоматически после перезагрузки операционной системы. Стопроцентная Поддержка NDS. С появлением Novell's NetWare Directory Services (NDS), Novell использует методологию Service Advertising Protocol (SAP). Пользователи сервера SQLBase для NetWare 4.x имеют возможность использовать преимущества этой технологии:
  • Пониженная загрузка сети. Имена базам данных и серверу больше не должны указываться явно, что переводит сервер в более высокий ранг сетевых средств обработки информации.
  • Упрощенные межсетевые коммуникации. Проблемы, касающиеся сетевых соединений, маршрутизаторов и фильтрации пакетов SAP устраняются с использованием NDS.
    Connectivity Administrator. Конфигурация сервера баз данных на различных платформах при использовании нескольких сетевых протоколов, установка параметров сервера, а также одновременное использование 16-ти и 32-разрядных клиентских приложений может стать очень серьезной проблемой.


    Для этой цели в SQLBase 7. 0 входит новый набор утилит и конфигурационных экспертов, для того чтобы избежать редактирования INI-файлов и реестров Windows. SQLBase 7.0 может обнаружить все программное обеспечение, установленное на вашем компьютере, включая протоколы и конфигурацию сети, и автоматически установит необходимые параметры сервера баз данных. Таким образом, установка и поставка сетевых и локальных SQLBase серверов в составе конечного продукта достаточно проста. SQLExchange(tm) Replication. В последнее время Internet-приложения становятся основным средством связи мобильных и удаленных пользователей с базами данных центральных офисов. Поэтому в SQLBase включены универсальные возможности . Эти новые возможности позволяют разработчикам использовать репликацию для распределения данных между корпорациями, отделениями, ведомствами, и даже настольными базами данных. SQLExchange предоставляет большие преимущества для тех пользователей, которым необходимо размещать или получать данные с использованием Web. SQLExchange, наряду с сервером баз данных SQLBase, легко перемещает данные между брандмауэрами. Конечно, SQLBase не единственная база данных на рынке с технологией репликации данных сервер/сервер (server-to-server). Однако, это - единственная RDBMS, которая безопасно управляется, и поддерживает репликацию для большого количества источников данных. SQLBase обеспечивает следующие особенности репликации:
  • Поддержка любых RDBMS, через ODBC и встроенные драйверы. Возможность конвертации типов данных "на лету".
  • Более легкий и удобный, пользовательский интерфейс для настройки репликации. Включает в себя язык скриптов для настройки логики процесса копирования данных, и запуска одного или большего количества репликационных процессов. Разработчики могут устанавливать правила для решения конфликтов "на лету".
  • Элементы управления ActiveX позволяют программистам делать прямые запросы к системе репликации из любого языка программирования. Любой инструмент разработки, поддерживающий использование ActiveX, типа Microsoft Visual Basic, может безопасно производить репликацию.
  • Внешние функции SQLBase позволяют автоматически вызывать триггеры в replication-set.
  • Независимая компонента системы репликации позволяет пользователям выполнить репликацию с любой клиентской машины, имеющей доступ к исходному и целевому серверу баз данных.


    JDBC драйвер для Java-приложений. Java-апплетам, как клиентским, так и серверным требуется доступ к базам данных. Для выполнения этой потребности SQLBase 7.0 имеет JDBC драйвер 4 уровня. Это позволяет разработчикам на Java иметь доступ к базам данных SQLBase через SQLBase API.
  • Родной JDBC драйвер
  • Стопроцентная поддержка Java
  • Не требует мостов или серверов
  • Высокая производительность
  • Использует любой виртуальный механизм Java или инструмент разработки
  • Новые возможности по обеспечению безопасности
    Внешние Функции. Внешние функции дают разработчикам возможность писать дополнительные программы для обращения к серверу SQLBase. Вызов внешних функций позволяет программисту базы данных расширить исходные функциональные возможности SQLBase. Используя эту технологию, разработчики могут организовать запросы к DLL из хранимых процедур. DLL может, в свою очередь, выполнять фактически любое действие и возвращать результат вне базы данных. Разработчики имеют возможность запускать внешние функции не только на сервере ( то есть синхронно ), но и как независимое приложение ( то есть асинхронно ). Эта является уникальной особенностью для SQLBase. Многопоточные программы Поскольку многопоточные операционные системы становятся более распространенными, разработчики начинают использовать их преимущество в своих приложениях. Чтобы реализовать эту потребность, базы данных должны обеспечивать интерфейс, который разрешает выполнение многократных параллельных транзакций от одного приложения. SQLBase API, называемый SQL/API, теперь поддерживает распределенные и многократные транзакции. В традиционной технологии клиент/сервер клиенты имеют возможность подключения только одного пользователя от одного отдельного компьютера. Мультизадачные возможности новых 32-битных операционных систем позволяют разработчикам создавать параллельные связи с базами данных для повышения производительности, а также улучшения функциональных возможностей. Web-приложения должны поддерживать множественные независимые связи с серверами баз данных.


    Серверные приложения или иные дополнения к Web-серверам легко обращаются с базами данных через драйверы баз данных. Такая архитектура позволяет разработчикам создавать Web-приложения, но требует при этом концентрировать многократные и независимые обращения к базам данных от отдельной программы. Сервер SQLBase также позволяет хранить и управлять наборами результатов(result set) на сервере, а не на клиенте. Эта особенность SQLBase очень выгодна для создания приложений для Web - с помощью SQLBase разработчики имеют возможность не переносить результаты на все компьютеры клиентов, а иметь их только на сервере. ODBC 3 драйверы. ODBC стали наиболее распространенным стандартом связи с базами данных для языков 3GL и 4GL. SQLBase 7 включает в себя ODBC драйверы уровня 3.0. Они полностью поддерживают многофункциональные приложения в SQLBase версии 7.0. Драйверы также полностью совместим с более старыми API ODBC 2.0. Server Monitor Server Monitor облегчает настройку основных параметров. Так как конечные пользователи обычно не имеют технических знаний, простое администрирование баз данных становится первостепенной задачей по снижению общей стоимости эксплуатации бизнес-приложений.
    Интерфейс Ltd

    Сергей Маклаков

    Тел.: (095) 135-7781, 135-5573 Факс (095) 135-5500, 135-2519

    E-mail:

    | |

    В качестве основных этапов жизненного

    Кирилл Лисовский, IBM
    В качестве основных этапов жизненного цикла программного обеспечения традиционно выделяют:
  • анализ требований;
  • проектирование;
  • программирование;
  • тестирование/отладку;
  • эксплуатация и сопровождение.
    IBM располагает самыми разнообразными средствами, предназначенными для автоматизации задач, возникающих на каждом из этих этапов. Большинство таких средств относится к семейству продуктов VisualAge. Наиболее развитым представителем этого семейства является, безусловно, IBM VisualAge Packbase. Он включает в себя средства поддержки полного цикла разработки приложения и может быть отнесен к категории "тяжелых" CASE-систем. IBM VisualAge Packbase ориентирован на коллективную разработку крупных распределенных систем, и представляет собой единый комплекс программных средств, состоящий из набора стандартных продуктов VisualAge, дополненных средствами анализа, проектирования и управления проектами. IBM VisualAge Generator представляет собой средство для разработки на языке 4GL интероперабельных приложений переносимых между такими платформами как OS/2, Windows, OS/400, MVS, различные UNIX и виртуальная машина Java. IBM VisualAge Generator ориентирован на разработку приложений баз данных по трехзвенной модели. IBM VisualАge Smalltalk является средством быстрой разработки приложений на объектном языке Smalltalk. Принцип построения приложений из частей, являющийся основой идеологии VisualAge, обеспечивает быструю разработку и эффективную модификацию приложения в сочетании с развитыми возможностями повторного использования кода, в том числе унаследованного. IBM VisualAge Smalltalk ориентирован на разработку приложений баз данных использующих архитектуру клиент-сервер. IBM VisualАge C++ является средством быстрой разработки приложений на языке С++, а входящий в его состав компилятор C/C++ используется в качестве средства системного программирования. В отличии от программных продуктов, перечисленных выше, IBM VisualАge C++ не включает в себя средства организации коллективной разработки.
    При наличии необходимости в них может использоваться VisualAge Team Connection. IBM VisulAge for Java играет важную роль в принятой IBM концепции сетецентрических вычислений и сочетает достоинства технологий Java и VisualAge. IBM VisualАge Basic ориентирован на быструю разработку небольших приложений и может использоваться для написания хранимых процедур DB2. IBM VisualАge Requirements Tool предоставляет средства описания, анализа и моделирования бизнес-процесса. Стремительное развитие технологий, связанных с электронной коммерцией и растущая потребность в инструментарии, предназначенном для разработки таких приложений вызвало появление VisualAge for E-Business, представляющий собой комплекс программных средств для построения приложений электронной коммерции. При разработке приложений баз данных особый интерес представляет IBM VisualAge DataAtlas, представляющий собой средство, решающее ряд задач анализа, проектирования и программирования, возникающих при создании таких приложений. DataAtlas предоставляет развитый инструментарий для проектирования новой или реинжиниринга существующей схемы базы данных, с последующей генерацией определения данных. IBM VisualAge DataAtlas состоит из трех основных модулей: 1. DataAtlas Modeler предназначен для построения как концептуальной, так и логической модели данных. Modeler использует диаграммы "сущность-связь" (ER) для представления разрабатываемой модели данных. С их помощью осуществляется детализация хранилищ данных моделируемой системы, документируются сущности системы и способы их взаимодействия, включая идентификацию объектов предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей). DataAtlas Modeler обеспечивает построение как концептуальной, так и логической модели данных. 2. DataAtlas Dictionary обеспечивает работу с определениями данных. Наряду с реляционными системами управления базами данных (DB2 и Oracle) поддерживаются иерархические (IMS) и приложения на языках разработки высокого уровня.


    DataAtlas Dictionary использует IBM VisualAge TeamConnection для хранения, обработки, и разделения объектов баз данных с модулями DataAtlas Designer и Modeler и другими средствами разработки (например, IBM VisualAge Generator). 3. DataAtlas Designer - инструмент для работы с реальной базой данных и импорта/экспорта в нее абстрактной модели данных. Он предоставляет средства для создания и поддержки оптимального физического определения данных на основании построенной ER-модели. DataAtlas Designer помогает разработчику или администратору базы данных в сложных и часто встречающихся процедурах оптимизации хранения данных. К их числу относятся следующие задачи:
  • оценка производительности для разрабатываемого приложения;
  • схема физического размещения данных;
  • определение и связывание дополнительных ресурсов (таких как индексы, области таблиц, пространства буферов);
  • решение о физическом выравнивании данных (таких как кластеризация индексов).
    IBM предлагает широкий выбор средства разработки программного обеспечения, располагая программными продуктами для решения самых разных возникающих при разработке задач. Некоторые из этих средств предлагают решение отдельных, узкоспециальных задач (например, VisualAge Exchange), другие (как VisualAge PackBase) предлагают комплексное решение, охватывающее все этапы жизненного цикла приложения. Открытые технологии и соответствие стандартам позволяет использовать продукты IBM совместно с программными средствами других производителей, а широкая гамма предлагаемых IBM средств разработки программного обеспечения позволяет выбрать инструмент, максимально соответствующий поставленной задаче.
    IBM

    Кирилл Лисовский

    Тел.: (095) 940-2000 Факс (095) 940-2070

    E-mail:

    | |

    Стратегические направления развития технологии Informix

    Ховард Залкин, Informix

    Что обеспечивает репликация данных
  • Защиту от потери информации за счет наличия резервной копии
  • Возможность продолжать работу при выходе из строя отдельных узлов
  • Распределение нагрузки между несколькими серверами
    Основные схемы тиражирования данных
    Стратегические направления развития технологии Informix

    Стратегические направления развития технологии Informix
    Решения Informix для организации тиражирования данных High-Availability Data Replication (HDR ) Особенности HDR
  • "Горячий" резерв (2 идентичных сервера)
  • Только первичный сервер допускает изменение данных
  • Функционирование на уровне серверов
  • Частичное распределение нагрузки между двумя узлами
  • Простота администрирования
  • Работает с OnLine Dynamic Server на Unix и NT
    Informix Enterprise Replication
  • тиражирование на уровне строк и колонок
  • поддержка асинхронной репликации
  • поддержка схем ведущий - ведомый и равный к равному
  • механизмы автоматического разрешения конфликтов
  • обеспечивается внутренними средствами сервера
  • нет жестких ограничений на соответствие версий сервера и типов ОС
  • поддержка всех типов данных, включая BLOB
  • централизованное администрирование и мониторинг
  • открытый API
    Подробнее о возможностях Enterprise Replication

    Репликация: Сравнение с конкурентами
  • Informix
  • На основе журнала транзакций. Быстро и надежно.
  • Открытый интерфейс
  • Просто в настройке и сопровождении
  • Главный конкурент
  • На основе триггеров. Без комментариев...
  • Закрытый интерфейс.
  • Тяжелое администрирование.
  • Требуется отдельный сервер
  • Несовместимость с объектами, фрагментированием, параллельными запросами
  • triggers

    Репликация: сравнение с конкурентами
    Стратегические направления развития технологии Informix
    Репликация в Informix - Заключение Необходимые условия для работы с Informix Enterprise Replication
  • Версия сервера 7.22 и выше
  • Сетевые протоколы TCP/IP и SNMP
  • Наличие NT Workstation
  • Базы данных с журналированием
  • Первичные ключи для всех реплицируемых таблиц
    Informix Enterprise Replication обеспечивает:
  • Организацию сложных схем репликации
  • Автоматическое разрешение кофликтов
  • Синхронный и асинхронный режимы работы
  • Централизованное администрирование в масштабах предприятия

    Informix Web Integration Option Ранее:
  • Web DataBlade Module (на Universal Server),
    и
  • Informix-Universal Web Connect (на всех других серверах).
    Сейчас:
  • Единое расширение, доступное для любых серверов

    INFORMIX-Client SDK 2.x Компоненты:
  • INFORMIX-ESQL/C
  • INFORMIX-CLI
  • Intersolv Data Direct ODBC
  • INFORMIX-Object Interface for C++
  • INFORMIX-Object Interface for Java
  • Informix-Driver for JDBC
    INFORMIX-Object Interface for Java
  • Компонента INFORMIX-Client SDK 2.x
  • Объектно-ориентированный API
  • Для разработчиков на Java, поддержи-вающих OO-подход и использующих SQL
  • Поддержка новых типов данных
  • Поддержка функций, определяемых пользователем
  • Обеспечивает поддержку SQL3
  • Включает драйвер INFORMIX для JDBC...
    Драйвер INFORMIX для JDBC
  • Реализация Informix спецификации JavaSoftTM JDBC
  • Позволяет JDBC-приложениям иметь доступ к Informix Dynamic Server
  • Позволяет разработчикам писать приложения используя "чистый" Java API
    Data Director for Java


    DDJ совместим с:
  • Windows 95 среда разработки
  • Web-сервера на Solaris and NT
  • Сервер БД Informix Dynamic Server
  • IDS/Universal Data Option
  • IDS Workgroup Edition
    Партнерство Informix и Symantec
    Стратегические направления развития технологии Informix
    Следующая версия 2.0
    Стратегические направления развития технологии Informix
    Развитие на ближайшее будущее
    Стратегические направления развития технологии Informix
    Ховард Залкин, Informix

    Менеджер отдела поддержки продаж

    Россия/СНГ

    +7-095-755-8700

    | |

    СУБД Jasmine - построение виртуальных предприятий

    Сергей Кузнецов, Computer Associates
    Введение     Развитие информационных технологий в сфере бизнеса породило огромный спрос на приложения нового поколения. Организации теперь все чаще используют программное обеспечение ради того, чтобы выпустить новую продукцию в кратчайшие сроки и опередить конкурентов. Многие устремились в Интернет, чтобы расширить круг своих клиентов и иметь возможность каждому потенциальному покупателю рассказывать о себе более наглядно и доходчиво. Эти новые решения не имеют ничего общего со старыми программами, работавшими на зеленых экранах терминалов мейнфреймов, и уже мало чем напоминают преобладающие сегодня на персональных компьютерах программы с окнами, иконками и ниспадающими меню. Главное отличие приложений нового поколения - это их динамичный характер. Например, некоторые наиболее развитые Web-приложения обладают высоко интуитивным интерфейсом с постоянно обновляющимся содержанием, что особенно привлекательно для посетителей Интернет. Однако новые мощные приложения нужны не только в среде Web. Многие компании модернизируют свои традиционные клиент-серверные решения, на которых ведутся такие функции, как бухгалтерия, прием и обработка заказов, учет кадров, исследования и корпоративная информация. Эти новые приложения значительно отличаются от тех, что создавались, скажем, лет пять тому назад. Пользователям теперь предоставляются более широкие возможности управления, а доступ может осуществляться не только внутренним, но и внешним пользователям в Интернет и в корпоративных сетях интранет или экстранет. Общей особенностью всех этих новых приложений является мультимедиа. Мультимедийные средства позволили оживить традиционные типы данных и сделали приложения более удобными в использовании. Вместе с тем, как и раньше, новые приложения должны характеризоваться высокой производительностью и надежностью - особенно ввиду того, что количество и уровень подготовки пользователей не всегда предсказуем. Безотказность приложений крайне важна для компаний, занимающихся бизнесом в Интернет - в конце концов, сама Сеть открыта для всех желающих круглые сутки и без выходных.
    Поэтому приложения изначально разрабатываются для всего мирового сообщества. Немаловажное значение имеет также безопасность, особенно если приложение используется для осуществления коммерческих операций. Чтобы приложения обладали подлинной динамичностью, они должны быть построены на прочном фундаменте базы данных. Это требование породило массу сложнейших проблем для разработчиков корпоративных баз данных. Если раньше от баз данных требовалось обрабатывать простую информацию, такую как текст или целые числа, то теперь перед ними встала задача управлять сложными данными и предоставлять эти данные как можно быстрей и как можно большему числу пользователей. Кроме того, база данных часто должна уметь предоставлять данные приложениям, работающим на разных платформах. Имея несколько десятилетий опыта в области управления информацией, фирма Computer Associates International, Inc. (CA) понимает потребности компаний, которым должно отвечать новое поколение приложений. Именно поэтому мы и разработали JasmineTM. Эта уникальная система управления информацией позволяет организациям быстро разрабатывать изощренные приложения, предназначенные для обработки мультимедиа и других сложных типов данных и способные функционировать где угодно. Технические требования к приложениям нового поколения Приложения нового поколения должны помогать компаниям увеличивать конкурентоспособность, сокращать сроки выхода новой продукции, расширять спрос и обращаться к каждому покупателю более индивидуально и доходчиво. А сами по себе приложения должны быть проще и не требовать длительного обучения. Для достижения этих целей, помимо традиционной текстовой и числовой информации, необходимы также мультимедийные данные, такие как видео, аудио и анимация. Мультимедийные приложения гораздо проще в понимании, нежели их предшественники. Они позволяют быстро и легко воспринимать огромный объем информации. Превосходство мультимедийных приложений доказывается хотя бы тем, что "лучше один раз увидеть, чем сто раз услышать".


    Благодаря изобилию графики, конструкция приложений в Web и интранет позволяет любому пользователю, попавшему на первую страницу, легко переходить от страницы к странице. В противовес этому, даже наиболее продуманные приложения Windows требуют частого обращения к справочной информации. Тем не менее, сама идея мультимедийности не только несет в себе многие преимущества для компаний, но и ставит ряд технических проблем перед разработчиками. На современном предприятии информация хранится в разнообразных источниках, включая реляционные, иерархические и сетевые базы данных. Новые приложения должны уметь обращаться к этим данным из любой клиентской среды, например, из броузера, из Windows на настольном или сетевом компьютере. Отсюда вытекает необходимость совместимости со множеством языков программирования, включая HTML, ActiveX, Java, C++ и другие. Дело осложняется еще и тем, что логистика бизнес-процессов может быть заложена в базах или приложениях, разбросанных по предприятию. СУБД Jasmine - построение виртуальных предприятий
    Современное предприятие Появление мультимедиа в этой и без того запутанной ситуации заставляет особенно остро ощутить потребность в кардинально новом решении. Мультимедиа - это сложный тип информации. Для разработки мультимедийных приложений обычно используются объектно-ориентированные языки. Однако очень часто можно наблюдать "несогласованность сопротивлений", когда приложение, написанное на объектно-ориентированном языке, пытаются привязать к необъектным базам. Приложение, обученное работе с объектами, просто задыхается от необходимости непрерывно собирать в объекты множество разрозненных данных, хранящихся в традиционных базах. Мультимедийные данные должны интерпретироваться перед обработкой. Возьмем простой пример: растровое изображение должно быть распознано как таковое, прежде чем над ним будут выполняться различные графические операции или вывод на экран. Традиционная база данных способна лишь хранить файл изображения, а всю работу по его распознаванию и обработке вынуждено делать приложение. Еще одна сложность заключается в том, что все приложения, обращающиеся в базу за мультимедийными данными, должны выполнять все операции выборки, распознавания и обработки этих данных единообразно.


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


    Главное из них - возможность не задумываться о сложности структуры информации, о том, как именно данные хранятся в базе, как они обрабатываются, изменяются и форматируются для отображения перед конечным пользователем. Это позволяет значительно ускорить процесс разработки приложений. Кроме того, поскольку код создается только один раз и внедряется в данные, он может повторно использоваться другими приложениями, что избавляет разработчика от необходимости каждый раз его дублировать и тестировать перед использованием. Ограничения альтернативных систем Реляционные СУБД, предназначенные для хранения простейших типов данных (числа и текст) не способны управлять сложными бизнес-объектами и, тем более, их взаимосвязью. По этой причине многие производители СУБД стремятся научить свои объектно-реляционные системы поддерживать бизнес-объекты. В объектно-реляционных СУБД, являющихся по сути гибридными, делается попытка строить объекты на реляционной технологии. Такие гибридные системы, как Informix Universal Server или Oracle8 Universal Data Server, не полностью реализуют объектную модель базы данных. Они не поддерживают базовые свойства объектов, такие как наследование. Эти функции приходится нести на себе приложениям, которые становятся слишком громоздкими и потому не могут относиться к "новому поколению". Дополнительной проблемой таких систем является необходимость переноса кода из базы в приложение, что вызывает значительное замедление в работе клиентов на маломощных рабочих станциях. В расширенно-реляционных системах, таких как DB2 фирмы IBM, изначально добавлены "определяемые пользователем типы данных" (UDT), надстраиваемые над реляционной структурой базы. Но даже в такой архитектуре не полностью реализуется объектная модель и отсутствуют указанные выше возможности. Частичная реализация объектной модели в гибридных системах - это лишь один из их проблем. Все гибридные продукты обладают еще одним общим недостатком. Под маской объектной ориентации в них скрывается изначально реляционная структура данных, состоящая из таблиц, колонок и строк.


    Запросы к объектам каждый раз формируются заново из крупиц данных строк и колонок. Гибридные системы страдают недостатком и гибкости и производительности. Поскольку объекты хранятся в реляционных таблицах, изменение структуры объектов выполняется медленно и сложно. Построение объектов из табличных данных также требует времени и извлечения кода из базы. Эти дополнительные функции обработки могут крайне отрицательно сказаться на производительности базы, особенно если данные хранятся в различных таблицах, которые необходимо объединять перед построением объекта. Проведенные исследования показали, что в гибридных системах треть времени уходит только на преобразование данных в объекты. Результат таков, что в гибридных системах недостаточно эффективно используются и объектная и реляционная модели базы данных. Как нельзя лучше это выразила эксперт Эстер Дайсон (Esther Dyson), сказав, что "Использовать таблицы для хранения объектов - все равно что разбирать машину прежде, чем поставить ее в гараж, а затем перед выездом снова ее собирать. Можно, конечно, делать и так, но разве это нормально?" "Комплексный подход Jasmine является его самой сильной стороной. С Jasmine вы имеете мощную мультимедийную базы данных, инструментальное средство пятого поколения и независимую от платформы среду выполнения. Никто сейчас не предлагает ничего подобного." Грег Киндалл (Greg Kindall), вице-президент Data Pro Необходима подлинно объектно-ориентированная система, в которой реализованы все возможности объектной модели базы данных. Только так можно избежать всех недостатков в гибкости и производительности, присущих альтернативным технологиям. Эффективная система должна также позволять легко разрабатывать приложения нового поколения, иначе масса пользователей ее не примет. Что же такое Jasmine? Jasmine представляет собой полностью объектно-ориентированную среду программирования. Это первая в мире СУБД для сложных мультимедийных бизнес-приложений. Jasmine позволяет быстро собирать из объектов мощные, насыщенные мультимедийными элементами, приложения.


    Вам не придется создавать разные версии приложения для использования на различных платформах. Приложение, разработанное один раз с помощью Jasmine, будет одинаково хорошо работать в любой среде - в Интернет, корпоративной сети интранет или экстранет, на автономной рабочей станции или в клиент-серверной системе. Jasmine обладает открытой архитектурой. Computer Associates понимает, как много вложений было сделано компаниями в различные системы и языки программирования. К базе данных Jasmine можно одинаково легко обращаться из приложений, написанных самыми разнообразными средствами - будь то Java, C, C++ или HTML, а также любым инструментарием, поддерживающим ActiveX или OLEDB таким как Visual Basic. Объектная модель Jasmine Имея в своей основе подлинно объектную модель, Jasmine обладает всеми теми функциями, которые делают объектно-ориентированные СУБД такими мощными. Это абстрактные классы, встраиваемость, классификация, наследование (единичное и множественное), уникальные идентификаторы объектов, методы (включая уровни экземпляра, класса и набора), полиморфизм и агрегация. Поскольку данные наследования хранятся вместе с другими типами метаданных, как и объекты в самой объектной базе, приложения Jasmine обеспечивают полный доступ к дереву наследования, даже в режиме выполнения. Методы хранятся в базе тоже как объекты определенного класса, поэтому они так же могут переопределяться в режиме выполнения, не требуя закрытия базы. Аналогичным образом приложения могут динамически модифицировать и расширять методы и свойства объектов на уровне класса и экземпляра. Объектная модель позволяет дополнять базу данных Jasmine новыми типами объектов без использования каких бы то ни было реляционных принципов преобразования типа "blades", "cartridges" или "extenders". В этом просто нет необходимости. База данных Jasmine "понимает" хранящиеся в ней объекты точно так же, как реляционная база понимает свои текстовые или числовые поля. В большой степени эффективность системы Jasmine объясняется наличием в ней библиотек предопределенных и многократно используемых классов, содержащих методы и свойства.


    Эти классы обеспечивают широчайший набор функций, включая мощные служебные функции, такие как манипуляцию объектами и строками, обработку метаданных, управление наборами, сеансами и транзакциями, динамическую оптимизацию и многое другое. Имеется также мощная библиотека классов мультимедиа и библиотека классов SQL, позволяющая приложениям Jasmine обращаться к базам OpenIngres, Oracle, Sybase, Informix, Microsoft SQL Server, CA-IDMS, CA-Datacom, VSAM и другим. "Мы выбрали Jasmine в качестве основной СУБД для данных о нашей продукции по двум причинам: потому что это лучшая из объектно-ориентированных систем и она полностью поддерживает Web." Рамеш Редди (Ramesh Reddi), президент Infopike Наличие библиотек классов SQL в объектно-ориентированной системе позволяет легко работать с данными в существующих базах. Благодаря этому, пользователи могут смело переходить на объектную технологию, не принося в жертву вложения, сделанные ими в существующие системы. Библиотеки SQL также избавляют от необходимости переноса данных или приложений в объектную среду. Преимущества такой интеграции признают не только пользователи СА, но и независимые эксперты. Разработчики могут создавать дополнительные библиотеки классов для поддержки нестандартных типов данных или для полной интеграции с приложениями, данными и процессами, которые функционируют вне среды Jasmine. Библиотеки классов поддерживают любые источники информации, а запросы к данным за пределами Jasmine осуществляются с помощью методов. Работая на обычных персоналках, связанных с высокопроизводительным сервером базы данных, приложение Jasmine не занимает много локальных ресурсов. Производительность достигается за счет того, что методы выполняются на более мощном сервере. Так как методы встроены внутри данных, хранящихся в базе Jasmine, внешние приложения не нужно переписывать при изменении бизнес-логистики. Надежная платформа В отличие от многих других объектных СУБД, которые разрабатывались для академических или экспериментальных целей, система Jasmine с самого начала предназначалась для использования в бескомпромиссном мире бизнеса.


    Поэтому она содержит в себе все функции, необходимые для промышленной эксплуатации, обеспечивая высокую степень безопасности, целостности и производительности. В СА накоплен богатый опыт по обеспечению больших и малых предприятий системами, способными работать безотказно. Весь этот опыт был использован и при разработке Jasmine. Первая версия этого продукта поддерживает SMP, онлайновое резервирование и восстановление, функции безопасности, полное управление транзакциями и распределенное хранение объектов. Сервер Jasmine управляет блокировкой записей и в целях повышения производительности поддерживает как совместную (для чтения), так и монопольную (для записи) блокировку. Имеются полноценные службы резервного копирования и восстановления, которые, естественно, могут работать при функционирующей базе данных. Кроме того, Jasmine содержит встроенную технологию защиты от сбоев носителей, позволяющую полностью восстановить базу в случае аппаратных сбоев носителей. Jasmine - подлинно объектная СУБД и, будучи таковой, она наиболее эффективна в тех сферах, где требуется точное отображение характера деятельности предприятия. Если реляционная база может легко "загнать" себя попытками соединения многочисленных реляционных таблиц и полей, то с Jasmine такого не произойдет никогда. Встроенные средства навигации по объектам позволяют Jasmine эффективно работать в среде Интернет или интранет, особенно в таких приложениях, где интенсивно используются сложные модели поведения при взаимодействии с пользователем, мультимедийные данные и другие характеристики "нового поколения". Функции навигации вместе с автоматической оптимизацией запросов обеспечивают непревзойденную производительность базы данных Jasmine. Многонитевая архитектура и поддержка SMP означают, что практически не может быть ограничений на количество пользователей при работе Jasmine в типичных бизнес-приложениях в среде Интернет или по традиционной двухуровневой схеме. Объекты Jasmine могут быть распределены по множеству дисков, что делает возможным использование этой системы в больших высокопроизводительных базах.


    К тому же, сервер Jasmine для повышения производительности использует особые методы манипуляции объектами, которые позволяют передавать по сети только нужные клиенту объекты. Jasmine поддерживает кэширование и со стороны сервера, и со стороны клиента. Кэшированию подвергаются как "объекты классов" (метаданные), так и объекты экземпляров (данные). Для ускорения передачи мультимедийных данных в среде Web используются такие технологии, как итерационный доступ, интеллигентное кэширование и эвристическое сжатие данных. СУБД Jasmine - построение виртуальных предприятий
    Чтобы добавить свойство аудио (файл WAV), достаточно перетащить файл с рабочего стола на свойство объекта
    Jasmine поставляется с полным набором интегрированных служб администрирования и управления, позволяющими легко выполнять резервное копирование и восстановление базы, устанавливать правила безопасности. Имеются также графические утилиты, позволяющие не только просматривать и выбирать содержимое в базе, но также редактировать, добавлять элементы в базу и даже формировать запросы. Добавление объекта или класса в базу Jasmine осуществляется лишь несколькими движениями мыши. Сложные данные (изображения, аудио, видео и другие типы файлов) попадают в базу путем их простого перетаскивания с рабочего стола в окно Jasmine. Существует распространенное заблуждение, что объектные СУБД якобы неспособны выполнять сложные запросы. В Jasmine запрос - сущий пустяк; нажав пару раз кнопкой мыши, вы получаете мощный и, вместе с тем, легко формируемый запрос. Computer Associates прекрасно понимает, что требования к информационной системе увеличиваются вместе с ростом предприятия. Свойственная Jasmine открытость, масштабируемость и поддержка различных платформ серверов делают эту СУБД превосходным решением как для небольших киосков в Интернет, так и для гигантских хранилищ информации. А многонитевые технологии управления базой и использование методов на сервере обеспечивают превосходную производительность любому приложению Jasmine. СУБД Jasmine - построение виртуальных предприятий
    Условия запроса включают: имя поля, логический оператор и значение поля.


    Интегрированная простая среда разработки Разработчикам современных приложений приходится не только "писать коды". В их задачу также входят конструирование сцен и web-страниц, определение логики приложения, интеграция логики с существующими данными, подготовка готового приложения к установке. Этот процесс напоминает создание музыкального произведения: различные партии и мелодии, исполняемые на разных инструментах, должны быть саранжированы в законченное творение, подчиняющееся одному дирижеру. Среда разработки Jasmine Application Development Environment (JADS) поддерживает обычные операции перетаскивания мышью при создании мультимедийных приложений и манипуляции с данными в базе Jasmine. Простой для понимания интерфейс JADS, во многом сходный с Microsoft Windows Explorer, позволяет любому программисту быстро создать законченное приложение Jasmine, включая конструирование сцен и прототипа, разработку и тестирование приложения, формирование базы данных и внедрение конечного продукта. В среде JADS программист работает со "сценами". Сцена - это готовый экран приложения или Web-страница. Интеллектуальные редакторы и броузеры позволяют легко перетаскивать на экран сцены объекты, классы или запросы и определять их свойства и правила взаимодействия. Среда JADS позволяет также:
  • Выполнять функции администрирования базы данных - например, добавлять классы и объекты.
  • Просматривать и изменять существующие классы и объекты.
  • Просматривать и редактировать свойства классов и объектов.
  • Просматривать, изменять и создавать методы и запросы.
    "С помощью Jasmine нам удалось сделать великолепный прототип мультимедийного приложения для дилеров. Он приковывает взгляд покупателей, и они могут на основе стандартного изображения машины буквально своими руками создать автомобиль своей мечты. Простыми движениями мыши можно выбрать любой аксессуар и сразу же увидеть, как это будет выглядеть на машине. В результате у клиента появляется желание вместе с самим автомобилем купить для него и родные аксессуары." Кевин Смит (Kevin Smith), главный системный менеджер Toyota в Австралии Добавление графических изображений при разработке приложения происходит легко, благодаря функциям перетаскивания JADS. СУБД Jasmine - построение виртуальных предприятий
    Выборочное отображение объектов на экране также осуществляется в JADS без особых усилий, благодаря редактору запросов Jasmine. Computer Associates

    Сергей Кузнецов

    Тел./факс (095) 937-4850

    URL:

    | |

    СУБД Teradata для OC UNIX


    СУБД Teradata для OC UNIX     С объявлением выпуска СУБД Teradata для ОС UNIX на машине WorldMark 5100 начинается самый драматический этап в истории постоянного совершенствования продукта, со времен первого выпуска в 1984 году. С появлением СУБД Teradata для ОС UNIX на машине WorldMark 5100 были сняты все ограничения, накладываемые мощностью аппаратных платформ, таким образом были полностью реализованы возможности архитектуры СУБД Teradata. Использование СУБД Teradata для ОС UNIX сразу же улучшило соотношение цена/производительность в три раза по сравнению с системой 3600. Система включает: автоматическое добавление/удаление процессоров при почти 100%-ой степени надежности системы; непрерывную масштабируемость от SMP через кластерные системы к MPP; поддержку дисковых массивом через шину SCSI и новую масштабируемую межпроцессорную шину (BYNET). В системе реализованы: виртуальные процессоры; 20-кратное увеличение хэш-корзин (hash buckets) для поддержки баз данных объемом свыше 100ТБ; работа с данными в блоках от 4КБ до 32 КБ, наличие доли свободного пространства в блоках данных и возможность освобождения страниц памяти, используемые для значительного улучшения работы систем с переменной нагрузкой; использование уже откомпилированных шагов по выполнению SQL запросов; автоматическое восстановление фрагментации; глобальное планирование приоритетов; локальная журналирование измененных строк; настраиваемые пользователем размеры кэша для наборов данных; увеличенные размеры кэша для поддержки большинства сложных SQL-запросов к промышленным базам данных; улучшенные формулы оптимизации запросов; улучшенная обработка битовых образов (bit maps); обработка ситуаций полного отключения питания; поддержка гигабайтов энергонезависимой памяти в системе; более быстрый доступ к данным по значению неуникального первичного индекса; более быстрая система передачи сообщений между процессами; и, наконец, увеличенная производительность при распределении строк. Завтра И это только начало. Дальнейшие усовершенствования возможностей, функций, производительности и готовности СУБД Teradata во второй половине 90-х годов будут идти в ускоренном режиме.
    Соединения BYNET, мощность систем NCR WorldMark и базовая архитектура параллельного программного обеспечения позволят СУБД Teradata сохранить и укрепить позиции лидера в области промышленных реляционных СУБД, систем поддержки принятия решений и приложений для хранилищ данных. Архитектура программного обеспечения СУБД Teradata Секрет мощности СУБД Teradata кроется в ее архитектуре. Архитектура Teradata уникальна в своем роде. Разработанная для поддержки очень больших баз данных (Very Large Databases - VLDB), с которыми работают различные приложения по поддержке принятия решений (Decision Support - DSS) и приложения хранилищ данных (Data Warehousing - DW), СУБД Teradata построена на архитектуре "ничего не разделяется", с тщательно проработанным многомерным параллелизмом. Никакая другая СУБД в мире не может сравниться по мощности с СУБД Teradata. В архитектуре Teradata нет ничего однопотокового. При проектировании любых особенностей или утилит всегда принимался во внимание аспект параллелизма. С появлением версии СУБД Teradata для ОС UNIX был сделан значительный скачок вперед. Теперь Teradata работает на 32-х битовых современных машинах NCR серии WorldMark, 4700, 5150 и 5100. В системе параллельно выполняются все SQL операторы, форматирование, восстановление, загрузка и извлечение данных, управление приоритетами, инсталляция и обновление программного обеспечения, отладка, управление производительностью, доступ к словарям, блокировки, соединения таблиц, и все остальные задачи. Архитектура Teradata достаточно быстро расширяется, в то время как конкуренты при проектировании своих систем преодолевают каждый 100-гигабайтный барьер, и их системы никогда не смогут выдержать реальную нагрузку хранилищ данных.
    | |

    СУБД Teradata® для ОС UNIX®

    Константин Лисянский, Дмитрий Слободяников, NCR
    Постоянное совершенствование     Компания Teradata была основана в 1979 году, как дочерняя фирма компании Citicorp Advanced Technology Group. Продукт данной фирмы был разработан специально для непрерывной обработки больших объемов данных. В 1984 году фирма Teradata выпустила первые системы массивно-параллельной обработки (massively parallel processing - MPP) - специализированный компьютер для баз данных первой модели (DBC Model 1). Teradata первой вышла на рынок MPP систем, опередив своих конкурентов более чем на десять лет. Начиная с того времени компания Teradata, а теперь и компания NCR (в 1991 году компания NCR купила компанию Teradata) выпускает один из лучших в мире продуктов для систем поддержки принятия решений и хранилищ данных. 80-ые годы Первая система Teradata отвечала архитектуре программного обеспечения "ничего не разделяется" ("Shared Nothing") и функционировала на соответствующей аппаратной платформе. В системе были реализованы : интеллектуальная межпроцессорная шина YNET; связующие каналы с мэйнфреймами; механизм защиты данных от сбоев (Fallback); мощный оптимизатор, оценивающий относительную "стоимость" выполнения SQL запроса, с возможностью выдачи подробных сведений о том, как выполнялся запрос. Все основные операции с данными выполнялись параллельно. Распараллеливались следующие операции и утилиты : INSERT, SELECT; UPDATE, DELETE; Nested Loop Join; Sort Merge Join; Hash Merge Join, архивация/восстановление данных; утилиты по загрузке данных; загрузчик программного обеспечения. К 90-му в году в СУБД Teradata были реализованы следующие возможности: устоявшиеся типы данных, соединения по локальной сети, кэширование шагов синтаксического разбора SQL запросов, объявляемые приоритеты, совместимость с базами данных DB2 и 10 уровней блокировок. Дополнительные, полностью распараллеленные возможности включали в себя : соединение операций по удалению записей (Delete Join), соединение операций по обновлению записей (Update Join), журналирование и утилиту параллельного обновления данных с возможностью обновления и вставки (UPSERT).
    На аппаратных платформах DBC третьего поколения было достигнуто двукратное улучшение соотношения цена/производительность. В 80-ые годы непрерывное совершенствование СУБД Teradata стало неотъемлемой частью существования нашей компании. Размеры баз данных росли не по дням, а по часам. Первую систему, рассчитанную на объем данных в 100ГБ, Teradata выпустила в 1985, первую СУБД на 500ГБ - в 1987 году и, наконец, первую СУБД на 700 ГБ - в 1989 году. Тесты подтвердили, что мощность СУБД практически линейно зависит от числа процессоров, при увеличении числа процессоров до 300. В 1986 году журнал Forbes Magazine присудил продукту Teradata DBS награду "Продукт года", а в 1990 году в журнале INC Teradata была названа самой быстро развивающейся компанией в Америке. Начало 90-х годов Постоянное совершенствование продолжалось и в 90-ые годы, были добавлены следующие возможности : Teradata Manager (Клиентское ПО, предназначенное для администрирования СУБД с удаленного ПК, работающего под ОС Windows 95/NT), Диспетчер запросов к базам данных (Database Query Manager), параллельная утилита экспорта данных, разрешен доступ к таблицам БД во время архивации, увеличена в 20 раз скорость восстановления узлов после сбоев, введены поддержка дисковых массивов RAID, параллельные внешние соединения, а также поддержка запросов, связанных с многомерным анализом (OLAP), для оптимизации которых используется соединения таблиц по типу Звезда или Снежинка и параллельный оператор Hash Star Join. В 1991, когда был представлен компьютер DBC четвертого поколения, Electronic Business назвал компанию Teradata "самой быстро растущей компанией в области электроники". В 1992 году была выпущена первая система, оперирующая с 1 терабайтом данных. В 1993 году, согласно сведениям Smaby Group, доля NCR на рынке CPP составляла 80%. В 1994 году была выпущена первая система, работающая с несколькими терабайтами данных, и группа Gartner Group назвала компанию NCR "Лидером в параллельной промышленной обработке данных".


    Опрос пользователей, проведенный в 1995 фирмой IDC и опубликованный в Computerworld, показал, что наша компания является компанией № 1 в области массивно-параллельной обработки. В 1997 году по результатам исследования проведенного компанией IDC по итогам 1996 года компания NCR занимает 50.5% рынка хранилища данных по поставкам и 40.9% по доходам по сравнению с ближайшими конкурентами DEC (поставки 16.8%, доходы 15.4) и IBM (поставки 10.1%, доходы 18.9%) соответственно. Сегодня Сегодня Teradata - единственный продукт, поддерживающий настоящие хранилища данных объемом свыше 500 ГБ и позволяющий реализовать системы с объемом пользовательских данных свыше 1 ТБ (1 триллион байтов). На СУБД Teradata реализована самое большое в мире промышленное хранилище данных с общим объемом в 24ТБ. Teradata является "сердцем" хранилищ данных таких крупнейших в мире компаний, как AT&T, Sprint, British Telecom, Swedish Post, Australian Telecom, Bank of America, Chemical Bank, Fidelity Investments, Proctor and Gamble, WalMart, Kmart, Sears, Otto Versand, Delta Airlines, Qantas, USAir и American Airlines, и это далеко не полный список. У одного из наших клиентов (не самого крупного) работает машина системы 3600, которая за день обрабатывает: 800000 "OLTP"-транзакций от 7500 пользователей со временем отклика меньше секунды; 2000 "OLCP"-транзакций от 400 пользователей с объемом данных до 70МБ на транзакцию и временем отклика от долей секунды до 20 минут; 40 сложных "нерегламентированных запросов DSS" от 6 пользователей-аналитиков; а также 25МБ транзакций, связанных с партиями товара, в базе данных объемом 750ГБ, содержащей 1300 таблиц. В самой большой таблице содержится 2.4 миллиарда строк. В двух других таблицах содержится по 300 миллионов строк, а в большинстве таблиц содержится от миллиона до 10 миллионов строк. Система работает 7 дней в неделю, 24 часа в сутки.
    | |

    WebSpeed2.0 - средства разработки

    Ольга Твердова, CSBI EE
    Progress совершенствует решение онлайновых бизнес-транзакций в режиме реального времени. Компания Progress Software (г. Бедфорд, США) - один из ведущих мировых производителей промышленных СУБД и средств разработки крупных информационных систем - летом 1996г. выпустил новую серию продуктов для создания информационных систем для Internet. Новый продукт от Progress оказался традиционно качественным, и сразу был взят на вооружение многими компаниями. В сентябре 1997 года Progress выпустил вторую версию продуктов WebSpeed, обзор которых мы вам предлагаем. Технология WebSpeed Одним из последних технологических достижений является Internet и средства, позволяющие вести разработку информационных приложений, ориентированных на транзакционную обработку через Internet/Intranet. Это один из наиболее эффективных путей по созданию информационных приложений, позволяющих пользователю, имея лишь простейшую клиентскую часть - броузер, работать с распределенными базами данных различных форматов, обеспечивать поддержку сложных транзакций и выполнение бизнес-логики на Internet-сервере. Транзакционная обработка подразумевает сохранение контекста данных, результатов предыдущих запросов, значений переменных для конкретного клиента при некоторой последовательности действий, и откат значений при заданных условиях. Так как при работе в среде Internet клиент не поддерживает постоянной связи с Web-сервером, в информационной системе должны быть реализованы специальные механизмы поддержки сессионных бизнес-транзакций. В основе технологии WebSpeed лежит наличие средств разработки и средств запуска приложений под Internet, выпускаемых компанией Progress Software Corp. Приложения, написанные на хорошо зарекомендовавшем себя языке 4GL Progress, запускаются через Internet/Intranet с клиентских компьютеров, оснащенных только лишь средствами доступа в Internet и Internet-броузером. Технология WebSpeed включает в себя два этапа - этап разработки и отладки приложения и этап его установки и запуска в промышленную эксплуатацию. Разработка приложения WebSpeed2.0 - средства разработки

    1. Приложения могут создаваться как локально, так и удаленно, т.к. средства разработки запускаются через любой Web-браузер, поддерживающий JavaScript. Разработка приложения начинается с создания интерфейсных HTML-страниц при помощи любого предназначенного для этих целей средства или текстового редактора, например Hot MetalPro или Microsoft Front Page. Полученные при этом страницы сохраняются в HTML-формате и используются в дальнейшем Транзакционным Сервером в качестве шаблонов при динамической генерации результатов запросов пользователей. Большое количество волшебников позволяют быстро создавать все типичные бизнес-объекты (отчеты, формы, таблицы, навигационные панели и др.). 2. При помощи продукта WebSpeed Workshop осуществляется связь между полями форм/шаблонов созданных HTML-файлов и таблицами и полями СУБД, с которыми будет работать приложение. Здесь же добавляется логика, связанная с данными полями и реализуемая на 4GL Progress, SQL или JavaScript. Начало и конец транзакций определяются в Progress с помощью специальных команд, запускающих транзакционные механизмы. Результат в виде процедур на соответствующем языке сохраняется в том же HTML-файле, который будет в дальнейшем исполняться непосредственно на WEB-сервере Транзакционным Агентом. 3. HTML-шаблоны тестируются и компилируются. На этом этапе разработка приложения завершена и можно переходить непосредственно к эксплуатации информационной системы. Эксплуатация приложения WebSpeed2.0 - средства разработки
    Транзакционный сервер WebSpeed работает под Windows NT 3.51 и выше (Intel и Digital Alpha), Digital Unix, IBM AIX, Sun Solaris (SPARC), HP-UX, SCO UnixWare и с любым Web-сервером, совместимым с ISAPI, NSAPI или CGI 1.1 интерфейсом. После размещения и отладки приложения на WEB-сервере процедура взаимодействия клиентов с приложением выглядит следующим образом: 1. На клиентской части запускается любой HTML-броузер v2.0 или выше, пользуясь которым пользователь при помощи URL-запроса выходит на WEB-сервер, с размещенным на нем приложением. 2.


    На WEB- сервере запускается транзакционный сервер WebSpeed, который запускает Транзакционный Брокер. 3. Запрос от клиентской машины через оптимизированный API-интерфейс перехватывается Транзакционным Брокером, который в ответ на данный запрос запускает Транзакционного Агента как отдельный процесс Progress. Тот в свою очередь и исполняет разработанное приложение. Так как собственно приложение состоит из HTML-шаблонов и процедур на 4GL Progress, то оно способно осуществлять доступ и транзакционную обработку по любым, поддерживаемым Progress распределенным источникам данных. 4. Результат обработки запроса совместно с HTML-шаблонами передается на Генератор Страниц, который динамически генерирует HTML-страницу, содержащую требуемые данные. 5. HTML-страница передается на клиентскую часть по протоколу TCP/IP. Далее процедура, описанная в пп. 1-5 повторяется. Выводы К числу преимуществ реализации подхода, предложенного Progress Software Corp., для разработки информационных систем, ориентированных на работу через Internet/Intranet, следует отнести следующее:
  • Приложения для Internet создаются на 4GL Progress, традиционно сильном языке для архитектур Хост/Терминал, каковой, по сути, и является среда Internet. Транзакции, инициируемые клиентской машиной, могут включать в себя бизнес-логику и обработку данных из многих СУБД одновременно, причем различных форматов.
  • Встроенная поддержка транзакционных механизмов позволяет быстро разрабатывать сложные приложения.
  • Приложения для Internet создаются на 4GL Progress, с поддержкой всей многоплатформенности, присущей языку. Это позволяет сохранять инвестиции на разработку информационных систем при переходе на другие программно-аппаратные платформы.
  • Приложения, написанные при помощи Progress, легко интегрируются с уже готовыми системами, разработанными на Progress, Oracle, Informix, Sybase, Clipper, FoxPro и др.
  • Технология WebSpeed рентабельна с экономической точки зрения - на клиентской части необходимы лишь средства работы с Internet/Intranet и любой Internet-броузер.Нет необходимости в приобретении клиентской части Run-Time.
    CSBI EE (Компьютерные Системы для Бизнеса) - Санкт-Петербург

    Ольга Твердова

    Тел. (812) 293-0544, 293-0521, 293-3480

    Факс (812) 293-3513

    E-mail: ,

    | |

    Совместное применение новых информационных технологий:

    Совместное применение новых информационных технологий:
  • Технология хранилищ данных и оперативной аналитической обработки
  • Технологии Web и Java
    позволит создать информационную инфраструктуру корпорации и упростить доступ к данным для оперативного анализа.
    Центр Информационных Технологий

    Москва, Ленинские горы, МГУ им. М.В. Ломоносова, 2-ой учебный корпус

    Тел.: (095) 932-9212, 932-9213, 939-0783

    Факс: 939-3670, 939-0805

    E-mail:

    URL:

    |

    Корпоративные базы данных - статьи

    Динамическая масштабируемая архитектура

    Архитектура сервера Informix-ODS получила название "динамическая масштабируемая
    архитектура" (DSA). Суть ее заключается в том, что одновременно выполняется относительно
    небольшое число серверных процессов (виртуальных процессоров, ВП), которые разделяют между
    собой работу по обслуживанию множества клиентов. По сравнению с более ранними моделями
    сервера INFORMIX, где для каждого клиента создавался индивидуальный серверный процесс,
    новая модель обладает рядом преимуществ:


  • снижение нагрузки на операционную систему (число серверных процессов
    невелико);
  • сокращение совокупной потребности клиентов в оперативной памяти;
  • снижение конкуренции при одновременном использовании системных
    ресурсов;
  • более рациональное по сравнению с ОС назначение приоритетов и
    планирование;

    для многопроцессорных платформ:


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

    Архитектуру Informix-ODS называют также многопотоковой. Для каждого клиента создается один
    или несколько потоков, т.е. подзадач, выполняемых в рамках одного из ВП. Потоки создаются
    также для выполнения внутренних задач сервера - ввода-вывода, журнализации,
    администрирования и др.

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

    ВП выбирают готовые к выполнению потоки из общей очереди, поэтому ни один из них не
    простаивает, если есть какая-либо работа по обработке запросов или управлению. Таким образом,
    обеспечивается сбалансированная загрузка доступных процессоров. Существенная экономия
    процессорного времени достигается за счет того, что переключение ВП с потока на поток
    выполняется значительно быстрее, чем переключение ОС с процесса на процесс.

    Определение Дэйта.

    Лучшее, на мой взгляд, определение распределенных баз данных (DDB) предложил Дэйт (C.J. Date)
    в . Он установил 12 свойств или качеств идеальной DDB:


  • Локальная автономия (local autonomy)
  • Независимость узлов (no reliance on central site)
  • Непрерывные операции (continuous operation)
  • Прозрачность расположения (location independence)
  • Прозрачная фрагментация (fragmentation independence)
  • Прозрачное тиражирование (replication independence)
  • Обработка распределенных запросов (distributed query processing)
  • Обработка распределенных транзакций (distributed transaction processing)
  • Независимость от оборудования (hardware independence)
  • Независимость от операционных систем (operationg system independence)
  • Прозрачность сети (network independence)
  • Независимость от баз данных (database independence)

    Локальная автономия

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

    Независимость от центрального узла

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

    Непрерывные операции

    Это качество можно трактовать как возможность непрерывного доступа к данным (известное "24
    часа в сутки, семь дней в неделю") в рамках DDB вне зависимости от их расположения и вне
    зависимости от операций, выполняемых на локальных узлах. Это качество можно выразить
    лозунгом "данные доступны всегда, а операции над ними выполняются непрерывно".

    Прозрачность расположения

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

    Прозрачная фрагментация

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

    Рассмотрим пример, иллюстрирующий оба типа фрагментации. Имеется таблица employee
    (emp_id, emp_name, phone), определенная в базе данных на узле в Фениксе. Имеется точно такая же
    таблица, определенная в базе данных на узле в Денвере. Обе таблицы хранят информацию о
    сотрудниках компании. Кроме того, в базе данных на узле в Далласе определена таблица
    emp_salary (emp_id, salary). Тогда запрос "получить информацию о сотрудниках компании" может
    быть сформулирован так:

    SELECT * FROM employee@phoenix, employee@denver ORDER BY
    emp_id

    В то же время запрос "получить информацию о заработной плате сотрудников компании"
    будет выглядеть следующим образом:

    SELECT employee.emp_id, emp_name, salary FROM employee@denver,
    employee@phoenix, emp_salary@dallas ORDER BY emp_id

    Прозрачность тиражирования

    Тиражирование данных - это асинхронный (в общем случае) процесс переноса изменений объектов
    исходной базы данных в базы, расположенные на других узлах распределенной системы. В данном
    контексте прозрачность тиражирования означает возможность переноса изменений между базами
    данных средствами, невидимыми пользователю распределенной системы. Данное свойство
    означает, что тиражирование возможно и достигается внутрисистемными средствами.

    Обработка распределенных запросов

    Это свойство DDB трактуется как возможность выполнения операций выборки над
    распределенной базой данных, сформулированных в рамках обычного запроса на языке SQL. То
    есть операцию выборки из DDB можно сформулировать с помощью тех же языковых средств, что
    и операцию над локальной базой данных. Например,

    SELECT customer.name, customer.address, order.number, order.date FROM
    customer@london, order@paris WHERE customer.cust_number = order.cust_number

    Обработка распределенных транзакций

    Это качество DDB можно трактовать как возможность выполнения операций обновления
    распределенной базы данных (INSERT, UPDATE, DELETE), не разрушающее целостность и
    согласованность данных. Эта цель достигается применением двухфазового или двухфазного
    протокола фиксации транзакций (two-phase commit protocol), ставшего фактическим стандартом
    обработки распределенных транзакций. Его применение гарантирует согласованное изменение
    данных на нескольких узлах в рамках распределенной (или, как ее еще называют, глобальной)
    транзакции.

    Независимость от оборудования

    Это свойство означает, что в качестве узлов распределенной системы могут выступать
    компьютеры любых моделей и производителей - от мэйнфреймов до "персоналок".

    Независимость от операционных систем

    Это качество вытекает из предыдущего и означает многообразие операционных систем,
    управляющих узлами распределенной системы.

    Прозрачность сети

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

    Независимость от баз данных

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

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

    Посмотрим, во что выливается некоторые наиболее важные свойства DDB, если рассматривать их
    практически.

    Стандартизация языка SQL

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

    В 1992 г. был принят новый стандарт SQL-92. Этот язык существенно более сложен, чем SQL-89, а
    конструкции SQL-92 специфицированы в стандарте существенно более полно. Первой компанией,
    которая объявила о соответствии своего продукта новому стандарту, была компания Oracle со
    своей седьмой версией (это произошло прямо в 1992 г.). Теперь и все остальные компании обещают
    вскоре выпустить продукты, соответствующие стандарту SQL-92.

    Кроме того, как это бывает всегда, производители стремятся добавить к своим продуктам
    качества, превышающие требования стандарта. Например, современные версии Oracle и Ingres
    содержат возможности определения тригеров (подробнее об этом см. ниже), в системе uniVerse
    компании VMark поддерживается расширенная ненормализованная реляционная модель и т.д.
    Другими словами, компании стремятся смотреть в будущее, предвидя требования следующего
    стандарта SQL (его условно называют SQL-3; ожидалось принятие этого стандарта в 1995 г., но
    теперь уже говорят про 1997 г.).

    Целостность данных



    В DDB поддержка целостности и согласованности данных, ввиду свойств 1-2, представляет собой
    сложную проблему. Ее решение - синхронное и согласованное изменение данных в нескольких
    локальных базах данных, составляющих DDB - достигается применением протокола двухфазной
    фиксации транзакций. Если DDB однородна - то есть на всех узлах данные хранятся в формате
    одной базы и на всех узлах функционирует одна и та же СУБД, то используется механизм
    двухфазной фиксации транзакций данной СУБД. В случае же неоднородности DDB для
    обеспечения согласованных изменений в нескольких базах данных используют менеджеры
    распределенных транзакций. Это, однако, возможно, если участники обработки распределенной
    транзакции - СУБД, функционирующие на узлах системы, поддерживают XA-интерфейс,
    определенный в спецификации DTP консорциума X/Open. В настоящее время XA-интерфейс имеют
    CA-OpenIngres, Informix, Microsoft SQL Server, Oracle, Sybase.

    Если в DDB предусмотрено тиражирование данных, то это сразу предъявляет дополнительные
    жесткие требования к дисциплине поддержки целостности данных на узлах, куда направлены
    потоки тиражируемых данных. Проблема в том, что изменения в данных инициируются как
    локально - на данном узле - так и извне, посредством тиражирования. Неизбежно возникают
    конфликты по изменениям, которые необходимо отслеживать и разрешать.

    Использование мультипроцессорных организаций

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

    Однако с появлением на рынке мультипроцессорных симметричных аппаратных архитектур,
    производители СУБД были вынуждены пересмотреть организацию своих серверов, допустив в них
    внутреннюю параллельность. Естественно, это требует очень основательного перепроектирования
    системы с ее существенным усложнением. Заметим, что в большинстве случаев компании пошли на
    это после появления в ОС UNIX механизма "легковесных" процессов (threads).

    О серьезности этой работы говорит тот факт, что, например, в компании Informix было
    образовано новое подразделение, занимающееся исключительно вопросами распараллеливания
    работы серверов.

    Разделяемая память

    Разделяемая память - это механизм операционной системы, на котором основано разделение
    данных между виртуальными процессорами и потоками сервера. Разделение данных
    позволяет:


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

    Управление разделяемой памятью реализовано таким образом, что ее фрагментация
    минимизируется, поэтому производительность сервера при ее использовании не деградирует с
    течением времени.

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

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

    Интеграция и интероперабильность

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

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

    Оптимизация дисковых операций

    Операции ввода-вывода, как правило, образуют наиболее медленную компоненту обработки баз
    данных. Поэтому от их реализации существенно зависит общая продуктивность

    сервера. Для В сервере Informix-ODS применяются следующие механизмы, которые способствуют
    оптимизации ввода-вывода и повышению надежности:


  • Собственное управление дисковой памятью;
  • Асинхронный ввод-вывод;
  • Опережающее чтение.

    Прозрачность расположения



    Это качество DDB в реальных продуктах должно поддерживаться соответствующими
    механизмами. Разработчики СУБД придерживаются различных подходов. Рассмотрим пример из
    Oracle. Допустим, что DDB включает локальную базу данных, которая размещена на узле в
    Лондоне. Создадим вначале ссылку (database link), связав ее с символическим именем
    (london_unix), транслируемым в IP-адрес узла в Лондоне.

    CREATE PUBLIC DATABASE LINK london.com CONNECT TO london_unix
    USING oracle_user_ID;

    Теперь мы можем явно обращаться к базе данных на этом узле, запрашивая, например, в
    операторе SELECT таблицу, хранящуюся в этой базе:

    SELECT customer.cust_name, order.order_date FROM customer@london.com,
    order WHERE customer.cust_number = order.cust_number;

    Очевидно, однако, что мы написали запрос, зависящий от расположения базы данных,
    поскольку явно использовали в нем ссылку. Определим customer и customer@london.com как
    синонимы:

    CREATE SYNONYM customer FOR customer@london.com;

    и в результате можем написать полностью независимый от расположения базы данных
    запрос:

    SELECT customer.cust_name, order.order_date FROM customer, order WHERE
    customer.cust_number = order.cust_number

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

    CREATE SYNONYM customer FOR client@central:smith.customer

    означает, что любое обращение к таблице customer в открытой базе данных будет
    автоматически переадресовано на компьютер central в базу данных client к таблице customer.
    Оказывается возможным переместить таблицу из одной базы данных в другую, оставив в первой
    базе ссылку на ее новое местонахождение, при этом все необходимые действия для доступа к
    содержимому таблицы будут сделаны автоматически.

    Мы уже говорили выше о горизонтальной фрагментации. Рассмотрим пример иерархически
    организованной DDB, на каждом из узлов которой содержится некоторое подмножество записей
    таблицы customer:

    Прозрачность расположения
    С помощью CREATE SYNONYM можно определить, например, таблицу структуры customer,
    в которой хранятся строки с записями о клиентах компании, находящихся в Японии:

    CREATE SYNONYM japan_customer FOR customer@hq.sales.asia.japan

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

    Обработка распределенных запросов



    Выше уже упоминалось это качество DDB. Обработка распределенных запросов (Distributed Query
    -DQ) - задача, более сложная, нежели обработка локальных и она требует интеллектуального
    решения с помощью особого компонента - оптимизатора DQ. Обратимся к базе данных,
    распределенной по двум узлам сети. Таблица detail хранится на одном узле, таблица supplier - на
    другом. Размер первой таблицы - 10000 строк, размер второй - 100 строк (множество деталей
    поставляется небольшим числом поставщиков). Допустим, что выполняется запрос:

    SELECT detail_name, supplier_name, supplier_address
    FROM detail, supplier
    WHERE detail.supplier_number = supplier.supplier_number;

    Результирующая таблица представляет собой объединение таблиц detail и supplier,
    выполненное по столбцу detail.supplier_number (внешний ключ) и supplier.supplier_number
    (первичный ключ).

    Данный запрос - распределенный, так как затрагивает таблицы, принадлежащие различным
    локальным базам данных. Для его нормального выполнения необходимо иметь обе исходные
    таблицы на одном узле. Следовательно, одна из таблиц должна быть передана по сети. Очевидно,
    что это должна быть таблица меньшего размера, то есть таблица supplier. Следовательно,
    оптимизатор DQ запросов должен учитывать такие параметры, как, в первую очередь, размер
    таблиц, статистику распределения данных по узлам, объем данных, передаваемых между узлами,
    скорость коммуникационных линий, структуры хранения данных, соотношение
    производительности процессоров на разных узлах и т.д. От интеллекта оптимизатора DQ впрямую
    зависит скорость выполнения распределенных запросов.

    Межоперабельность



    В контексте DDB межоперабельность означает две вещи. Во-первых, - это качество, позволяющее
    обмениваться данными между базами данных различных поставщиков. Как, например,
    тиражировать данные из базы данных Informix в Oracle и наоборот? Известно, что штатные
    средства тиражирования в составе данной конкретной СУБД позволяют переносить данные в
    однородную базу. Так, средствами CA-Ingres/Replicator можно тиражировать данные только из
    Ingres в Ingres. Как быть в неоднородной DDB? Ответом стало появление продуктов,
    выполняющих тиражирование между разнородными базами данных.

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

    Специальные подходы - это, например, использование шлюзов, позволяющее приложениям
    оперировать над базами данных в "чужом" формате так, как будто это собственные базы данных.
    Вообще, цель шлюза - организация доступа к унаследованным (legacy) базам данных и служит для
    решения задач согласования форматов баз данных при переходе к какой-либо одной СУБД. Так,
    если компания долгое время работала на СУБД IMS и затем решила перейти на Oracle, то ей
    очевидно потребуется шлюз в IMS. Следовательно, шлюзы можно рассматривать как средство,
    облегчающее миграцию, но не как универсальное средство межоперабельности в распределенной
    системе. Вообще, универсального рецепта решения задачи межоперабельности в этом контексте не
    существует - все определяется конкретной ситуацией, историей информационной системы и массой
    других факторов. DDB конструирует архитектор, имеющий в своем арсенале отработанные
    интеграционные средства, которых на рынке сейчас очень много.

    Технология тиражирования данных



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

    Тиражирование данных - это асинхронный перенос изменений объектов исходной базы данных в
    базы, принадлежащим различным узлам распределенной системы. Функции DR выполняет, как
    правило, специальный модуль СУБД - сервер тиражирования данных, называемый репликатором
    (так устроены СУБД CA-OpenIngres и Sybase). В Informix-OnLine Dynamic Server репликатор
    встроен в сервер, в Oracle 7 для использования DR необходимо приобрести дополнительно к
    Oracle7 DBMS опцию Replication Option.

    Специфика механизмов DR зависит от используемой СУБД. Простейший вариант DR -
    использование "моментальных снимков" (snapshot). Рассмотрим пример из Oracle:

    CREATE SNAPSHOT unfilled_orders
    REFRASH COMPLETE
    START WITH TO_DATE ('DD-MON-YY HH23:MI:55')
    NEXT SYSDATE + 7
    AS SELECT customer_name, customer_address, order_date
    FROM customer@paris, order@london
    WHERE customer.cust_name = order.customer_number AND
    order_complete_flag = "N";

    "Моментальный снимок" в виде горизонтальной проекции объединения таблиц customer и
    order будет выполнен в 23:55 и будет повторятся каждые 7 дней. Каждый раз будут выбираться
    только завершенные заказы.

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

    Детали тиражирования данных полностью скрыты от прикладной программы; ее
    функционирование никак не зависят от работы репликатора, который целиком находится в


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

    Синхронное обновление DDB и DR-технология - в определенном смысле антиподы. Краеугольный
    камень первой - синхронное завершение транзакций одновременно на нескольких узлах
    распределенной системы, то есть синхронная фиксация изменений в DDB. Ee "Ахиллесова пята" -
    жесткие требования к производительности и надежности каналов связи. Если база данных
    распределена по нескольким территориально удаленным узлам, объединенным медленными и
    ненадежными каналами связи, а число одновременно работающих пользователей составляет сотни
    и выше, то вероятность того, что распределенная транзакция будет зафиксирована в обозримом
    временном интервале, становится чрезвычайно малой. В таких условиях (характерных, кстати, для
    большинства отечественных организаций) обработка распределенных данных практически
    невозможна.

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

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


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

    DR-технология данных не лишена недостатков. Например, невозможно полностью исключить
    конфликты между двумя версиями одной и той же записи. Он может возникнуть, когда вследствие
    все той же асинхронности два пользователя на разных узлах исправят одну и ту же запись в тот
    момент, пока изменения в данных из первой базы данных еще не были перенесены во вторую. При
    проектировании распределенной среды с использованием DR-технологии необходимо
    предусмотреть конфликтные ситуации и запрограммировать репликатор на какой-либо вариант их
    разрешения. В этом смысле применение DR-технологии - наиболее сильная угроза целостности
    DDB. На мой взгляд, DR-технологию нужно применять крайне осторожно, только для решения
    задач с жестко ограниченными условиями и по тщательно продуманной схеме, включающей
    осмысленный алгоритм разрешения конфликтов.

    Архитектура клиент-сервер, традиционные решения

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

    Архитектура клиент-сервер, традиционные решения
    На рисунке 1 мы видим традиционное решение в архитектуре файл-сервер. Недостатки очевидны:
    удаленный разделяемый винчестер предполагает меньшую надежность данных, большой сетевой
    траффик.

    Архитектура клиент-сервер, традиционные решения
    На рисунке 2 мы видим традиционное решение в архитектуре клиент-сервер. Клиентские
    приложения обращаются к серверу БД (например, InterBase, Oracle, Informix, Sybase, MS SQL через
    родные линки или другие (уже через ODBC)). Логика клиентского приложения может быть
    написана на Paradox, dBase, Delphi или С/С++. Cледует еще раз отметить, что при этом все
    взаимодействие с БД ведется через родные линки компаний-производителей, инкапсулированные
    механизмом IDAPI - универсальным механизмом доступа к данным, который предлагает компания
    Borland. При этом клиентское приложение может напрямую запрашивать у сервера данные и
    оперирует понятиями запросов, транзакций и таблиц. Только в Delphi 2.0 появилась возможность
    работы не напрямую, а через монитор транзакций (Taxedo, Encina - см. Рисунок 3).

    Архитектура клиент-сервер, традиционные решения

    Что такое объектно-реляционная СУБД?

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

    В настоящее время существуют две преобладающие архитектуры: РСУБД и ОСУБД, лишь
    частично решающие проблемы управления сложными данными:

    РСУБД: нет сложных типов данных.

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

    ОСУБД: нет стандартного языка запросов.

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

    Интегрированная база данных - констатация идеи

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

    Было сформулировано принципиальное требование отделения программ от интегрированных
    данных. Этот принцип направлен на отчуждение данных в качестве ресурса предприятия, важен
    также тем, что консервативные по характеру данные отделялись от прикладных программ,
    которые могли часто подвергаться изменениям.

    Другой важной проблемой проектирования БД явилось обеспечение нужных эксплуатационных
    параметров, таких как объем внешней памяти или время выполнения различных операций.
    Известны и другие требования. Например, информация не должна потеряться не только из-за
    отказов оборудования, но и вследствие ошибки пользователя. Это отличается от того положения,
    при котором тот, кто решает некую задачу, сам и отвечает за сохранность данных для этой задачи.

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

    Национальные алфавиты и таблицы кодировок

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

    В России известно несколько Таблиц Кодировок альтернативная, основная, дополнительная. В
    операционных системах DOS, MS-WINDOWS, UNIX также используются различные Таблицы
    Кодировок. Рассмотрим как в Progress осуществляется описание, настройка и динамическое
    преобразование Таблиц Кодировок для различных операционных систем и оборудования.
    Описанный ниже алгоритм позволяет освободить разработчика от задач, связанных с
    локализацией продуктов и настройкой их на работу в конкретном операционном окружении, что
    значительно облегчает его работу и экономит время, необходимое на разработку и сопровождение
    программного продукта.

    Вся информация необходимая для настройки Таблиц Кодировок, в PROGRESS они называются
    кодовыми страницами, содержится в файле convmap.cp. Этот файл хранится во внутреннем
    формате PROGRESS, и создается специальной утилитой из обычного текстового файла
    convmap.dat.

    В данном файле хранится несколько специальных таблиц, двух типов - определения кодовых
    страниц и правил сортировки.


  • Для каждой кодовой страницы определяется таблица букв - ISALPHA, в которой указывается
    является ли символ буквой или нет (знак пунктуации, цифра и т.д.). Progress использует эту
    таблицу для проверки символов при вводе с определением формата. Таблица ISALPHA состоит из
    256 полей, пронумерованных от 0 до 255. Каждое поле соответствует одному символу кодовой
    таблицы. Если символ является буквой, то в соответствующем ему поле стоит значение 001. В
    противном случае значение поля равняется 000.

    Для каждого символа от 0 до 255, является ли он буквой или нет.
    В случае, если символ является
    буквой, в таблице 1 на соответствующему ему месте стоит код 001. В противном случае - 000. Тип
    таблицы указывает используется ли данная таблица для однобайтовой кодировки или нет.
    Значение TYPE 1 указывает, что данная таблица используется для однобайтовых кодировок.

    ====

    CodePAGE

    CODEPAGE-NAME "NEW1"

    TYPE "1"

    ISALPHA

    /*000-015*/ 000 000 000 000 000 000 000 000 000 000 000 000 000 000
    000 000

    /*016-031*/ 000 000 000 000 000 000 000 000 000 000 000 000 000 000
    000 000

    .

    .

    /*128-143*/ 001 001 001 001 001 001 001 001 001 001 001 001 001 001
    001 001

    .

    .

    /*240-255*/ 000 000 000 000 000 000 000 000 000 000 000 000 000 000
    000 000

    ENDTABLE

    ENDCODEPAGE

  • Следующие две таблицы - UPPERCASE-MAP и LOWERCASE-MAP, определяют правила
    преобразования прописных букв в заглавные и наоборот. Для каждой кодовой страницы
    возможно задание нескольких пар таких таблиц. Как правило, используется пара под названием
    BASIC. Эти таблицы используются как при вводе информации, так и при выполнении операторов
    LowerCase, CAPS и др.

  • Таблица преобразований кодовых страниц - CONVERT. Эти таблицы определяют правила
    перекодировок между двумя различными кодовыми таблицами. Таких таблиц может быть
    несколько, но обязательно должна существовать по крайней мере одна из них.

  • Для задания правил сортировки используется две таблицы CASE-SENSITIVE-SORT и CASE-
    INSENSITIVE-SORT. В первом случае вначале идут все заглавные буквы, а затем все прописные.
    Во втором случае порядок следования символов будет следующим "A", "a", "Б", "б" и т.д.

    После определения все этих таблиц необходимо запустить утилиту преобразования получившегося
    файла (convmap.dat) во внутренний формат Progress (convmap.cp).

    Proutil -C codepage-compiler ....\convmap.dat ....\convmap.cp

    После выполнения всех этих действий Вы уже можете использовать подготовленную Вами
    кодовую страницу. Для этого в стартовом файле необходимо указать значение параметра -
    convmap.

    Общая характеристика CADRE VantageTeam Builder

    CASE-технология (Computer Aided Software/System Engineering), как это и следует из названия,
    предполагает использование вычислительных средств в качестве инструмента для разработки и
    реализации крупных проектов информационных систем. В основе CASE - средств заложена, как
    правило, одна из традиционных (по крайней мере на Западе) методологий проектирования. Входящие
    в состав CASE - средств инструменты позволяют с той или иной степенью полноты реализовать
    соответствующие методы разработки и в той или иной степени контролируют правильность
    применения этих методов.

    VantageTeam Builder фирмы CADRE позволяет использовать метод структурного проектирования
    Yourdon'а с некоторыми дополнительными инструментами. В целом метод
    представляется весьма естественным и достаточно прост в освоении как разработчиком, так и
    заказчиком (предполагается ознакомление заказчика не только с готовой системой, но и с
    предварительными результатами проектирования на разных стадиях проекта) в силу ориентации на
    графическое представление всех результатов разработки.

    Общие сведения о современном состоянии

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

    Все это многообразие видов информационных систем и технологий становится возможным
    благодаря тому, что ADABAS обеспечивает поддержку следующих моделей и типов данных:


  • Не первая нормальная форма (NF2 - Non-First Normal Form)


    Эта модель данных (рис. 1)традиционна для ADABAS с 1969 года,
    когда он впервые вышел на рынок систем обработки данных, по ней большинство пользователей и
    знает эту СУБД. Его сегодняшнее название ADABAS C.


    Запись базы данных ADABAS C
    Простая группа Периодическая группа
    Общие сведения о современном состоянии
    		Общие сведения о современном состоянии
    Множественное поле
    Множественное поле периодической группы

    Распределенные базы данных

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

    Реляционные системы

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

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

    Цель методологии создания информационных систем

    Цель методологии создания информационных систем (ИС) заключается в организации процесса
    построения ИС и обеспечении управления этим процессом для того, чтобы гарантировать
    выполнение требований как к самой ИС, так и к характеристикам процесса разработки.
    Основными задачами, решение которые должна обеспечивать методология создания
    корпоративных ИС (вместе с соответствующим набором инструментальных средств) являются
    следующие задачи:


  • обеспечивать создание корпоративных ИС, отвечающих предъявляемым к
    ним требованиям по автоматизации деловых процессов и отвечающих целям и
    задачам организации;
  • гарантировать создание системы с заданным качеством в заданные сроки и
    в рамках бюджета;
  • поддерживать удобную дисциплину сопровождения, модификации и
    наращивания системы, чтобы ИС могла отвечать быстро изменяющимся
    требованиям работы компании;
  • обеспечивать создание корпоративных ИС, отвечающих требованиям
    открытости, переносимости и масштабируемости;
  • обеспечивать использование в разрабатываемой ИС задела в области
    информационных технологий, существующего в организации (ПО, баз данных,
    средств вычислительной техники, телекоммуникаций, технологий).

    Методология должна обеспечивать снижение сложности процесса создания ИС за счет полного и
    точного описания этого процесса и применения современных методов и технологий создания ИС
    на всем жизненном цикле ИС - от замысла до реализации.

    В 90-ые годы в мире произошли кардинальные изменения как на рынках товаров и услуг, так и в
    информационных технологиях (ИТ). Современные корпоративные ИС становятся основным
    фактором успешной работы корпораций на рынке. Для выполнения своего назначения они
    должны решать значительно более сложные задачи, чем раньше. В соответствии с высокой
    динамикой изменения ситуации на рынке становятся очень жесткими требования как к функциям,
    выполняемым ИС, так и к процессу создания ИС. Резко ужесточились требования ко времени
    разработки отдельных приложений и системы в целом. Появилась необходимость в изменении


    требований в процессе разработки с тем, чтобы система отвечала требованиям организации на
    момент конца разработки, а не на момент начала.

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

    Практика показывает, что для успешного создания сложных системы, к которым относятся
    корпоративные ИС, недостаточно иметь только современные платформы и средства, а прежние
    методологии создания ИС, созданные в 70 - 80-е годы и ориентированные на мэйнфрэймы и
    однородную среду, устарели и оказались непригодны в новых условиях. Согласно статистическим
    данным, собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994г,
    неудачными оказались более 30% проектов общей стоимостью более чем 80 миллиардов долларов.
    При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход
    средств составил 189% от запланированного бюджета. Анализ показал, что большинство неудач
    было связано с отсутствием или неправильным применением методологии проектирования ИС.

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


    создания корпоративных ИС. В этой области работают многие ведущие специалисты во всем мире.
    В 1994г в Великобритании был создан международный консорциум DSDM (Dynamic Systems
    Development Method), объединяющий более 100 ведущих фирм мира, который на постоянной
    основе разрабатывает проекты стандартов, методы и методологию быстрого создания приложений
    (ИС). В консорциуме участвуют и российские компании.

    Таким образом, с появлением инструментальных средств нового поколения роль методологии
    при создании ИС не только не снизилась, - она возросла. По данным опроса, проведенного в 1994
    г, большинство американских специалистов считают методологию, наряду с архитектурой клиент-
    сервер, двумя наиболее важными факторами для успешной разработки своих ИС.

    Сегодня в нашей стране недостаточно оценивается роль и значение методологии (в отличии от
    средств проектирования прикладного программного обеспечения). В предстоящие годы задача
    создания корпоративных ИС на базе современных методологий встанет перед многими
    отечественными организациями. (При этом заметим, что на Западе методологии по-прежнему
    считают стратегической продукцией. Многие из них представляют собой ноу-хау и по сей день.)

    Что нужно от баз данных для ответа на новые требования

    Покажем новые требования к корпоративным БД на примере двух аспектов создания новых
    корпоративных ИС (из более чем двух десятков видов работ, составляющих основу Н.С.П. - см.
    []):


  • Обеспечение максимальных возможностей для каждого работника, то есть
    поддержка выполнения всех бизнес-функций тем самым работником, который
    и получает конечный результат. Со стороны ИС, БД и СУБД для этого
    требуется:
  • обеспечение средств доступа ко всем необходимым данным с
    использованием распределенных БД, средств репликаций данных,
    управления событиями в данных и процессах обработки транзакций;
  • использование архитектуры и программных средств хранилища
    данных, средств Оперативной Аналитической Обработки Данных (OLAP),
    применение средств быстрой разработки приложений (RAD) для создания
    "ИС руководителя" (EIS), средств поддержки принятия решений (DSS) на
    основе хранилища данных, OLAP и RAD/EIS;
  • применение средств DSS на основе анализа БД прецедентов, а
    также методов логического вывода, нейронных сетей и нейрокомпьютеров, и
    др.;
  • предложение единого интерфейса пользователя для работы с
    разными компонентами данных и приложений, использование в этом
    интерфейсе средств, повышающих простоту поиска информации и
    обращения к конкретным прикладным функциям, например, функции
    геоинформсистем, гипертекстовые, естественного языка, речевого ввода.
  • Разработка концепции и структуры корпоративной базы данных для новой
    ИС, реализация структуры БД, предполагающая снятие (существенное
    уменьшение) ограничений на ее развитие, в том числе, при смене функций или
    функциональных компонентов обработки информации:
  • применение методов компонентного проектирования предметных БД
    как для операционных БД, так и для исторических БД хранилищ данных,
    архивов документов, гео-информационных и иных данных;
  • разработка процедур компонентного изменения корпоративной БД
    при изменении бизнес-процедур, видов деятельности, применяемых
    приложений и географического размещения предприятия;
  • постоянная актуализация понятийной модели деятельности
    предприятия для учета новых понятий, возникающих при изменении
    прикладных компонент на функционально сходные и при изменении видов
    деятельности предприятия, и построение на этой основе новых
    интерфейсов между компонентами ИС;
  • динамическое администрирование фрагментами распределенной
    корпоративной БД при изменении частоты их использования, при
    модификации их структуры и при изменении их размещения.

    Некоторые новые технические требования к базам данных можно получить из анализа в
    [].

    Список литературы

  • Кодд Е.Ф. Реляционная модель данных для больших совместно используемых банков
    данных. СУБД № 1, 1995, с. 145-160.
  • Chen P.P. The Entity-Relationship Model: Toward a Unified View of Data. ACM Transactions on
    Database Systems, vol.1., № 1, 1976.
  • Горин С.В., Тандоев А.Ю. Среда разработки приложений PowerBuilder. DBMS/Russian Edition,
    № 1, 1995.
  • Тандоев А.Ю. Архитектура продуктов клиент-сервер фирмы Sybase. СУБД № 1, 1995, с. 62-
    69.

    Сергей Викторович Горин

    Андрей Юрьевич Тандоев

    Фирма АлконсСофт

    тел. (095) 362-5138, 918-1380, 362-7443

    []
    []
    []

    Вошедшие в практику новые инструменты мастерской проектировщика

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

    В реальных разработках наиболее распространенных организационно-производственных ИС в
    большинстве случаев или в большей части объемов работ произошла замена средств разработки с
    SQL во включающем 3GL-языке или языка 4GL процедурного типа на языки и инструменты 4GL с
    оконным интерфейсом на основе управления через меню и с использованием элементов концепции
    объектно-ориентированного программирования (и сохранением возможностей выхода на SQL и
    процедурный язык).

    Возникли практически работающие стандарты de facto интероперабельной работы с данными, в
    первую очередь - стандарт ODBC.

    Мультиплатформенность стала нормой, многопротокольность коммуникаций для распределенных
    БД реализуется на основе стандартов и интероперабельных мониторов транзакций,
    поддерживается "интернационализация" хотя бы в части настроек на таблицы национальных
    кодировок данных.

    Вошли в практику новые структуры и типы данных, новые операции над данными:
    неформатированные элементы, полнотекстовые БД и их обработка, ГИС-данные, мультимедийные
    БД, гипертекстовые распределенные БД, распределенная обработка и обработка, доставляемая
    вместе с объектом на вход ИС. На практике наблюдаются шаги реальной интеграции упомянутых
    структур и операций.

    Меняется подход к выбору СУБД, в первую очередь - для проектирования корпоративных БД,
    эксплуатация и развитие которых планируется как минимум на несколько лет. Все более
    используются экономические основания и критерии для выбора СУБД (см. []).

    Объектная ориентация в проектировании БД здесь не рассматривается как уже реально
    существующий в практике новый инструмент Мастерской. (Не имеется в виду объектно-
    ориентированное программирование.) В настоящее время представляется обоснованным отнести
    такое проектирование все еще к направлениям исследований.

    К новым подходам в организации проектирования БД

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

    Каскадные схемы организации проектирования ПО для ИС достаточно давно стали
    преобразовываться в циклические формы. Так, организация продолжающейся разработки IBM
    corp. (см. []) предусматривала непрерывное контролируемое развитие программной
    системы в виде передачи в эксплуатацию ее новых версий.

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

    Однако, такие циклические схемы сохраняют многие старые недостатки структурных методов. Для
    условий Н.С.П. важными недостатками являются:


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

    Существуют и другие, например, громоздкость ведения проектной документации. Все это
    полностью относится и к проектированию БД.

    В условиях компонентного проектирования организационная схема проектирования БД должна
    выглядеть как схема параллельного спирального проектирования компонентов БД и их
    комплексирования по необходимости.

    Часто можно встретить утверждения, что объектно-ориентированное проектирование и
    программирование решают проблемы, порожденные структурным подходом и остающиеся при
    использовании циклических схем. Однако, с использованием таких технологий вопросы
    смысловой интероперабельности, тем более - при компонентном проектировании, могут в
    реальности осложниться еще больше из-за инкапсулированности описаний и меньшего внимания к
    дисциплине документирования данных. Представляется, что делать выводы о границах
    применимости этих подходов еще рано.

    От новых требований к типам и источникам информации - к новым архитектурным принципам БД

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

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


  • компонентная технология проектирования и перекомплектации предметно-
    ориентированных операционных БД, допускающих работу пользователей через
    общие, в том числе, для Хранилища Данных, интерфейсы;
  • расширенная технология Хранилища Данных, интегрирующая
    исторические форматированные данные, архивные текстовые документы,
    звуковые и видеоархивы, а также картографические данные, и включающая
    средства оперативной аналитической обработки данных, необходимые виды
    "дружественных" интерфейсов, например: гипертекстовый, ГеоИнформСистем
    и др.;
  • открытость БД для включения в нее и получения из нее информации с
    использованием принципов Глобальной Информационной Магистрали;
  • Архитектура Открытых Систем, расширенная методами и средствами
    компонентного формирования: на верхнем уровне это открытость
    компонентного проектирования БД и свободного обмена с источниками
    информации любых внешних систем, на нижнем уровне - технологическая
    открытость БД на основе стандартов переносимости, интероперабельности,
    масштабируемости и др..

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

    Об исключении избыточности в данных

    Сохраняется как разумное требование однократного ввода данных в БД для решения разных задач
    и защиты от возникновения противоречий (нарушении логической целостности) при актуализации
    хранимых данных. Однако, в условиях глобального информационного пространства и
    компонентного проектирования контекст этих требований должен быть пересмотрен.
    Несомненно, в операционных БД рационально планировать "острова" нормализованных и, в
    классическом смысле, безызбыточных кластеров отношений или объектов. Эти "острова" чаще
    всего и будут являться давно известными предметными БД.

    Вместе с тем, объединение исторических данных Хранилищ, БД ГИС-систем, архивов текстовых
    документов, потоков информации, получаемых по Информационной Магистрали и др. в общей
    постановке проектирования корпоративной БД приводит к отказу от повсеместного и
    всеобязательного принципа исключения избыточности: проектирование корпоративной БД на
    уровне логической схемы и на концептуальном уровне не опирается как на глобальный критерий на
    требование и процедуры исключения избыточности в данных.

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

    Проблема консервации проблем

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

    Предполагаемые подходы:


  • возможность фиксировать описания атрибутов, сущностей, связей,
    функций, и т.д. с любой степенью неполноты, возможности производить
    описания на уровне недетализированных, предметно связанных совокупностей
    информационных структур ("кластеров сущностей");
  • проектирование или реконструкция моделей компонентов ИС и БД, их
    интеграция в общем понятийном пространстве;
  • проектирование упорядоченной последовательности состояний
    корпоративной БД как последовательности совокупностей эксплуатируемых
    предметных БД, включающих: наследованные БД, структурно
    предопределенные БД "покупных" функциональных компонентов,
    спроектированные специально для данного предприятия БД, причем БД двух
    последних категорий постепенно заменяют наследованные и, затем и
    параллельно, заменяют друг друга в процессе развития ИС;
  • открытость репозитория CASE-системы, словаря СУБД и системы 4GL,
    позволяющая надстраивать метаобъекты и механизмы требуемыми
    тезаурусными и глубинными семантическими отношениями между элементами,
    а также производить двухсторонний обмен метаинформацией с другими
    системами 4GL и CASE, соединять модели разных компонентов в одну с
    использованием и сохранением всех необходимых семантических отношений.

    Компонентная открытость и смысловая интероперабельность

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

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

    Разработка понятийных моделей и СКК

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

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

    Понятийные модели и последующие проектные работы

    На последующих этапах проектирования собственно БД понятийная модель продолжает
    использоваться с различными целями, например:


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

    Технологическая открытость

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

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

    Целесообразно ориентироваться на CASE-системы, ориентированные на возможность
    параллельного проектирования компонент независимыми разработчиками (в том числе - без
    использования данной CASE-системы) с последующей интеграцией метаинформации.

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

    Проблемы объемов, временных характеристик и физического проектирования

    Распространение БД класса VLDB требует более активного использования методов
    проектирования эффективных физических схем данных. Невозможно строить такие БД
    рассчитывая на постоянную реорганизацию путем переписи в новые физические структуры. Это
    так для операционных БД режима OLTP, тем более это так для терабайтных БД, ориентированных
    на OLAP. Легкость процедур выполнения реорганизаций указанным методом может становиться
    "ловушкой" для проектировщика, особенно - на первых этапах ввода БД в действие, когда ее
    перепись еще возможна из-за неполного объема.

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

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

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

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

    К новым подходам в методах проектирования БД

    Как ответ на новые требования можно рассмотреть рекомендации к новым методам и
    инструментам проектирования БД. (Конечно, в предположении, что все новое есть ранее кем-то
    уже обнаруженное старое.)

    в условиях Нового Системного Проектирования

    Создание корпоративных БД в условиях Нового Системного Проектирования - деятельность,
    использующая многие методы классического проектирования, но требующая иной организации и
    многих дополнительных методов, а также новых, которые заменили бы некоторые из тех, что
    были разработаны 10 и более лет назад.

    Дисциплина проектирования БД в новых условиях еще отсутствует. Тем не менее, ее начала видны,
    ее элементы работают в реальных проектах.

    В соответствии с принципом сохранения иммунитета к компьютерным революциям (см.
    []) классические методы проектирования БД должны продолжать использоваться, но
    только в тех в областях, где они действительно полезны. Методы проектирования,
    рассматриваемые в конкретных проектах корпоративных ИС и БД, и соответствующие
    инструменты должны проверяться на свои возможности обеспечивать функции в соответствии с
    требованиями Нового Системного Проектирования.

    Литература

    [Дадли96] Дадли К. Соответствие стандарту SQL. Бюллетень "Мир ORACLE", М., N. 1, 1996.

    [Зиндер95а] Зиндер Е.З. Критерии выбора современной СУБД как объекта инвестиций для
    развития предприятия. СУБД, N 1, 1995.

    [Зиндер95б] Зиндер Е.З. Революции и перспективы. Computerworld Россия, сентябрь 26, 1995.

    [Зиндер96] Зиндер Е.З. Новое системное проектирование: информационные технологии и бизнес-
    реинжиниринг (вторая часть). СУБД, N 1, 1996.

    [Калиниченко93] Калиниченко Л.А. СИНТЕЗ: язык определения, проектирования и
    программирования интероперабельных сред неоднородных информационных ресурсов. М., ИПИ
    РАН, 1993.

    [Мартин95] Мартин Дж. Превратите вашу компанию в киберкорпорацию. Computerworld Россия,
    ноябрь 14, 1995.

    [Меллинг95] Меллинг В.П. Корпоративные информационные архитектуры: и все-таки они
    меняются. СУБД, N2, 1995.

    [Фокс85] Фокс Дж. Программное обеспечение и его разработка. М., "МИР", 1985.

    [Цикридзис85] Цикритзис Д., Лоховски Ф. Модели данных. М., "Финансы и статистика", 1985.

    [Codd79] Codd E.F. Extending the Database Relational Model to Capture More Meaning. ACM Trans.
    Database Syst., N 4, 1979.

    [Codd93] Codd E.F., Codd S.B., and Salley C.T. Providing OLAP to User-Analyst: An IT Mandate.
    E.F.Codd & Associates, 1993.

    [Hammer93] Hammer M., Champy J. Reengineering the Corporation. A Manifesto for Business
    Revolutions. HarperBusiness, 1993.

    [Zinder90] Zinder E.Z. PRIMET - The PeRsonal Information MetaTechnologies: from marketing to
    program implementation. //Общие проблемы информатики. III Международная конф.
    "Программное обеспечение ЭВМ" (ноябрь, Тверь, 1990) - Тверь: НПО ЦПС,1990

    []
    []

    Анализ - постановка задачи, общие принципы решения.

    В фазе анализа VantageTeam Builder предоставляет средства разработки диаграмм Потоков данных,
    используемых как для описания взаимодействия системы с внешним миром (контекстная диаграмма),
    так и для определения структуры процесса обработки информации (диаграммы потоков данных
    более низких уровней). При желании возможно формализованное задание требований к
    разрабатываемой системе в виде Списка событий. В этом случае обеспечивается контроль
    соответствия контекстной диаграммы и Списка событий. Кроме того обеспечивается контроль
    правильности декомпозиции диаграмм при переходе с уровня на уровень.

    Для разработки модели данных предлагается весьма широкий спектр средств, включающий в себя
    диаграммы Структуры данных, диаграммы Отношений сущностей и текстовое описание в форме
    Бэкуса-Науэра. Различные типы диаграмм сравниваются между собой на непротиворечивость.

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

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

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

    Фрагментация управления. Неразделение данных

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

    На каждом ко-сервере выполняются также компоненты, отвечающие за разбиение запроса на
    подзадачи и их распределение между ко-серверами:


  • Менеджер запросов (МЗ) отвечает за реализацию запросов с разбиением
    их на подзадачи, распределяемые между узлами с соблюдением баланса
    загрузки.
  • Оптимизатор запросов определяет наилучший план выполнения запроса,
    основываясь на оценках стоимости необходимых ресурсов.
  • Менеджер метаданных (ММД). Метаданные - это информация о
    распределении данных по узлам. Метаданные каждой БД, как правило,
    сосредоточены на одном узле. ММД ко-серверов, взаимодействуя между
    собой, обеспечивают каждому узлу доступность метаданных всех БД данного
    сервера.
  • Планировщик распределяет выполнение подзадач, из которых состоит
    выбранный план реализации запроса, между ко-серверами слабосвязанной
    системы. Он следит, в частности, за тем, чтобы на каждом ко-сервере были
    локально доступны ресурсы, необходимые для выполнения его подзадачи.

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

    Каждый узел, имея собственные сервисы протоколирования, восстановления, буферизации,
    управления контрольными точками и управления блокировками, полностью распоряжается
    данными, которыми он владеет. Если другим узлам требуются его данные, то они присылают
    соответствующие запросы на их получение.

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

    Архитектура Informix-OXPS, основанная на принципах децентрализованного,
    фрагментированного управления и раздельного владения данными, лишена ряда недостатков,
    присущих противоположному подходу, когда базы данных разделяются всеми узлами. В таком
    случае необходим выделенный центральный узел, который координирует совместный доступ
    "рабочих" узлов к содержимому баз данных.

    Активные базы данных

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

    Легко видеть, что основа этой идеи содержалась в языке SQL времени System R. На самом деле,
    что есть определение триггера или условного воздействия как не введение в БД правила, в
    соответствии с которым СУБД должна производить дополнительные действия? Плохо лишь то,
    что на самом деле триггеры не были полностью реализованы ни в одной из известных систем, даже
    и в System R. И это не случайно, потому что реализация такого аппарата в СУБД очень сложна,
    накладна и не полностью понятна.

    Среди вопросов, ответы на которые до сих пор не получены, следующие. Как эффективно
    определить набор вспомогательных действий, вызываемых прямым действием пользователя?
    Каким образом распознавать циклы в цепочке "действие-условие-действие-..." и что делать при
    возникновении таких циклов? В рамках какой транзакции выполнять дополнительные условные
    действия и к бюджету какого пользователя относить возникающие накладные расходы?

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

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

    Архитектура - общие принципы решения задачи.

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

    Для описания необходимой структуры базы данных используются диаграммы Отношений сущностей в
    нотации Чена . Они позволяют указывать различные типы реляционных
    отношений между таблицами (общее, тотальное, слабое, рекурсивное), связи различной мощности (1-1,
    1-N, N-N), а также различные суб- и супертипы, ассоциированные сущности и связи с атрибутами.

    Диаграммы Структуры данных и аналогичные им по нотации диаграммы Структуры управляющих
    потоков могут использоваться для определения структуры и типов программных переменных.

    В фазе Архитектуры начинается определение принципов построения интерфейса системы с
    использованием диаграмм Последовательности экранных форм. Они позволяют указывать как
    условия переходов между экранными формами, так и выполняемые при этом действия.

    Принцип передачи функций

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

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

    Дедуктивные базы данных

    По определению, дедуктивная БД состоит из двух частей: экстенсиональной, содержащей факты, и
    интенсиональной, содержащей правила для логического вывода новых фактов на основе
    экстенсиональной части и запроса пользователя.

    Легко видеть, что при таком общем определении SQL-ориентированную реляционную СУБД
    можно отнести к дедуктивным системам. Действительно, что есть определенные в схеме
    реляционной БД представления как не интенсиональная часть БД.

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

    Мы не будем здесь более подробно рассматривать конкретные проблемы, применяемые
    ограничения и используемые методы в дедуктивных системах. Отметим лишь, что обычно языки
    запросов и определения интенсиональной части БД являются логическими (поэтому дедуктивные
    БД часто называют логическими). Имеется прямая связь дедуктивных БД с базами знаний
    (интенсиональную часть БД можно рассматривать как БЗ). Более того, трудно провести грань
    между этими двумя сущностями; по крайней мере, общего мнения по этому поводу не
    существует.

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

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

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

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

    Фаза дизайна завершается, по словам разработчиков CASE'а, за один шаг до программы. Здесь
    осуществляется окончательная отработка модели данных, функциональной модели и проектирование
    интерфейса системы с помощью уже упоминавшихся диаграмм, а также ряда специальных типов
    диаграмм, позволяющих однозначно сформулировать требования к интерфейсу и программе.

    Разработка структуры базы данных предполагает полное описание всех атрибутов сущностей (полей
    таблиц). Для этого используется механизм логических типов данных и логических ограничений,
    практически полностью поддерживающий понятие домена. Возможно задание внешних (используемых
    при работе с заказчиком и в документации) и внутренних (программных) имен таблиц, полей и
    программных переменных. Определяются необходимые политики поддержания целостности базы по
    ссылкам при основных действиях (INSERT, UPDATE, DELETE) с различными таблицами.

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

    Диаграмма Содержания экранных форм позволяет указать таблицы и их поля, представленные в
    форме, способ их представления (список - полноэкранная форма), а также основные функциональные
    возможности (доступность таблиц на запись или только для чтения информации). При этом неявно
    определяется разделение таблиц на группы, включающие в себя одну или несколько основных
    (базовые) таблиц и связанные с ними отношением N-1 словари. На диаграмме можно указать
    необходимость открытия просмотрового окна для организация поиска значений в соответствующем
    словаре.

    Структурные схемы программ - универсальное средство описания функциональных возможностей
    приложения. Они позволяют описать любую программу с произвольной точностью (до функции,
    до группы операторов, до отдельного оператора, до отдельных составляющих оператора типа
    структуры AFTER FIELD в операторе INPUT). Основными элементами структурных схем являются
    заголовок или вызов функции, хэт-модуль ("модуль со шляпой", что соответствует используемому для
    него обозначению), позволяющий записать произвольные конструкции на языке программирования и
    указания относительно их размещения в программном файле (например, из любого хет модуля
    можно добавить определение еще одной переменной в секцию описания глобальных, модульных
    или локальных переменных, добавить в файл описание еще одной функции и т. п.), операторы выбора
    (MENU, IF, IF ... ELSE, CASE), операторы повтора (WHILE, FOR) и библиотечные
    (предопределенные или стандартные модули), представляющие собой, как будет показано ниже,
    весьма мощный инструмент быстрой разработки приложений.

    Темпоральные базы данных

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

    Конечно, можно явно ввести в хранимые отношения явный временной атрибут и поддерживать его
    значения на уровне приложений. Более того, в большинстве случаев так и поступают. Недаром в
    стандарте SQL появились специальные типы данных date и time. Но в таком подходе имеются
    несколько недостатков: СУБД не знает семантики временного поля отношения и не может
    контролировать корректность его значений; появляется дополнительная избыточность хранения
    (предыдущее состояние объекта данных хранится и в основной БД, и в журнале изменений); языки
    запросов реляционных СУБД не приспособлены для работы со временем.

    Существует отдельное направление исследований и разработок в области темпоральных БД. В
    этой области исследуются вопросы моделирования данных, языки запросов, организация данных
    во внешней памяти и т.д. Основной тезис темпоральных систем состоит в том, что для любого
    объекта данных, созданного в момент времени t1 и уничтоженного в момент времени t2, в БД
    сохраняются (и доступны пользователям) все его состояния во временном интервале [t1,t2].

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

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


    эксперименты.

    Главными особенностями системы управления памятью в Postgres является, во-первых, то, что в
    ней не ведется обычная журнализация изменений базы данных и мгновенно обеспечивается
    корректное состояние базы данных после перевызова системы с утратой состояния оперативной
    памяти. Во-вторых, система управления памятью поддерживает исторические данные. Запросы
    могут содержать временные характеристики интересующих объектов. Реализационно эти два
    аспекта связаны.

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

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

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

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

    Интегрированные или федеративные системы и мультибазы данных

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

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

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

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

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

    СУБД следующего поколения

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

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

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

    Одно свойство системы Postgres сближает ее с объектно-ориентированными СУБД. В Postgres
    допускается хранение в полях отношений данных абстрактных, определяемых пользователями
    типов. Это обеспечивает возможность внедрения поведенческого аспекта в БД, т.е. решает ту же
    задачу, что и ООБД, хотя, конечно, семантические возможности модели данных Postgres
    существенно слабее, чем у объектно-ориентированных моделей данных.

    Хотя отнесение СУБД к тому или иному классу в настоящее время может быть выполнено только


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


  • Направление Postgres. Основная характеристика: максимальное следование (насколько это
    возможно с учетом новых требований) известным принципам организации СУБД (если не считать
    упоминавшейся коренной переделки системы управления внешней памятью).
  • Направление Exodus/Genesis. Основная характеристика: создание собственно не системы, а
    генератора систем, наиболее полно соответствующих потребностям приложений. Решение
    достигается путем создания наборов модулей со стандартизованными интерфейсами, причем идея
    распространяется вплоть до самых базисных слоев системы.
  • Направление Starburst. Основная характеристика: достижение расширяемости системы и ее
    приспосабливаемости к нуждам конкретных приложений путем использования стандартного
    механизма управления правилами. По сути дела, система представляет собой некоторый
    интерпретатор системы правил и набор модулей-действий, вызываемых в соответствии с этими
    правилами. Можно изменять наборы правил (существует специальный язык задания правил) или
    изменять действия, подставляя другие модули с тем же интерфейсом.
    В целом можно сказать, что СУБД следующего поколения - это прямые наследники реляционных
    систем.

    Объектно-ориентированные базы данных

    Направление объектно-ориентированных баз данных (ООБД) возникло сравнительно давно.
    Публикации появлялись уже в середине 1980-х гг. Однако наиболее активно это направление
    развивается в последние годы. С каждым годом увеличивается число публикаций и реализованных
    коммерческих и экспериментальных систем.

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

    Конечно, ООБД возникли не на пустом месте. Соответствующий базис обеспечивают как
    предыдущие работы в области БД, так и давно развивающиеся направления языков
    программирования с абстрактными типами данных и объектно-ориентированных языков
    программирования.

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

    Среди языков и систем программирования наибольшее первичное влияние на ООБД оказал
    Smalltalk. Этот язык сам по себе не является полностью пионерским, хотя в нем была введена новая
    терминология, являющаяся теперь наиболее распространенной в объектно-ориентированном
    программировании. На самом деле, Smalltalk основан на ряде ранее выдвинутых концепций.

    Большое число работ не означает, что все проблемы ООБД полностью решены. Как отмечается в
    Манифесте группы ведущих ученых, занимающихся ООБД, современная ситуация с ООБД
    напоминает ситуацию с реляционными системами середины 1970-х гг.
    При наличии большого
    количества экспериментальных проектов ( и даже коммерческих систем) отсутствует общепринятая
    объектно-ориентированная модель данных, и не потому, что нет ни одной разработанной полной
    модели, а по причине отсутствия общего согласия о принятии какой-либо модели. На самом деле,
    имеются и более конкретные проблемы, связанные с разработкой декларативных языков запросов,
    выполнением и оптимизацией запросов, формулированием и поддержанием ограничений
    целостности, синхронизацией доступа и управлением транзакциями и т.д.

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

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

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

    ADABAS в корпоративных информационных системах

    По классификации Gartner Group (рис. 2)peализация концепции
    клиент/сервер в распределенной неоднородной вычислительной среде возможна в следующих
    конфигурациях:


  • распределенное отображение данных;
  • удаленное отображение данных (эмуляция терминала);
  • распределенное приложение (серверы приложений);
  • доступ к удаленной базе данных (серверы баз данных);
  • доступ к распределенной базе данных (интеграция/репликация баз
    данных).


    Модели клиент-сервер
    Источник:Gartner GroupКлиентADABAS в корпоративных информационных системах
    Сервер
    ADABAS в корпоративных информационных системах
    Распределенное отображение данных
    		Удаленное отображение данных
    		Распределенное приложение
    		Доступ к удаленной базе данных
    		Доступ к распределенной базе данных

    Архитектура Illustra

    Сравнение архитектур реляционных и объектно-ориентированных СУБД.

    Недостатки объектно-ориентированной архитектуры:


  • Функции СУБД запускаются в пространстве памяти клиента. Отсюда -
    высокие требования к клиентской станции.
  • Нет стандартного языка запросов. Все обращения к базе данных с
    помощью библиотек С/С++ или SmallTalk.
  • Жесткая привязка к языку 3GL.
  • Негибкость. Для того, чтобы изменить запрос к базе данных, необходимо
    переписать и перекомпилировать программу.

    Недостатки реляционной архитектуры.


  • Ограниченная поддержка типов данных.
  • Компоненты архитектуры предопределены и жестко связаны друг с другом.
  • Object wrappers чрезвычайно неэффективны.

    Архитектура Illustra - основная особенность - расширяемость сервера:


  • Компоненты сервера управляются системными таблицами.
  • Сервер можно расширять определяемыми пользователем типами данных,
    функциями, новыми методами доступами.
  • Возможность создавать функциональные индексы для быстрого доступа к
    данным.
  • Модули DataBlade добавляют новые домены данных.

    Illustra DataBlades расширяют объектно-ориентированную программную методологию до
    объектно-ориентированной стратегии управления данными. DataBlades включают новые типы
    данных и функции, а также могут включать методы визуализации и доступа для поддержки
    интеллектуальных запросов к новым типам данных.

    Архитектура "клиент-сервер"

    Распределенные системы - это системы "клиент-сервер". Существует по меньшей мере три модели
    "клиент-сервер" (подробно о них рассказано в ):


  • Модель доступа к удаленным данным (RDA-модель)
  • Модель сервера базы данных (DBS-модель)
  • Модель сервера приложений (AS-модель)

    Первые две являются двухзвенными и не могут рассматриваться в качестве базовой модели
    распределенной системы (ниже будет показано, почему это так). Трехзвенная модель хороша тем,
    что в ней интерфейс с пользователем полностью независим от компонента обработки данных.
    Собственно, трехзвенной ее можно считать постольку, поскольку явно выделены:


  • Компонент интерфейса с пользователем
  • Компонент управления данными (и базами данных в том числе)
    а между ними расположено программное обеспечение промежуточного слоя (middleware),
    выполняющее функции управления транзакциями и коммуникациями, транспортировки запросов,
    управления именами и множество других. Middleware - это ГЛАВНЫЙ компонент распределенных
    систем и, в частности, DDB-систем. Главная ошибка, которую мы совершаем на нынешнем этапе -
    полное игнорирование middleware и использование двухзвенных моделей "клиент-сервер" для
    реализации распределенных систем.

    Существует фундаментальное различие между технологией "SQL-клиент - SQL-сервер" и
    технологией продуктов класса middleware (например, менеджера распределенных транзакций
    Tuxedo System). В первом случае клиент явным образом запрашивает данные, зная структуру базы
    данных (имеет место так называемый data shipping, то есть "поставка данных" клиенту). Клиент
    передает СУБД SQL-запрос, в ответ получает данные. Имеет место жесткая связь типа "точка-
    точка", для реализации которой все СУБД используют закрытый SQL-канал (например, Oracle
    SQL*Net). Он строится двумя процессами: SQL/Net на компьютере - клиенте и SQL/Net на
    компьютере-сервере и порождается по инициативе клиента оператором CONNECT. Канал закрыт
    в том смысле, что невозможно, например, написать программу, которая будет шифровать SQL-


    запросы по специальному алгоритму (стандартные алгоритмы шифрования, используемые,
    например, в Oracle SQL*Net, вряд ли будут сертифицированы ФАПСИ).

    В случае трехзвенной схемы клиент явно запрашивает один из сервисов (предоставляемых
    прикладным компонентом), передавая ему некоторое сообщение (например) и получает ответ
    также в виде сообщения. Клиент направляет запрос в информационную шину (которую строит
    Tuxedo System), ничего не зная о месте расположения сервиса. Имеет место так называемый
    function shipping (то есть "поставка функций" клиенту). Важно, что для Клиента база данных (в том
    числе и DDB) закрыта слоем Сервисов. Более того, он вообще ничего не знает о ее существовании,
    так как все операции над базой данных выполняются внутри сервисов.

    Сравним два подхода. В первом случае мы имеем жесткую схему связи "точка-точка" с передачей
    открытых SQL-запросов и данных, исключающую возможность модификации и работающую
    только в синхронном режиме "запрос-ответ". Во втором случае определен гибкий механизм
    передачи сообщений между клиентами и серверами, позволяющий организовывать взаимодействие
    между ними многочисленными способами.

    Таким образом, речь идет о двух принципиально разных подходах к построению информационных
    систем "клиент-сервер". Первый из них устарел и явно уходит в прошлое. Дело в том, что SQL
    (ставший фактическим стандартом общения с реляционными СУБД) был задуман и реализован как
    декларативный язык запросов, но отнюдь не как средство взаимодействия "клиент-сервер" (об этой
    технологии тогда речи не было). Только потом он был "притянут за уши" разработчиками СУБД в
    качестве такого средства. На волне успеха реляционных СУБД в последние годы появилось
    множество систем быстрой разработки приложений для реляционных баз данных (VisualBasic,
    PowerBuilder, SQL Windows, JAM и т.д.). Все они опирались на принцип генерации кода
    приложения на основе связывания элементов интерфейса с пользователем (форм, меню и т.д.) с
    таблицами баз данных. И если для быстрого создания несложных приложений с небольшим числом
    пользователей этот метод подходит как нельзя лучше, то для создания корпоративных
    распределенных информационных систем он абсолютно непригоден.

    Для этих задач необходимо применение существенно более гибких систем класса middleware
    (Tuxedo System, Teknekron), которые и составляют предмет нашей профессиональной деятельности
    и базовый инструментарий при реализации больших проектов.

    Идентификация и проверка подлинности пользователей

    Обычно в СУБД для идентификации и проверки подлинности пользователей применяются либо
    соответствующие механизмы операционной системы, либо SQL-оператор CONNECT. Например, в
    случае СУБД Oracle оператор CONNECT имеет следующий вид:

    CONNECT пользователь[/пароль] [@база_данных];

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

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

    Информационное моделирование

    В данной статье мы рассмотрим некоторые аспекты информационного моделирования и его
    автоматизации с использованием CASE-средства ERwin 2.5 фирмы LogicWorks.

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

    Предыдущие версии ERwin - 1.5 и 2.1 - завоевали все возможные призы среди программ своего
    класса, в том числе DBMS Readers' Choice в 1992, 1993, 1994, 1995 годах, Software Development
    Productivity Award 1993, Data Based Advisor Readers' choice 1992 и 1994. Текущая версия продукта -
    2.5.

    Реализация моделирования в ERwin базируется на теории реляционных баз данных и на методологии
    IDEF1X.

    Методология IDEF1X была разработана для ВВС США и теперь используется, в частности, в
    правительственных, аэрокосмических и финансовых учреждениях, а также в большом числе частных
    компаний.

    Методология IDEF1X определяет стандарты терминологии, используемой при информационном
    моделировании, и графического изображения типовых элементов на диаграммах.

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

    Основные составляющие методологии

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

    Таким образом, фундамент предлагаемой методологии составляют:


  • итерационная спиральная модель жизненного цикла ИС;
  • комплекс развивающихся систем согласованных моделей;
  • методология анализа ИС на основе бизнес-процессов;
  • методология проектирования от данных;
  • комплекс согласованных инструментальных средств

    Постреляционные системы

    В этом разделе очень кратко рассматриваются основные направления исследований и разработок в
    области так называемых постреляционных систем, т.е. систем, относящихся к следующему
    поколению (хотя термин next-generation DBMS зарезервирован для некоторого подкласса
    современных систем).

    Сервер Informix-Online EXtended Parallel Server

    Системы с массовым параллелизмом (MPP) и слабосвязанные (кластерные) системы, для которых
    предназначена модель сервера Informix-OXPS, обладают двумя важнейшими преимуществами -
    высоким потенциалом отказоустойчивости и широкими возможностями наращивания
    производительности.

    MPP и слабосвязанные системы, называемые часто архитектурами без разделяемых ресурсов,
    представляют собой быстрые сети, связывающие однопроцессорные или симметричные
    многопроцессорные системы - узлы. Если база данных поделена между множеством узлов, то отказ
    одного из них приведет лишь к недоступности относящихся к нему данных. Остальные данные
    будут по-прежнему доступны пользователям. Если же в конфигурации предусмотрено аварийное
    переключение узлов, то доступ к данным отказавшего узла будет автоматически
    восстановлен.

    Для приложений DSS, имеющих сложный аналитический характер и предполагающих обработку
    очень больших массивов данных, критичной может оказаться способность платформы к
    наращиванию мощности параллельных вычислений. Число процессоров, которые реально
    способны поддерживать сегодняшние системы SMP, ограничено пропускной способностью
    системной шины; их практическая масштабируемость обеспечивается лишь с ростом количества
    процессоров до 32.

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

    Informix-OXPS доступен в настоящее время для платформ IBM SP2, ICL Goldrush, AT&T 5100;
    планируются реализации для платформ Pyramid/SNI Reliant RM1000, а также кластерных
    платформ Sun Microsystems Inc., Hewlett-Packard Co., Sequent Computer Systems Inc., Silicon
    Graphics Inc., Intel. Предполагается, что в перспективе будет обеспечена поддержка всех платформ
    этих типов, работающих под управлением ОС UNIX.

    Системные сообщения

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

    VantageTeam Builder как инструмент аналитика и дизайнера

    В соответствии с реализованным в VantageTeam Builder методом работа над проектом разбивается на
    четыре фазы: Анализ, Архитектура (в соответствии с отечественными традициями Глобальное
    проектирование), Дизайн (соответственно, Детальное проектирование) и Программирование.

    За идеей - классическая методология проектирования

    Классическая методология проектирования БД - это мощное и красивое течение со своей
    философией, способами восприятия реальности и способами существования в ней. В этом течении
    возникла своя прикладная математика, свое понятие "Мира", "Предметной Области" (ПрО) и их
    моделей. В отношении проектирования БД осознаны и интегрированы в стройные схемы методы
    выполнения таких проектных этапов:


  • сбор сведений о ПрО (анализ потребностей и описание ПрО с
    использованием так называемых "процессного" или UP, "usage perspective"
    подхода и "непроцессного" или ISP, "information structure perspective" подхода);
  • выбор языка представления т.н. "семантической" модели для фиксации
    сведений о ПрО, их последующего анализа и синтеза модели БД;
  • анализ собранных сведений о ПрО: классификация, формализация и
    интеграция структурных элементов описания ПрО, формализация как
    структурных, так и процедурных ограничений целостности элементов в
    будущей модели ПрО, определение динамики экземпляров объектов ПрО;
  • синтез концептуальной модели БД: проектирование целостной
    концептуальной схемы БД на выбранном языке семантического
    моделирования;
  • выбор конкретной модели данных и СУБД для реализации БД;
  • проектирование логической схемы БД для выбранной СУБД
    (называющееся также "проектирование реализации");
  • разработка физической структуры БД ("физической" или "внутренней"
    схемы, она же - "схема размещения"), включая размещение БД по узлам;
  • разработка технологии и процедур начального создания и заполнения БД;
  • разработка технологии и процедур сопровождения БД;
  • разработка универсальных программ доступа к БД и соответствующих
    интерфейсов пользователей;
  • информационное обеспечение разработки конкретных программ обработки
    данных: обеспечение метаинформацией, данными контрольных примеров и
    др.;
  • получение обратной связи от разработчиков прикладных программ и
    пользователей Информационной Системы (ИС) о полноте и эффективности


    организации БД;
  • тестирование БД, ее развитие и улучшение (настройка) ее структуры.

    Есть все основания называть методологию классической: для указанных методов разработаны
    полные, целостные методические системы, для большинства методов предложены
    формализованные модели, эти модели - или, по крайней мере, их итоговые выразительные
    возможности - нашли реальное применение в практике проектирования. Один только перечень
    основных моделей данных и их авторов производит внушительное впечатление, см. их обзор,
    например, в [].

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

    Масштабируемость и фрагментация

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

    Для того чтобы исключить по возможности узкие места программного характера и перекосы в
    распределении данных, в серверах Informix применяются механизмы фрагментации данных и
    фрагментации выполнения. В Informix-OXPS этой же цели служит принцип фрагментации
    управления, а в Informix-ODS - многопотоковая архитектура.

    Основные понятия

    Обычно в СУБД применяется произвольное управление доступом, когда владелец объекта
    передает права доступа к нему (чаще говорят - привилегии) по своему усмотрению. Привилегии
    могут передаваться субъектам (отдельным пользователям), группам, ролям или всем
    пользователям.

    Группа - это именованная совокупность пользователей. Объединение субъектов в группы
    облегчает администрирование баз данных и, как правило, строится на основе формальной или
    фактической структуры организации. Каждый пользователь может входить в несколько групп.
    Когда пользователь тем или иным способом инициирует сеанс работы с базой данных, он может
    указать, от имени какой из своих групп он выступает. Кроме того, для пользователя обычно
    определяют подразумеваемую группу.

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

    Привилегии роли имеют приоритет над привилегиями пользователей и групп. Иными словами,
    пользователю как субъекту не обязательно иметь права доступа к объектам, обрабатываемым
    приложениям с определенной ролью.

    Отметим, что в СУБД Oracle под ролью понимается набор привилегий. Такие роли служат
    средством структуризации привилегий и облегчают их модификацию.

    Совокупность всех пользователей именуется как PUBLIC. Придание привилегий PUBLIC -
    удобный способ задать подразумеваемые права доступа.

    Синхронизация доступа к данным

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

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

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

    Создание базы данных.

    SQL-скрипт для создания базы со всеми необходимыми операторами CREATE TABLE (с указанием
    необходимых ограничений), ADD FOREIGN KEY и CREATE PROCEDURE генерится
    автоматически. При этом для каждой таблицы создается описание трех хранимых процедур,
    обеспечивающих выполнение функций INSERT, UPDATE и DELETE. Использование процедур в
    приложении позволяет обеспечить выполнение требуемых политик поддержания целостности базы
    по ссылкам.

    Скрипт выполняется с помощью DBACCESS.

    Фрагментация данных

    Серверы Informix поддерживают горизонтальную фрагментацию таблиц. Это такой способ
    хранения таблицы, когда совокупность ее строк разбивается на несколько групп согласно
    некоторому правилу, и эти группы хранятся на разных дисковых разделах. В Informix-OXPS
    фрагменты таблицы могут распределяться между дисками разных узлов.

    Благодаря фрагментации:


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

    Генерация экранных форм.

    Экранные формы генерятся автоматически в соответствии с диаграммами Содержания экранных
    форм при переносе проекта в фазу Программирования. Их ручная доработка в части более
    рационального или эстетичного размещения полей по экрану может осуществляться в любом
    текстовом редакторе.

    Основные категории пользователей

    Пользователей СУБД можно разбить на три категории:


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

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

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

    Можно провести аналогию между пользователем ingres и администраторами баз данных с одной
    стороны, и суперпользователем операционной системы (root в случае ОС UNIX) и служебными
    пользователями (в ОС UNIX это могут быть bin, lp, uucp и т.д.) с другой стороны. Введение
    служебных пользователей позволяет администрировать функциональные подсистемы, не получая
    привилегий суперпользователя. Точно так же информацию, хранящуюся на сервере баз данных,
    можно разделить на отсеки, так что компрометация администратора одного отсека не означает
    обязательной компрометации другого.

    Управление транзакциями

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

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

    Фрагментация выполнения

    Термином "фрагментация выполнения" обозначается разбиение запроса на несколько подзапросов
    и их параллельное выполнение (т. е. вертикальный параллелизм); подзапросы затем могут быть
    разбиты на подзадачи, выполняемые параллельно (горизонтальный параллелизм, рис. 1).


    t
    Фрагментация выполнения
    writeФрагментация выполнения
    sortФрагментация выполнения
    mergeФрагментация выполнения
    scan
    abc

    Генерация кодов программ.

    Включает следующие стадии:

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

    Поддержание копий данных в нескольких узлах сети

    Основным накладным расходом при выполнении распределенного запроса является пересылка
    данных между узлами сети. Одним из способов сокращения этого накладного расхода является
    поддержание копий наиболее часто используемых данных в нескольких узлах сети с учетом
    порождаемых этим дополнительных накладных расходов по поддержанию согласованности копий
    при модификации данных.

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

    Виды привилегий

    Привилегии в СУБД можно подразделить на две категории: привилегии безопасности и
    привилегии доступа. Привилегии безопасности позволяют выполнять административные действия.
    Привилегии доступа, в соответствии с названием, определяют права доступа субъектов к
    определенным объектам.

    3.3.1. Привилегии безопасности

    Привилегии безопасности всегда выделяются конкретному пользователю (а не группе, роли или
    всем) во время его создания (оператором CREATE USER) или изменения характеристик
    (оператором ALTER USER). Таких привилегий пять:


  • security - право управлять безопасностью СУБД и отслеживать действия
    пользователей. Пользователь с этой привилегией может подключаться к любой
    базе данных, создавать, удалять и изменять характеристики пользователей,
    групп и ролей, передавать права на доступ к базам данным другим
    пользователям, управлять записью регистрационной информации, отслеживать
    запросы других пользователей и, наконец, запускать INGRES-команды от
    имени других пользователей. Привилегия security необходима администратору
    сервера баз данных, а также лицу, персонально отвечающему за
    информационную безопасность. Передача этой привилегии другим
    пользователям (например, администраторам баз данных) увеличивает число
    потенциально слабых мест в защите сервера баз данных.
  • createdb - право на создание и удаление баз данных. Этой привилегией,
    помимо администратора сервера, должны обладать пользователи, которым
    отводится роль администраторов отдельных баз данных.
  • operator - право на выполнение действий, которые традиционно относят к
    компетенции оператора. Имеются в виду запуск и остановка сервера,
    сохранение и восстановление информации. Помимо администраторов сервера
    и баз данных этой привилегией целесообразно наделить также
    администратора операционной системы.
  • maintain_locations - право на управление расположением баз
    администраторы сервера баз данных и операционной системы.
  • trace - право на изменение состояния флагов отладочной трассировки.
    Данная привилегия полезна администратору сервера баз данных и другим


    знающим пользователям при анализе сложных, непонятных ситуаций.

    3.3.2. Привилегии доступа

    Привилегии доступа выделяются пользователям, группам, ролям или всем посредством оператора
    GRANT и изымаются с помощью оператора REVOKE. Эти привилегии, как правило, присваивает
    владелец соответствующих объектов (он же - администратор базы данных) или обладатель
    привилегии security (обычно администратор сервера баз данных).

    Прежде чем присваивать привилегии группам и ролям, их (группы и роли) необходимо создать с
    помощью операторов CREATE GROUP и CREATE ROLE.

    Для изменения состава группы служит оператор ALTER GROUP.

    Оператор DROP GROUP позволяет удалять группы, правда, только после того, как опустошен
    список членов группы.

    Оператор ALTER ROLE служит для изменения паролей ролей, а DROP ROLE - для удаления
    ролей.

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

    Привилегии доступа можно подразделить в соответствии с видами объектов, к которым они
    относятся. В СУБД INGRES таких видов пять:


  • таблицы и представления
  • процедуры
  • базы данных
  • сервер баз данных
  • события

    Присваивание привилегий доступа производится с помощью оператора GRANT. В самом общем
    виде оператор GRANT имеет следующий формат:

    GRANT привилегии

    ON объекты

    TO кому;

    Применительно к таблицам и представлениям можно управлять следующими правами доступа:

    SELECT- право на выборку данных
    INSERT- право на добавление данных
    DELETE- право на удаление данных
    UPDATE - право на обновление данных (можно указать определенные
    столбцы, разрешенные для обновления)
    REFERENCES- право на использование внешних ключей, ссылающихся на данную таблицу (можно указать определенные столбцы)

    По умолчанию пользователь не имеет никаких прав доступа к таблицам и представлениям - их


    необходимо передать с помощью операторов GRANT.

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

    Права доступа к базе данных как к единому целому может предоставлять ее администратор или
    пользователь с привилегией security. Эти "права" на самом деле устанавливают ряд ограничений на
    использование базы данных, то есть по сути являются запретительными. Имеется в виду
    ограничение на число операций ввода/вывода или число строк, возвращаемых одним запросом,
    ограничение права создания таблиц и процедур и т.п. По умолчанию пользователь не стесняется
    количественными лимитами и получает право на создание объектов в базе.

    Отметим, что при создании базы данных указывается ее статус - общая или личная. Это влияет на
    подразумеваемые права доступа к базе. По умолчанию право на подключение к общей базе
    предоставляется всем. Право на подключение к личной базе нужно передавать явным образом.
    Право на подключение необходимо для выполнения всех прочих операций с базой и
    содержащимися в ней объектами.

    Привилегии (которые в данном случае точнее было бы назвать ограничениями)
    QUERY_IO_LIMIT и QUERY_ROW_LIMIT проверяются на основании оценок, выданных
    оптимизатором запросов. Если оптимизатор предсказывает, что запрос превысит отведенный
    лимит числа операций ввода вывода или возвращаемых строк, он (запрос) отвергается. Наложение
    подобных количественных ограничений препятствует монополизации сервера одним клиентом и
    может использоваться как один из инструментов поддержания высокой готовности.

    Обратим внимание на следующее любопытное обстоятельство. По умолчанию все пользователи
    имеют право создавать процедуры в базах данных. Если бы они при этом автоматически получали


    права на выполнение, то смогли бы осуществить по существу любую операцию с данными,
    поскольку выполнение процедуры не требует прав доступа к обрабатываемым объектам. К
    счастью, для передачи привилегии доступа к объектам, и в, частности, для предоставления права
    на выполнение процедуры, надо быть не только владельцем объекта, но и администратором базы
    данных. Мы видим, насколько осторожно нужно относиться к предоставлению привилегий
    выполнения по отношению к новым, непроверенным процедурам. В принципе достаточно одного
    "троянского коня", чтобы скомпрометировать всю базу данных. Процедуры являются столь же
    гибким, но и столь же опасным средством, что и UNIX-программы с битом переустановки
    действующего идентификатора пользователя.

    Отметим, что запретительные привилегии в принципе можно наложить на администратора базы
    данных или администратора сервера, однако они не будут иметь силы. Тем самым злоумышленник
    лишен возможности ограничить права доступа администраторов. В частности, он не может
    создать личную "секретную" базу данных, к которой не будет иметь доступ пользователь ingres.
    Правда, у подобного положения есть и оборотная сторона - компрометация пароля администратор
    сервера предоставляет злоумышленнику неограниченные права доступа ко всем базам
    данных.

    Права доступа к серверу распространяются на все базы данных, обслуживаемые данным серверам.
    Набор этих прав тот же, что и для отдельных баз данных.

    Привилегии, явно определенные для отдельных баз, имеют приоритет над привилегиями
    сервера.

    Механизм событий подробно рассмотрен в . Здесь мы отметим лишь, что по
    отношению к событиям имеются две привилегии - RAISE и REGISTER. Первая позволяет
    возбуждать события, вторая - регистрироваться для их получения.

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

    GRANT ...

    ...

    WITH GRANT OPTION;

    Подобный оператор GRANT передает не только указанные в нем привилегии, но и права на


    их дальнейшую передачу. Очевидно, что использование конструкции WITH GRANT OPTION
    ведет к децентрализации контроля над привилегиями и содержит потенциальную угрозу
    безопасности данных.

    Для отмены привилегий, выданных ранее (как разрешительных, так и запретительных), служит
    оператор REVOKE.

    3.3.3. Получение информации о привилегиях

    Важно не только давать и отбирать привилегии, но и иметь информацию о том, какими правами
    доступа обладает каждый из субъектов. Подобные данные можно получить с помощью функции
    dbmsinfo, а также путем анализа содержимого таблиц в базе данных iidbdb.

    Функция dbmsinfo возвращает права доступа к базе, относящиеся к текущему подключению.
    Можно узнать имена действующих группы и роли, значения количественных ограничений,
    наличие привилегий для создания таблиц и процедур и т.п.

    Таблицы iiusergroup, iirole и iidbprivileges базы данных iidbdb содержат соответственно, список
    групп и их состав, перечень ролей вместе с зашифрованными паролями и сведения о привилегиях
    доступа к базам данных. Так, таблица iiusergroup состоит из трех столбцов:


  • groupid - имя группы,
  • groupmem - имя члена группы,
  • reserve - резервный столбец.

    Средствами SQL из этих таблиц можно извлечь необходимую информацию.

    Фрагментация объектов БД

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

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

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

    Использование представлений для управления доступом

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

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

    CREATE VIEW empview AS

    SELECT name, dept

    FROM employee

    WHERE dept = 'shoe';

    Предоставим всем право на выборку из этого представления:

    GRANT SELECT

    ON empview

    TO PUBLIC;

    Субъекты, осуществляющие доступ к представлению empview, могут пытаться запросить
    сведения об отделах, отличных от shoe, например:

    SELECT *

    FROM empview

    WHERE dept = 'toy';

    но в ответ просто получат результат из нуля строк, а не код ответа, свидетельствующий о
    нарушении прав доступа. Это принципиально важно, так как лишает злоумышленника
    возможности получить список отделов косвенным образом, анализируя коды ответов,
    возвращаемые после обработки SQL-запросов.

    Сборка программы.

    VantageTeam Builder предлагает программисту достаточно удобные инструменты для описания
    приложения, как совокупности программных, объектных и библиотечных файлов, зависимостей
    между файлами с исходными текстами программ и между другими входящими в приложение файлами.
    На основе этого описания для приложения автоматически генерится makefile, управляющий
    компиляцией и сборкой программы. По желанию может быть собран как файл с интерпретируемым,
    так файл с исполняемым кодом программы.

    Алгоритмы выполнения реляционных операций

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

    Таким образом, даже рассмотрев только небольшую часть проблем распределенных систем, можно
    убедиться, что они нуждаются в большом количестве исследований и экспериментов. Начавшийся
    в России переход к использованию локальных сетей дает практическую возможность проведения
    таких работ.

    Иерархия прав доступа

    Оператор GRANT и другие средства управления доступом СУБД позволяют реализовать
    следующие виды ограничения доступа:


  • операционные ограничения (за счет прав доступа SELECT, INSERT,
    UPDATE, DELETE, применимых ко всем или только некоторым столбцам
    таблицы);
  • ограничения по значениям (за счет механизма представлений);
  • ограничения на ресурсы (за счет привилегий доступа к базам данных).

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

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

    Иерархия авторизации выглядит для СУБД INGRES следующим образом:


  • роль (высший приоритет)
  • пользователь
  • группа
  • PUBLIC (низший приоритет)

    Для каждого объекта, к которому осуществляется доступ, INGRES пытается отыскать в иерархии
    привилегию, относящуюся к запрашиваемому виду доступа (SELECT, EXECUTE и т.п.).
    Например, при попытке доступа к таблице с целью обновления, INGRES проверяет привилегии
    роли, пользователя, группы и всех пользователей. Если хотя бы на одном уровне иерархии
    привилегия UPDATE имеется, запрос передается для дальнейшей обработки. В противном случае
    используется подразумеваемое право доступа, которое предписывает отвергнуть запрос.

    Рассмотрим подробнее трактовку ограничений на ресурсы. Пусть, например, на всех четырех


    уровнях иерархии специфицированы свои ограничения на число результирующих строк запроса
    (привилегия QUERY_ROW_LIMIT):


    роль1700
    пользователь1500
    группа2000
    PUBLIC1000

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

    Обычно используемая роль и группа задаются, соответственно, как аргументы опций -R и -G в
    командной строке запуска приложения. Пример:

    QBF -Gaccounting company_db

    Если опция -G отсутствует, применяется подразумеваемая группа пользователя, если таковая
    имеется.

    Наконец, если в командной строке sql задана опция

    -uпользователь

    то в число проверяемых входят также привилегии указанного пользователя.

    Метки безопасности и принудительный контроль доступа

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

    В "Критериях оценки надежных компьютерных систем", применительно к системам уровня
    безопасности B, описан механизм меток безопасности, реализованный в версии INGRES/Enhanced
    Security (INGRES с повышенной безопасностью). Применять эту версию на практике имеет смысл
    только в сочетании с операционной системой и другими программными компонентами того же
    уровня безопасности. Тем не менее, рассмотрение реализации меточной безопасности в СУБД
    INGRES интересно с познавательной точки зрения, а сам подход, основанный на разделении
    данных по уровням секретности и категориям доступа, может оказаться полезным при
    проектировании системы привилегий многочисленных пользователей по отношению к большим
    массивам данных.

    В СУБД INGRES/Enhanced Security к каждой реляционной таблице неявно добавляется столбец,
    содержащий метки безопасности строк таблицы. Метка безопасности состоит из трех
    компонентов:


  • Уровень секретности. Смысл этого компонента зависит от
    приложения. В частности, возможен традиционный спектр уровней от
    "совершенно секретно" до "несекретно".
  • Категории. Понятие категории позволяет разделить данные на
    "отсеки" и тем самым повысить надежность системы безопасности.
    В
    коммерческих приложениях категориями могут служить "финансы", "кадры",
    "материальные ценности" и т.п. Ниже назначение категорий разъясняется
    более подробно.
  • Области. Является дополнительным средством деления
    информации на отсеки. На практике компонент "область" может действительно
    иметь географический смысл, обозначая, например, страну, к которой
    относятся данные.

    Каждый пользователь СУБД INGRES/Enhanced Security характеризуется степенью
    благонадежности, которая также определяется меткой безопасности, присвоенной данному
    пользователю. Пользователь может получить доступ к данным, если степень его благонадежности
    удовлетворяет требованиям соответствующей метки безопасности. Более точно:


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

    Рассмотрим пример. Пусть данные имеют уровень секретности "конфиденциально", принадлежат
    категории "финансы" и относятся к областям "Россия" и "СНГ". Далее, пусть степень
    благонадежности пользователя характеризуется меткой безопасности с уровнем секретности
    "совершенно секретно", категориями "финансы" и "кадры", а также областью "Россия". Такой
    пользователь получит доступ к данным. Если бы, однако, в метке пользователя была указана
    только категории "кадры", в доступе к данным ему было бы отказано, несмотря на его
    "совершенно секретный" уровень.

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

    Отметим, что механизм меток безопасности не отменяет, а дополняет произвольное управление
    доступом. Пользователи по-прежнему могут оперировать с таблицами только в рамках своих
    привилегий, но даже при наличии привилегии SELECT им доступна, вообще говоря, только часть
    данных.

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

    Специальная привилегия, DOWNGRADE, позволяет изменять метки безопасности,
    ассоциированные с данными. Подобная возможность необходима, например, для коррекции
    меток, по тем или иным причинам оказавшихся неправильными.

    Представляется естественным, что СУБД INGRES/Enhanced Security допускает не только скрытое,
    но и явное включение меток безопасности в реляционные таблицы. Появился новый тип данных,
    security label, поддерживающий соответствующие операции сравнения.

    INGRES/Enhanced Security - первая СУБД, получившая сертификат, эквивалентный аттестации на
    класс безопасности B1. Вероятно, метки безопасности постепенно войдут в стандартный репертуар
    систем управления базами данных.

    Функции СУБД

    Описание объектных средств Illustra:


  • Типы данных.
  • Типы, определяемые пользователем. Множества, массивы и конструкторы
    типов. Наследование типов. Преобразования типов.
  • Функции.
  • Определяемые пользователем функции. SQL и С- функции. Клиентские и
    серверные функции. Переопределение функций при наследовании.
  • Поддержка сервером механизмов правил и алертеров.
  • Система правил для поддержки целостности данных. Концепция активного
    ядра базы данных в механизме алертеров.
  • Управление хранением данных.
  • Хранение элементов данных внутри записей (in row) и в виде больших
    объектов (large object). Прозрачность механизма для пользователя.
  • Возможности time travel.
  • Хранение всех версий записей. Поддержка запросов "time travel".

    Итерационная спиральная модель жизненного цикла ИС.

    Методология описывает процесс создания и сопровождения информационных систем в виде
    жизненного цикла (ЖЦ) ИС, представляя его в виде последовательности стадий, каждая из
    которых разбита на этапы, и выполняемых на них процессов. Для каждого этапа определяются
    последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые
    для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ
    ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить
    управление этим процессом.

    Жизненный цикл ИС, определяемый методологией, приведен на рис.1. Он включает стадии
    анализа, проектирования, разработки, тестирования и интеграции, внедрения, сопровождения и
    развития ИС. На рисунке приведены также перечень основных этапов для каждой стадии ЖЦ и
    процессы, выполняемые на протяжении всего ЖЦ - процессы управления и интегральные
    процессы. Эти процессы в той или иной степени присутствуют на каждом из этапов.


    Процессы организации и управления проектом: планирование,
    управление, контрольАнализПроектированиеРазработкаИнтеграция и
    тестированиеВнедрениеСопровождениеИнтегральные процессы: управление конфигурацией,
    документирование, проверки, интеграция
    * Обследование и создание моделей деятельности организации

    *Анализ (моделей) существующих ИС

    *Анализ моделей и формирование требований к ИС

    *разработка плана создания ИС
    		*Концептуальное проектирование

    *Разработка архитектуры ИС

    *Проектирование общей модели данных

    *Формирование требований к приложениям
    		*Разработка, прототипирование и тестирование приложений

    *Разработка интеграционных тестов

    *Разработка пользовательской документации
    		*Интеграция и тестирование приложений в составе системы

    *Оптимизация приложений и баз данных

    *Подготовка эксплуатационной документации

    *Тестирование системы
    		*Обучение пользователей

    *Развертывание системы на месте эксплуатации

    *Инсталляция баз данных

    *Эксплуатация

    *Проведение ПСИ
    		*Регистрация, диагностика и локализация ошибок

    *Внесение изменений и тестирование

    *Управление режимами работы ИС
    <
    Рис. 1. Жизненный цикл ИС

    Процесс создания ИС представляет из себя процесс построения и последовательного
    преобразования согласованных моделей на всех этапах ЖЦ. Эти модели сохраняются и
    накапливаются в репозитории проекта. С помощью CASE-средств модели создаются,
    преобразуются и контролируются. Основными результатами на каждом этапе ЖЦ являются
    модели определяемых на данном этапе объектов (организации, требований к ИС, проекта ИС,
    требований к приложениям и т.д.).

    Характер выполняемых процессов и организация работ в представленной модели ЖЦ
    основаны на подходе информационного инжиниринга и отличаются от классической каскадной
    модели ЖЦ, несмотря на внешнюю схожесть. При традиционной обработке данных разработка
    велась строго последовательно. Требования ТЗ утверждались в начале разработки, а их
    выполнение проверялось в конце. Переход от стадии к стадии, от этапа к этапу допускался только
    после полного выполнения всего перечня работ и получения всех запланированных результатов.

    ЖЦ ИС, предлагаемый в новой методологии определяется следующими особенностями.


  • Современные средства CASE, 4GL, СУБД и др. предоставляют
    возможности быстрого проектирования, прототипирования, разработки и
    тестирования приложений и баз данных на основе построенных моделей.
  • Методология предполагает активное участие заказчиков на всех этапах
    создания ИС, поскольку модели, создаваемые на каждом этапе, понятны и
    разработчику и заказчику.

    Эти особенности определяют возможности оперативного и быстрого пересмотра требований и
    разработанных решений на основе современных средств, возможности неравномерной,
    параллельной разработки различных частей проекта, возможности возврата на предыдущие этапы
    по отдельным частям проекта при необходимости внесения изменений. Методология
    предусматривает и версионный характер изменения проекта или его частей при поддержке CASE-
    средств. Все это определяет итерационный, спиральный характер предлагаемой модели
    жизненного цикла.

    Работа Progress в гетерогенной сети

    Различные устройства могут использовать различные кодовые страницы и при работе в
    гетерогенных сетях важно уметь настроить ваше приложение на работу с такими устройствами.
    PROGRESS различает несколько типов кодовых страниц - внутренняя страница, страница баз
    данных, страница печати, страница символьного терминала, страница дополнительного потока.
    Progress осуществляет автоматическое преобразование информации в соответствии с задаваемыми
    кодовыми страницами. Конечный пользователь приложения может даже не знать, что различные
    устройства используют различные кодовые страницы. Progress осуществляет следующие типы
    преобразований: Значения используемых кодовых страниц указываются при запуске сессии
    Progress и Progress автоматически осуществляет необходимые преобразования.

    Приведем некоторые стартовые параметры.


  • cpinternal позволяет установить кодовую страницу, используемую
    PROGRESS для внутренних операций.
  • cpstream позволяет определить кодовые страницы, используемые при
    импорте и экспорте файлов, а также для дополнительных потоков.
  • cpterm позволяет вам установить кодовую страницу для алфавитных
    терминалов, использующих кодовую страницу отличную от внутренней.
  • cpprint позволяет определить кодовую страницу для принтера.
  • cpcoll позволяет определить кодовую страницу для клиентского процесса.

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

    Progress приложения могут работать не только с базами данных Progress, но и с другими базами
    данных Oraclе, SYBASE. В некоторых случаях разные поставщики используют разные
    наименования для одной и той же кодовой страницы, как например, SYBASE использует
    наименование ISO-1 вместо ISO8859-1. В этом случае вам необходимо позаботиться о правильном
    определении таблиц перекодировок в файле convmap.cp.

    Распределенные СУБД

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

    Реляционные базы данных

    В реляционной модели все данные представляются как факты о сущностях и связях. Например,
    система резервирования билетов содержит информацию о сущностях "пассажир" и "рейс". Между
    сущностями определяются функциональные связи. Продолжая пример, между сущностями "пассажир"
    и "рейс" определяется связь "перевозит" ("рейс" "перевозит" много "пассажиров").

    Сущность - это, например, человек, место, вещь, событие, концепция, о которых хранится
    информация. Сущности именуются обычно существительными, такими как "покупатель", "компьютер",
    "служащий", "продажа".

    Более точно, сущность - это множество индивидуальных объектов - экземпляров, причем все эти
    объекты являются различными.

    Связь - это функциональная зависимость между сущностями. Например, "служащий" совершает
    "продажи".

    Каждая сущность обладает атрибутами. Атрибут - это свойство объекта, характеризующее его
    экземпляр. Сущность "служащий" может иметь атрибуты "имя", "дата рождения" и т.д.

    Общепринятым видом графического изображения реляционной модели данных является ER-
    диаграмма. На такой диаграмме сущности (таблицы) изображаются прямоугольниками, возможно,
    соединенными между собой линиями (связями). Такое графическое представление облегчает
    восприятие структуры базы данных по сравнению с текстовым описанием.

    Управление доступом

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

    VantageTeam Builder для программиста.

    Рассмотрим основные действия программиста, осуществляющего разработку проекта с
    использованием VantageTeam Builder.

    За методологией - мастерская инструментов проектирования БД

    Проектирование комплексной по предметной направленности, интегрированной и, обычно,
    большой по размеру БД стало сложной задачей. Наличие целостной методологии проектирования
    позволило позаботиться о "сапожнике-проектировщике" и начать шить ему сапоги в виде систем
    автоматизации проектирования БД. Этому способствовало наличие технологического опыта в
    организации и компьютерной поддержке систем разработки программного обеспечения и, с
    другой стороны, использование активных интегрированных словарей-справочников данных
    (DD/D, Data Dictionary/Directory). Так возникли системы CASE (Computer Aided System
    Engineering) - системы для структурного проектирования БД и связанных с ними ИС,
    ориентированные на модели данных, реализованные в различных СУБД. Наибольшую
    популярность получили CASE-системы для реляционных СУБД с SQL-моделями данных, а DD/D
    переименовался в CASE-репозиторий проектируемой ИС.

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

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

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

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

    Аварийное переключение ко-серверов Informix- OXPS

    Каждый ко-сервер владеет некоторым набором дисков, на которых располагаются фрагменты
    базы данных. Диски, как правило, являются двухпортовыми, и каждый из них физически соединен
    еще с некоторым ко-сервером Informix-OXPS. Если в результате аппаратного или программного
    сбоя узел выходит из строя, его диски автоматически передаются во владение альтернативным ко-
    серверам, и доступность данных сохраняется. Диски, журнал транзакций, рабочую загрузку
    отказавшего узла берут на себя остальные ко-серверы.

    При отказе узла одна или несколько транзакций могли остаться незавершенными. Поэтому ко-
    сервер, принявший журнал вышедшего из строя узла, запускает процедуру быстрого
    восстановления, цель которой - привести данные в состояние физической и логической
    целостности.

    Личные библиотеки модулей программы.

    В VantageTeam Builder поддерживаются библиотечные модули для реализации и вызова базовых SQL-
    функций доступа к таблицам базы данных. Разработчик может пользоваться этим инструментом для
    создания собственных, личных (или проектных) библиотек модулей. Каждый такой модуль является
    атомарным (детально не раскрываемым) элементом структурной схемы программы. Они
    предназначены для выполнения двух задач.

    Первая, это создание библиотеки стандартных (непараметризуемых) фрагментов текста, например:

    INPUT BY NAME p_record.*
    --начало библиотечного модуля
    ON KEY (ESC)
    LET INT_FLAG = true
    EXIT INPUT
    --конец библиотечного модуля
    Вторая - это создание библиотеки шаблонов, используемых для генерации параметризуемых
    фрагментов текста, например (имя таблицы и имена полей определяются в данном примере
    параметрически):

    --начало библиотечного модуля
    INPUT BY NAME p_{имя таблицы}.*
    ON KEY (ESC)
    LET inf_flag = true
    EXIT INPUT
    ON KEY(CONTROL-U)
    --для всех импортированных полей
    IF INFIELD({имя поля}) THEN
    CALL find_{имя таблицы}(p_{имя таблицы}.{имя поля})
    RETURNING p_{имя таблицы}.*
    END IF
    END INPUT
    --конец библиотечного модуля
    Соответственно дизайнер может использовать один и тот же библиотечный модуль на различных
    схемах, а программист один раз пишет необходимый код или шаблон. Шаблоны представляют собой
    текст программы, содержащий вызовы специальных функций, написанных на языке Tool Command
    Language (TCL), и обеспечивающих чтение информации из формируемых с помощью VantageTeam
    Builder моделей (диаграмм) и запись сформированного текста в соответствующие разделы
    генеримого файла с кодом программы или SQL-скрипта. Например, шаблон для приведенного
    выше примера выглядит следующим образом:

    --начало шаблона
    INPUT BY NAME p_~${current_table}.*
    ON KEY (ESC)
    LET inf_flag = true
    EXIT INPUT
    ON KEY(CONTROL-U)
    ~[ foreach col [gen_col_list $current_table "FKEY"] {
    set master_table [get_master $col]
    set col_name [get_uniq_name $col]
    expand_text $current_section {


    IF INFIELD(~$col_name) THEN
    CALL find_~${master_table}()
    returning p_~$current_table.~$col_name
    END IF
    END INPUT
    --конец шаблона
    Здесь:
  • current_table - переменная, в которой хранится имя текущей таблицы;
  • foreach - команда цикла по всем импортированным из других таблиц полям
    текущей таблицы;
  • get_master и get_uniq_name - функции, обеспечивающие чтение имени
    связанной таблицы и импортированного поля;
  • expand_text $current_section - команда, обеспечивающая запись сгенеренного
    текста в программный файл.
    Имя таблицы, для которой необходимо сгенерить соответствующий фрагмент кода, может
    определяться по диаграмме содержания экранной формы. При этом нетрудно обеспечить, чтобы
    указанный фрагмент кода генерился для каждой из присутствующих на диаграмме таблиц, только для
    базовых таблиц, либо только для "словарей".

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

    Ограничения

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

    Табличные ограничения относятся к группе столбцов и могут задаваться как при создании
    таблицы, так и позже, посредством оператора ALTER TABLE.

    Следующий пример содержит именованное ограничение, связывающее значения в двух
    столбцах:

    CREATE TABLE dept (

    dname char(10),

    budget money,

    expenses money,

    CONSTRAINT check_amount CHECK (budget > 0 and expenses
    );

    {Бюджет должен быть положительным, а расходы не должны выходить за рамки
    бюджета}

    Ссылочные ограничения отвечают за целостность связей между таблицами. Подобное
    ограничение требует, чтобы каждому значению в столбце или группе столбцов одной таблицы
    соответствовало ровно одно значение в другой таблице. Название ограничения объясняется тем,
    что такие значения играют роль ссылок между таблицами в реляционной модели.

    Приведем пример ссылочного ограничения:

    CREATE TABLE emp (

    ename char(10),

    edept char(10) references dept(dname)

    );

    {Ни один работник не должен числиться в неизвестном отделе}

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

    Отметим, что для наложения ссылочного ограничения необходимо обладать привилегией
    REFERENCES по отношению к таблице, на которую делается ссылка (dept в примере выше).

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

    CREATE TABLE dept (

    name char(10) NOT NULL,

    location char(20),

    CONSTRAINT dept_unique UNIQUE(name)

    );

    CREATE TABLE emp (

    name char(10),

    salary decimal(10,2),

    edept char(10) CONSTRAINT empref REFERENCES dept(name)

    );

    Если требуется удалить ограничение dept_unique, можно воспользоваться следующим
    оператором:

    ALTER TABLE dept

    DROP CONSTRAINT dept_unique cascade;

    Слово cascade означает, что следует удалить также все ограничения, прямо или косвенно
    зависящие от dept_unique. В данном случае будет изъято ограничение empref. Если вместо cascade
    указать restrict, то есть сделать попытку удалить только ограничение dept_unique, СУБД
    зафиксирует ошибку. Тем самым обеспечивается целостность системы ограничений.

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

    Использование стандартной библиотеки модулей программы.

    В стандартную поставку VantageTeam Builder входит набор библиотечных модулей для генерации
    меню по диаграмме последовательности экранных форм и для выполнения стандартных действий
    (insert, update, delete) для базовых таблицы определенной экранной формы. Поэтому вы можете
    ограничиться следующей последовательностью действий для получения полностью функционального
    приложения (обеспечивающего выполнение всех необходимых действий с таблицами базы данных), с
    единообразным интерфейсом.

    Шаг1. Разработка структуры базы данных с использованием диаграмм отношений
    сущностей.

    Шаг2. Разработка интерфейса приложения с использованием диаграмм последовательности
    экранных форм. В последовательности экранных форм используются формы двух видов - формы-
    меню и формы для работы с одной или несколькими таблицами базы данных. Формы-меню
    обеспечивают выбор таблицы (группы таблиц), с которой вы собираетесь работать.

    Шаг3. Для форм, предназначенных для работы с одной таблицей, ее имя указывается в
    атрибутах формы, а для форм, предназначенных для работы с полями нескольких таблиц, создаются
    диаграммы содержания экранных форм.

    Шаг4. К формам-меню привязывается структурная схема, основным элементом которой
    является библиотечный модуль "MENU". К формам, предназначенным для работы с таблицами
    привязывается стандартная структурная схема, обеспечивающая выполнение стандартных действий
    (insert, update, delete, find).

    Все вышеперечисленные действия выполняются в фазе дизайна. В результате при переходе в фазу
    программирования вы получаете не только готовый SQL-скрипт и экранные формы, но и полностью
    готовое автоматически сгенеренное приложение. Скорость разработки простых проектов при этом
    оказывается вполне сопоставимой с такими популярными средствами разработки приложений, как
    PowerBuilder и Delphi.

    Правила

    Правила позволяют вызывать выполнение заданных действий при определенных изменениях базы
    данных. Обычно действие - это вызов процедуры. Правила ассоциируются с таблицами и
    срабатывают при изменении этих таблиц.

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

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

    SET NORULES;

    Оператор

    SET RULES;

    позволит затем восстановить работу механизма правил. По умолчанию этот механизм
    включен.

    Для удаления правил служит оператор

    DROP RULE правило;

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

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

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

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

    Проблемы практического применения стандартной технологии.

    Описанная выше технология позволяет использовать VantageTeam Builder как средство ускоренной
    разработки приложений с однотипным интерфейсом и функциональными возможностями для
    различных таблиц. Однако, она не свободна от ряда недостатков, существенно снижающих ее
    достоинства. Одним из них является выбранный для разработки шаблонов эталон интерфейса и
    программного кода. Он:

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

    С учетом соотношения цен вряд ли целесообразно использовать VantageTeam Builder при разработке
    относительно простых приложений. В более сложных же проектах неизбежно возникает проблема
    доработки автоматически сгенеренных кодов программ с целью выполнения специфических
    требований заказчика касательно работы с конкретными таблицами. Причем чем крупнее проект, тем
    больше таких специфических таблиц и тем лучше эти изменения должны быть задокументированы.
    При выбранной же структуре шаблонов внесение даже таких мелких изменений, как использование
    дополнительных опций оператора INPUT (например, BEFORE INPUT или BEFORE FIELD),
    означает либо незадокументированное и, следовательно, не воспроизводимое при необходимости
    повторной генерации текста ручное внесение исправлений в автоматически сгенеренный текст, либо
    отказ от использования шаблонов и переход на практически ручное (хотя и структурное)
    программирование.

    Тиражирование данных

    Механизм тиражирования Informix-ODS позволяет поддерживать копию первичного сервера на
    вторичном сервере, который в обычном режиме доступен только на чтение и может, например,
    использоваться для выполнения приложений DSS. При отказе первичного сервера вторичный
    переключается в режим чтения-записи, и все клиенты переключаются на него.

    Informix-OXPS обеспечивает тиражирование на уровне узлов: копия узла, содержащего базу (или
    ее фрагмента), поддерживается на другом узле. При отказе основного узла клиенты переключаются
    на дублирующий, продолжая работать с копией данных.

    Игнорирование недоступных данных

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

    Администрирование баз данных в оперативном режиме

    Существенный фактор обеспечения непрерывной доступности данных - возможность выполнять
    основные административные действия без останова сервера. Серверы Informix позволяют в
    оперативном многопользовательском режиме выполнять такие процедуры, как изменение
    параметров конфигурирования, рефрагментация таблиц, добавление и уничтожение столбцов,
    создание и уничтожение индексов, сохранение и восстановление данных, замена диска, изменение
    конфигурации узла OXPS.

    Факторы, влияющие на производительность объектно- реляционной СУБД Illustra:


  • Выполнение функций на сервере. Предотвращает передачу больших
    интерпретированных массивов данных клиенту.
  • Поддержка функциональных индексов. Позволяет ускорить доступ к
    данным, основанным на результатах вычисления функций.
  • Функции сравнения для определяемых пользователем типов. Возможность
    ввести такие функции позволяет интеллектуализировать методы поиска по
    полям такого типа.
  • Расширяемость наборов методов доступа. Метод B-tree не всегда является
    лучшим решением. Существует возможность определить оптимальный метод
    доступа для конкретного типа данных.

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

    Методология определяет процесс создания корпоративных информационных систем как процесс
    построения и последовательного развития систем согласованных моделей, начиная от системы
    моделей, описывающих деятельность организации, и заканчивая готовой информационной
    системой. Модели должны создаваться, преобразовываться и контролироваться с помощью
    соответствующих CASE-средств и сохраняться в репозитории.

    Отправной точкой процесса создания ИС являются модели бизнес-процессов, протекающих в
    организации и реализующих ее цели и задачи. Если построена компьютерная модель организации,
    описанная в терминах бизнес-процессов и бизнес-функций, то из этой модели может быть получено
    большинство важнейших требований к информационной системе. Это фундаментальное
    положение методологии позволяет абсолютно объективно подойти к выработке требований и
    проектированию информационной системы. Создается система моделей описания требований к
    ИС, которая затем преобразуется в систему моделей, описывающих проект ИС. Формируются
    модели архитектуры ИС, требований к программному обеспечению (ПО) и информационному
    обеспечению (ИО). Затем формируется архитектура ПО и ИО, выделяются корпоративные БД и
    отдельные приложения, формируются модели требований к приложениям и проводится их
    разработка, тестирование и интеграция. На представлен комплекс развивающихся систем
    согласованных моделей (КРССМ), который показывает состав и последовательность развития
    систем моделей, создаваемых в процессе построения ИС.

    Развитие и преобразования моделей происходит в соответствии со схемой преобразования
    моделей, представленной на , обеспечивающей полноту и согласованность на каждом уровне
    преобразования моделей, что обеспечивает корректное формирование и реализацию всех
    требований к ИС. Архитектурные рамки для развития систем согласованных моделей,
    определяемые схемой преобразования моделей, основаны на модели Закмана.

    Одновременная поддержка нескольких языков

    Все более актуальной становится возможность использования одного и того же приложения в
    различных странах на разных языках с учетом национальных традиций и особенностей. В России
    ряд разработчик также столкнулся с такого же рода задачей. Российские приложения хотят
    эксплуатировать на Украине, в Казахстане, в других странах бывшего Советского Союза. При
    этом встает вопрос поддержки национальных алфавитов каждой из этих стран. Progress Software
    разработала специальный продукт Translation Manager 2 для решения этих вопросов. В его состав
    входят две основные компоненты - Translation Manager и Visual Translator.

    Описание процесса перевода приложения

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

    Руководитель проекта определяет те процедуры, которые должны быть переведены на другой
    язык. После этого он указывает фильтр для типов сообщений, которые необходимо перевести в
    каждой процедуре. Такими типами могут быть: меню, метки, наименования кнопок и т.д. После
    этого происходит формирование задания на перевод для переводчиков. В задание могут быть
    включены стандартные словари, содержащие перевод основных терминов, при этом допускается
    использование стандартных словарей фирмы Microsoft, которые использовались для перевода
    Word и Excel. При этом выдается вся статистика, позволяющая оценить трудоемкость работы и
    возможные сроки ее окончания. Переводчику передается только информация, необходимая для
    перевода без логики самого приложения. Задание может посылаться по почте, на дискете или иным
    способом.

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

    Руководитель проекта, собрав полученные работы от переводчиков, консолидирует их работу и
    выполняет компиляцию приложений. После этого с данным приложением можно работать с
    использованием нового языка. Для указания языка используется стартовый параметр - lng.

    _prowin.exe -p _desk.p -lng Russian

    Особо - о временных характеристиках и транзакциях

    Обеспечение эксплуатационных характеристик БД - по-прежнему непростая задача несмотря на
    повышение удельной мощности компьютеров и снижение удельной стоимости памяти. При этом
    определение временных характеристик работы с БД и сохранение этих характеристик в процессе
    эксплуатации БД относится к труднейшим проектным задачам. На этапах проектирования для
    определения рациональной физической схемы БД от способов определения временных
    характеристик нужно следующее:


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

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

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

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

    Нужно будет обнаруживать пределы возможностей такого деления работ на достаточно мелкие
    порции. Здесь отметим очень важный эффект: практика ориентации на "транзакционный подход"
    тесно связана с классической методологией проектирования БД, которая развивалась, в основном,
    как методология проектирования так называемы "операционных" БД, то есть баз данных, которые
    должны фиксировать отдельные совершаемые операции и хранить модель текущего фактического
    состояния объекта или ПрО.

    Поддержание целостности данных в СУБД

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

    Известно, что главными врагами баз данных являются не внешние злоумышленники, а ошибки
    оборудования, администраторов, прикладных программ и пользователей. Защита от подобных
    ошибок - главная тема этого раздела.

    С точки зрения пользователя СУБД, основными средствами поддержания целостности данных
    являются ограничения и правила.

    Сервер Informix - среда высокой доступности данных

    Серверные продукты Informix содержат целый спектр средств для поддержания доступности
    данных. Сочетание этих средств позволяет обеспечить разные уровни надежности и
    отказоустойчивости в зависимости от потребностей приложений и от наличных аппаратных
    ресурсов.

    Сервер Informix - среда высокой доступности данных

    Системы БД с многоуровневой защитой

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

    После создания нового отношения все привилегии, связанные с этим отношением и всеми его
    столбцами, принадлежат только пользователю-создателю отношения. В число привилегий входит
    привилегия передачи всех или части привилегий другому пользователю, включая привилегию на
    передачу привилегий. Технически передача привилегий осуществляется при выполнении оператора
    SQL GRANT. Существует также привилегия изъятия всех или части привилегий у пользователя,
    которому они ранее были переданы. Эта привилегия также может передаваться. Технически
    изъятие привилегий происходит при выполнении оператора SQL REVOKE. Проверка
    полномочности доступа к данным происходит на основе информации о полномочиях,
    существующих во время компиляции соответствующего оператора SQL.

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

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

    []
    []
    []

    Средства ускорения разработки приложений

    Как видно из предыдущего описания, VantageTeam Builder позволяет вести разработку проектов
    весьма высокой сложности. Графические редакторы и средства контроля существенно упрощают
    анализ задачи и проектирование приложения, упрощая и ускоряя работу аналитиков и
    проектировщиков. Программист же получает на первый взгляд не так уж много:

  • удобный инструмент создания базы данных с генерацией полезных
    хранимых процедур;
  • несколько более удобный, чем опция Forms в стандартной среде разработки
    Informix-4GL, инструмент генерации экранных форм, который сразу формирует
    экранные массивы и нужные пользователю названия полей, в том числе, на
    русском языке;
  • возможность придерживаться классического структурного подхода,
    поскольку программирование теперь выглядит как "вписывание" необходимых
    операторов в соответствующие элементы структурной схемы программы.
    Нередко от программистов на этой стадии знакомства с CASE-технологией можно услышать: "Ну в
    фазах анализа и архитектуры мне просто нечего делать, а программу написать я могу и не по
    квадратикам. Я их уже столько написал. Возьму нужный фрагмент из какой-нибудь старой
    программы, изменю имена полей и таблиц и готово". Однако более детальное знакомство с
    VantageTeam Builder показывает, что он может оказывать программисту очень большую помощь в
    решении именно этой задачи - написании новой программы по старому образцу.

    Сущности и атрибуты в реляционной модели

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

    Предположим, в базе данных хранится информация о служащих. Таблица "покупатель" содержит 3
    колонки и 4 строки:

    Имя
    Адрес
    Идент. карты
    Сидоров
    		1 улица 8 марта
    		 444444
    Иванов
    		2 улица 8 марта
    		 222222
    Петров
    		3 улица 8 марта
    		 333333
    Павлов
    		4 улица 8 марта
    		 111111
    Имя таблицы и имена ее колонок составляют структуру таблицы: customer (name,
    address, card_id). В реляционной модели все значения данных являются атомарными, т.е. нельзя в
    клетке таблицы хранить список значений.

    Таблицы в реляционной модели соответствуют (не обязательно совпадают по имени) сущностям, а
    колонки - атрибутам.

    Эталонный интерфейс для произвольной таблицы БД.

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

    Как легко видеть, эталонный интерфейс для работы с произвольной таблицей базы данных включает
    три экранные формы:

  • форма ввода и модификации информации - add_form (она же
    используется для просмотра записей при удалении - delete_form);
  • форма формирования запроса на поиск - find_form;
  • форма списка с двумя подрежимами :
    а
  • список с отметками, в котором можно отметить одну или более
    записей для проведения с ними определенной операцией - list_form;
    а
  • список с выбором единственной - choose_form (для выбора
    записей из словарей при экспорте ссылок или значений в вышестоящую
    таблицу).
    Для выбора начальной операции с таблицей и операций с выбранной записью (записями) из
    списка используются вертикальные меню (реализуемые специальной функцией). При начале
    работы с таблицей можно выбрать режим ввода новой записи, либо поиска всех записей по
    введенному запросу с формированием списка найденных записей. После ввода новой записи
    пользователь также получает список, хотя и состоящий из одной этой записи. Отметив одну или
    несколько записей в списке вы попадаете в меню выбора операции. Среди них ввод новой записи
    по образцу (введенная запись добавляется в список), модернизация или удаление отмеченных
    записей.

    При формировании полноэкранной формы для работы с таблицей и ее словарями поля базовой
    таблицы разбиваются на видимые и невидимые (но поддерживаемые программой). К последним, как
    правило, относятся уже упоминавшееся сериальное поле, импортированные из словарей (master-
    tables) их сериальные поля, а также (в нашей разработке, реализуемой с помощью генератора) поля с


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

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

    Хотя это является явным "ограничением общности", принятое решение представляется нам весьма
    разумным, ибо приучает пользователя к единообразному представлению записи, где бы она не
    появилась.

    Эталонный интерфейс для произвольной таблицы БД.

    Кластерная организация сервера баз данных

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

    В настоящем разделе будет рассмотрена разработка компании Sun Microsystems, Inc -
    SPARCcluster PDB Server (параллельный сервер баз данных на основе SPARC-кластера).

    5.1.1. Аппаратная организация SPARCcluster PDB Server

    В минимальной конфигурации SPARCcluster PDB Server состоит из двух узлов SPARCserver 1000,
    двух дисковых подсистем SPARCstorage Array и консоли кластера (SPARCclassic). Узлы-
    компьютеры соединяются между собой посредством быстрого Ethernet (100 Мбит/с), дисковые
    подсистемы подключаются через оптоволоконные каналы. В более мощной конфигурации вместо
    SPARCserver 1000 может использоваться SPARCcenter 2000, а число дисковых подсистем способно
    достигать 32 (до 1 Тб дискового пространства). Каждый узел кластера - это многопроцессорный
    компьютер, к которому, помимо прочих, подключены накопители на DAT-лентах (или
    автозагрузчики кассет с такими лентами). Все связи с компьютерами и дисковыми подсистемами
    продублированы.

    Следующий рисунок поясняет аппаратную организацию SPARCcluster PDB Server.

    Кластерная организация сервера баз данных
    Рис. 1. Аппаратная организация SPARCcluster PDB Server (на
    рисунке не показаны связи кластера с внешним миром)

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

    Вся аппаратура устроена так, что допускает замену в горячем режиме, без остановки других


    компонентов кластера.

    5.1.2. Программная организация SPARCcluster PDB Server

    Если рассматривать программную организацию SPARCcluster PDB Server в контексте надежной
    работы баз данных, необходимо обратить внимание еще на один компонент - фронтальную
    машину, на которой выполняется какой-либо монитор транзакций, например, TUXEDO. С учетом
    этого дополнения программная организация приобретает следующий вид.

    Рассмотрим компоненты программного обеспечения SPARCcluster PDB Server.

    Устойчивый к отказам распределенный менеджер блокировок (Fault Tolerant Distributed Lock
    Manager, FT-DLM) управляет параллельным доступом к базам данных, устанавливая и снимая
    блокировки. Кроме того, FT-DLM нейтрализует последствия отказов, снимая блокировки,
    установленные вышедшим из строя узлом. FT-DLM взаимодействует с сервером Oracle для
    поддержки неблокируемых операций чтения и для блокировки на уровне строк при записи в
    таблицы. В результате обеспечивается целостность и сериализация транзакций в сочетании с
    параллельной работой узлов кластера и с параллельным доступом к нескольким дисковым
    подсистемам.

    Кластерная организация сервера баз данных
    Рис. 2. Программная организация SPARCcluster PDB Server
    (узлы кластера работают под управлением ОС Solaris версии 2.4 или
    выше)

    Распределенность менеджера блокировок означает, что на каждом узле кластера работает свой
    экземпляр FT-DLM и что FT-DLM умеет динамически реконфигурировать себя (как при выходе
    узлов из строя, так и при добавлении новых узлов). В результате выход из строя одного узла не
    означает краха всего сервера баз данных - сервер жив, пока работает хотя бы один менеджер
    блокировок.

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

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


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

    Подсистема управления кластером состоит из трех инструментов с графическим интерфейсом:
    консоли кластера, менеджера томов и менеджера сервера Oracle. Их интеграция обеспечивает
    централизованное оперативное управление всеми ресурсами кластера.

    5.1.3. Нейтрализация отказа узла

    Рассмотрим, как в SPARCcluster PDB Server реализована нейтрализация самого неприятного из
    отказов - отказа узла. Программное обеспечение предпринимает при этом следующие
    действия:


  • Подсистема обнаружения отказов выявляет вышедший из строя узел.
  • Создается новая конфигурация кластера, без отказавшего узла. Этот
    процесс занимает 1 - 2 минуты, в течение которых обработка транзакций
    приостанавливается.
  • Менеджер блокировок производит восстановление:
    а
  • Подтвержденные транзакции от отказавшего узла (транзакции, об
    успешном завершении которых другие узлы кластера не успели узнать)
    накатываются вперед и деблокируются.
    а
  • Неподтвержденные транзакции от отказавшего узла откатываются и
    также деблокируются.

    В этот период транзакции обрабатываются исправными узлами, но, вероятно, несколько
    медленнее, чем обычно.


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

    Отметим, что все действия, исключая ремонт отказавшего компонента, выполняются в
    автоматическом режиме и не требуют вмешательства обслуживающего персонала. Следует
    учитывать, однако, что если следующая поломка случится до окончания ремонта, кластер может
    на какое-то время стать неработоспособным, поэтому затягивать ремонт не рекомендуется.

    Строго говоря, SPARCcluster PDB Server не поддерживает одну из важных кластерных функций - с
    внешней точки зрения кластер не выглядит как единое целое. Прикладные программы могут
    напрямую подключаться к его узлам, и тогда отказы узлов требуют нейтрализации на прикладном
    уровне. В то же время использование мониторов транзакций позволяет сгладить этот недостаток,
    обеспечивая к тому же балансировку загрузки между узлами.

    Атрибуты и генерация эталонного интерфейса.

    Одним из инструментов VantageTeam Builder, поддерживающих генерацию по шаблону, являются
    задаваемые пользователем атрибуты для любых элементов любых типов диаграмм. Детальный анализ
    эталонного интерфейса показал, что его реализация требует задания для каждой таблицы и ее
    полей некоторых дополнительных атрибутов, среди которых основными являются признак видимого
    поля, признак вхождения поля в альтернативный ключ, признак вхождения поля в строковое
    представление, тип вычисляемого поля для представления словарной таблицы. Перечисленные выше
    атрибуты наиболее естественным образом могут быть введены на ER-диаграммах, поскольку при
    принятой нами логике построения приложения, их значения единственны для всех форм, имеющих
    отношение к данной таблице.

    Отсутствие в CASE'е версии 3.1 инструментов генерации сложных экранных форм привело к
    необходимости построения собственного генератора экранных форм, генерящего для каждой
    таблицы формы для ввода/модификации информации и для формирования запросов, который также
    вошел в состав GRINDERY One-Step 4GL.

    С точки зрения скорости получения работающего приложения, чем крупнее шаблон, тем лучше.
    Соответственно, мы ограничились одним шаблоном на весь набор функций, обеспечивающих работу
    с таблицей (в отличие от VantageTeam Builder, мы генерим не одну функцию, а несколько,
    основными из которых являются функция для ввода/модификации, функция для удаления
    отмеченных в списке записей, функция просмотра записи, соответствующей "словарному" полю или
    строке в списке, функция ввода запроса и формирования списка найденных записей и функция
    формирования строкового представления). Однако, пойдя по такому пути мы не могли не столкнуться
    с проблемой доработки прототипа. Вносить в него изменения вручную легче, чем в текст,
    генерящийся по стандартным шаблонам, поскольку он разбит на отдельные функции и уже за счет
    этого лучше структурирован. Сложность же здесь, как и при использовании стандартных шаблонов,
    возникает прежде всего потому, что при внесении изменений непосредственно в текст модуля с одной
    стороны ухудшается степень документированности проекта, а с другой теряется возможность
    перегенерации кода программы при внесении каких-либо изменений в структуру таблиц или
    переназначении дополнительных атрибутов. В настоящее время для решения этой проблемы
    изменения, которые вносятся в текст программного модуля, записываются в специальные файлы (по
    одному на каждый модуль) со специальными метками, указывающими куда именно внесено
    изменение. Таким образом достигается и определенная документированность внесенных уникальных
    изменений (хотя они и не отражаются на каких-либо диаграммах, их значительно легче найти в таком
    файле, чем в полном тексте программы,) и их повторное использование при перегенерации
    программы.

    Тиражирование данных

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

    Развитые возможности тиражирования предоставляет СУБД INGRES. Им посвящена статья href="#lit">[2]    . Здесь мы рассмотрим возможности другого популярного сервера СУБД -
    Informix OnLine Dynamic Server (OnLine-DS) 7.1. В отличие от предыдущего раздела, речь пойдет
    об обычных (а не кластерных) конфигурациях.

    В Informix OnLine-DS 7.1 поддерживается модель тиражирования, состоящая в полном
    отображении данных с основного сервера на вторичные.

    В конфигурации серверов Informix OnLine-DS с тиражированием выделяется один основной и ряд
    вторичных серверов. На основном сервере выполняется и чтение, и обновление данных, а все
    изменения передаются на вторичные серверы, доступные только на чтение . В случае отказа основного сервера вторичный автоматически или вручную переводится в
    режим доступа на чтение и запись . Прозрачное перенаправление
    клиентов при отказе основного сервера не поддерживается, но оно может быть реализовано в
    рамках приложений.

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

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


    вторичном, даже в случае сбоя основного сервера. Асинхронный режим не обеспечивает
    абсолютной согласованности, но улучшает рабочие характеристики системы.



    Тиражирование данныхТиражированиеТиражирование данных
    Тиражирование данныхТиражирование данных Тиражирование данныхТиражирование данных
    Тиражирование данных

    Тиражирование данных
    Тиражирование данных
    Тиражирование данныхТиражирование данныхТиражирование данных
    		Тиражирование данных
    Основной
    сервер    		Вторичный
    сервер

    Рис. 3. Тиражирование. Основной сервер доступен на
    чтение и запись, вторичный - только на чтение.



    Тиражирование данных
    		 Тиражирование данных
    Тиражирование данных
    		Тиражирование данных
    		Тиражирование данных
    		Тиражирование данных
    		Тиражирование данных
    Тиражирование данных
    Тиражирование данных
    		Тиражирование данных
    		Тиражирование данных
    		Тиражирование данных
    		Тиражирование данных
    		Тиражирование данных
    Основной
    сервер    		Стандартный
    сервер

    Рис. 4. Когда основной сервер выходит из строя,
    вторичный переводится в режим доступа и на чтение, и на запись.

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

    Применение и перспективы развития GRINDERY One-Step 4GL.

    Написанный нами кодогенератор прошел серьезную практическую проверку как основной инструмент
    написания кода при разработке системы автоматизации коммерческой и производственной
    деятельности нашей фирмы. С его помощью было сгенерено не менее 80% общего объема приложения
    (около 2 Мб исходных текстов программ) и почти все экранные формы. В целом он, по нашим
    оценкам, сократил в несколько раз время написания кода по сравнению с проектами, выполнявшимися
    вручную. Существенно упростилась отладка и тестирование приложения, поскольку из автоматически
    сгенеренного кода для работы с примерно полусотней таблиц достаточно проверить один-два
    стандартных варианта. Тщательного тестирования требуют лишь те 20% кода, которые написаны
    полностью или частично вручную.

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

    Другое направление, в котором мы надеемся усовершенствовать кодогенерацию, это повышение
    степени документированности вносимых изменений. И здесь, как нам кажется, нам удалось найти
    интересное решение, основанное на возможности CASE'а версии 3.2. использовать одну структурную
    схему для генерации программных модулей, предназначенных для работы с различными
    таблицами.

    Генератор GRINDERY On-Step 4GL

    Перечисленные выше недостатки стандартных шаблонов VantageTeam Builder заставили нас
    задуматься о разработке собственных шаблонов. При этом необходимо отметить, что произошло это
    еще при использовании CASE'а версии 3.1. В отличии от версии 3.2. он не позволял использования
    одной и той же структурной схемы для различных экранных форм (в библиотечных модулях было
    необходимо явно указывать, для какой таблицы необходимо сгенерить код) и не поддерживал
    диаграмм Содержания экранных форм. Поэтому для реализации идеи автоматической генерации
    значительной части кода приложения с достаточно большими функциональными возможностями
    было необходимо строго формализовать не только принципы формирования программного кода, но и
    принципы построения экранной формы.

    Рассмотрение в данном разделе инструмента кодогенерации будет проводится на примере алфавитно-
    цифровой среды разработки приложений INFORMIX-4GL, что не является ограничением общности
    подхода, как это будет видно из дальнейшего, но удобно для нас с методологической точки
    зрения.

    Illustra DataBlades

    Описание, основные рынки приложений и преимущества использования модулей DataBlades:


  • Text
  • Вводит новый тип doc и функции для работы с содержимым
    документов, включая сравнение документов и проверку на содержание слов.
  • Определяет новый метод доступа для документов - D-tree.
  • TimeSeries
  • Вводит новые типы: calendar и timeseries, возможности определения
    календарей и функции для работы с данными временных рядов.
  • Производительность работы с данными временных рядов
    повышается в сотни раз по сравнению с РСУБД.
  • Типичные приложения: управление финансовыми портфелями,
    анализ экспериментальных результатов, анализ видеопоследовательностей.
  • 2D & 3D Spatial:
  • Добавляет десятки новых типов данных, представляющие собой
    двумерные и трехмерные графические объекты, а также более 100 функций
    для работы с такими объектами.
  • Новый метод доступа, наиболее эффективный для таких данных, -
    R-tree.
  • Типичные приложения: геоинформационные системы.
  • Web
  • Добавляет новый тип данных anchor. Позволяет легко использовать
    новые типы данных и функции преобразования и поиска информации.
  • Позволяет получать прямые ссылки (URLs) на объекты внутри базы
    данных.
  • SQL обеспечивает дополнительный уровень безопасности
    информации в сети.
  • Типичные приложения: сетевые публикации, каталоги.
  • Image
  • Вводит новый тип image, поддерживая 49 форматов изображений, и
    продвинутые функции для работы с изображениями.
  • Позволяет простое расширение для поддержки новых графических
    форматов.
  • Типичные приложения: графические библиотеки.

    Интегральные средства управления

    Программное обеспечение Informix-OXPS тесно интегрировано с развитой средой системного
    управления Tivoli Management Environment (TME), разработанной компанией Tivoli Systems Inc.
    (Начиная с версии 8 аналогичные средства системного управления будут реализованы и для
    Informix ODS.) Среда управления скрывает от администраторов внутреннюю сложность
    аппаратных конфигураций кластерных архитектур и систем MPP, предоставляя единую точку
    обзора объектов баз данных, независимо от их физического местоположения.

    Управление базами данных существенно упрощается благодаря наглядному графическому
    пользовательскому интерфейсу систем администрирования. Администратор работает с
    графическим представлением объектов баз данных и легко может получить информацию о статусе
    каждого из них. За счет интеграции со средой сообщений и планировщиком TME, предоставляется
    единая точка планирования и обработки событий в базах данных, а также рассылки сообщений,
    относящихся к состоянию баз данных.

    В рамках TME поддерживается комплект развитых приложений, охватывающих все аспекты
    деятельности, связанной с администрированием баз данных:


  • Управление, конфигурирование, слежение за текущим состоянием;
  • Резервирование журналов транзакций, архивирование, восстановление;
  • Мониторинг характеристик производительности;
  • Анализ, экспертная помощь в физическом конфигурировании данных;
  • Параллельная загрузка баз данных;
  • Управление тиражированием для распределенных баз данных;
  • Управление реляционными объектами.

    Методология анализа ИС на основе бизнес-процессов

    Целью начальных этапов создания ИС, выполняемых на стадии анализа, является формирование
    требований к ИС, корректно и точно отражающих цели и задачи организации. Чтобы описать
    процесс создания ИС, отвечающей целям и задачам организации, нужно выяснить в чем
    заключаются эти цели и задачи. Нужно выяснить требования заказчиков к ИС и преобразовать их
    на языке моделей в требования к разработке проекта ИС так, чтобы обеспечить соответствие
    целям и задачам организации.

    Современные средства позволяют достаточно быстро создавать ИС по готовым требованиям. Но
    как отмечалось выше, очень часто оказывается, что эти системы не удовлетворяют заказчиков. Их
    приходится постоянно дорабатывать, что приводит к резкому удорожанию фактической
    стоимости ИС. Основной причиной такого положения является неправильное, неточное или
    неполное определение требований к ИС. И это не случайность. Как правило, заказчики не могут
    правильно и точно сформулировать требования к ИС. Более того, они зачастую не могут точно
    определить основные цели и задачи своей организации. Задача разработчиков заключается в том,
    чтобы извлечь эту информацию из заказчиков. Проблема формирования требований к ИС
    остается до настоящего времени одной из наиболее трудно формализуемых и наиболее дорогих и
    тяжелых для исправления в случае ошибки. Именно поэтому столь велика роль начальных этапов
    ЖЦ создания ИС, когда эти требования должны быть выявлены и формализованы, в получении
    конечного результата. Предлагаемая методология определяет, какие виды данных должны
    собираться в организации в процессе обследования и какие модели строиться для того, чтобы
    сформировать требования к ИС.

    Основу деятельности любой организации составляют ее деловые процессы, или бизнес-процессы,
    которые определяются целями и задачами организации. Процессы обеспечивают реализацию всех
    видов деятельности организации, связанных с производством товаров и/или услуг, которые
    корпорация либо производит, либо продает и поставляет, либо делает все это в совокупности.


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

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

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

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

    Оценка достигнутого состояния

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

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

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

    Можно, конечно, поставить под сомнение ценность таких исследований. Действительно, каким бы
    плохим ни был язык программирования, его в конце концов все-таки можно выучить. Точно также и
    средства СУБД можно освоить за определенный период времени. Но проблема состоит не в освоении
    средств, а в эффективности их использования. Машина должна быть служанкой человека, но не
    наоборот!

    Выше шрифтом выделена цитата из []. С тех пор СУБД, методы проектирования БД и
    соответствующие инструменты значительно прибавили в возможностях. Но остальной мир тоже не
    стоял на месте, существенно усложнились стоящие перед разработчиками ИС и БД задачи. И надо
    признать: формулировки Цикритзиса и Лоховски не устарели.

    Средства поддержания высокой готовности

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

    Подобные средства должны с самого начала закладываться в архитектуру комплекса. Например,
    необходимо использовать тот или иной вид избыточных дисковых массивов. Конечно, это сделает
    аппаратно-программное решение более дорогим, но зато убережет от возможных убытков во
    время эксплуатации.

    Связи в реляционной модели

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

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

    Получение информации путем логических выводов

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

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

    Еще один пример - выяснение набора первичных ключей таблицы при наличии только привилегии
    INSERT (без привилегии SELECT). Если набор возможных значений ключей примерно известен,
    можно пытаться вставлять новые строки с "интересными" ключами и анализировать коды
    завершения SQL-операторов. Как мы видели из предыдущего примера, сам факт присутствия
    определенного ключа в таблице может быть весьма информативным.

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

    Основным средством борьбы с подобными угрозами, помимо тщательно проектирования модели
    данных, является механизм размножения строк. Суть его в том, что в состав первичного ключа,
    явно или неявно, включается метка безопасности, за счет чего появляется возможность хранить в
    таблице несколько экземпляров строк с одинаковыми значениями "содержательных" ключевых
    полей. Наиболее естественно размножение строк реализуется в СУБД, поддерживающих метки
    безопасности (например, в INGRES/Enhanced Security), однако и стандартными SQL-средствами
    можно получить удовлетворительное решение.

    Продолжая медицинскую тематику, рассмотрим базу данных, состоящую из одной таблицы с
    двумя столбцами: имя пациента и диагноз. Предполагается, что имя является первичным ключом.
    Каждая из строк таблицы относится к одному из двух уровней секретности - высокому (HIGH) и
    низкому (LOW). Соответственно, и пользователи подразделяются на два уровня благонадежности,
    которые мы также будем называть высоким и низким.

    К высокому уровню секретности относятся сведения о пациентах, находящихся под надзором
    правоохранительных органов или страдающих специфическими заболеваниями. На низком уровне
    располагаются данные о прочих пациентах, а также информация о некоторых "секретных"
    пациентах с "маскировочным" диагнозом. Части таблицы могут выглядеть примерно так:


    ИмяДиагноз
    ИвановСПИД
    ПетровСифилис
    СидоровСтреляная рана

    Агрегирование данных

    Агрегирование - это метод получения новой информации путем комбинирования данных, добытых
    легальным образом из различных таблиц. Агрегированная информация может оказаться более
    секретной, чем каждый из компонентов, ее составивший. В качестве примера можно рассмотреть
    базу данных, хранящую параметры всех комплектующих, из которых будет собираться ракета, и
    инструкцию по сборке. Данные о каждом виде комплектующих необходимы поставщикам,
    инструкция по сборке (вставьте деталь A в отверстие B) - сборочному производству.

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

    Повышение уровня секретности данных при агрегировании вполне естественно - это следствие
    закона перехода количества в качество. Бороться с агрегированием можно за счет тщательного
    проектирования модели данных и максимального ограничения доступа пользователей к
    информации.

    Покушения на высокую готовность (доступность)

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


    Покушения на высокую готовность (доступность)
    Рис. 5. Конфигурация прикладной или инструментальной
    среды клиент-сервер, использующей Informix-DCE/Net.

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

    Что и как из классических методов проектирования применяется в практике настоящего времени

    Применяются на практике:


  • СУБД, поддерживающие реляционную модель данных 1971 года с
    некоторыми расширениями (см., например, []);
  • Иерархическая "каскадная" схема структурного проектирования БД при
    подходе "сверху-вниз";
  • CASE-системы для структурного проектирования баз данных, ИС в целом
    или, к тому же, прикладных программ ИС. Наиболее часто используются:
    варианты ER-модели данных; табличная реляционная модель 1971 года,
    расширенная тем или иным дополнительным набором средств описаний
    ограничений целостности (ссылочная целостность, бизнес-правила); для
    анализа "процессного" источника сведений чаще всего предоставляются
    модели потоков данных или SADT, возможно, расширенные дополнительными
    связями по управлению (эти связи нельзя смешивать с выделенными потоками
    условий выполнения функций в нотации IDEF0);
  • Утилиты динамического администрирования БД, обеспечивающие
    следующие функции:
  • отслеживание динамики показателей эксплуатации БД: показатели
    доступны в любой момент на фоне работы приложений, эти показатели
    ("статистика") могут использоваться для поддержки оптимального
    динамического построения путей доступа к данным,
  • создание резервных копий БД, также как и ведение копий БД
    горячего резерва на фоне работы приложений, восстановление и откат
    фрагментов и полной БД,
  • возможна динамическая реорганизация БД (переразмещение БД и
    отдельных физических фрагментов, логическая и физическая
    реструктуризация данных), однако, эти возможности являются
    ограниченными.
  • Учет пользовательских требований к представлению данных в большем
    диапазоне, чем ранее. Требования к учету специфики представлений часто
    стали преобразовываться из положений желательности наличия разных
    внешних моделей данных к положению доступности значительного числа
    пользовательских инструментов, имеющих различные интерфейсы и,
    практически, различные внешние модели данных.

    Методология проектирования от данных

    Поскольку данные составляют основу деятельности любой организации и являются наиболее
    стабильной ее составляющей (функции и структура организации меняются гораздо чаще), то при
    построении корпоративной ИС наиболее адекватным решаемым задачам является подход к
    проектированию, основанный на данных. Такой подход обеспечивает наилучшее архитектурное
    решение при разбиении системы на приложения, а также простоту и согласованность при
    интеграции приложений. В основу процессов проектирования и разработки ПО и ИО положены
    методология проектирования от данных DATARUN, которая была разработана в компании CSA
    (США) для проектирования и быстрой разработки программного и информационного
    обеспечения переносимых распределенных ИС в архитектуре клиент-сервер. Эти возможности
    основаны на использовании современных инструментальных средств моделирования, быстрого
    прототипирования и разработки.

    Методология DATARUN основана на моделях. Она поддерживает принципы формирования и
    развития моделей, заложенные в КРССМ. Модель требований к ПО и ИО базируется на бизнес-
    процессах и формируется на основе системы моделей требований к ИС. Процесс проектирования
    основан на извлечении всех данных из моделей бизнес-процессов, построении и развитии моделей
    данных (концептуальной модели данных, модели архитектуры ИС, полной реляционной модели
    данных и т.д., вплоть до моделей, определяющих приложения). Эти модели взаимоувязаны и
    интегрированы друг с другом и определяют множество уровней спецификаций для каждого этапа
    разработки. В процессе проектирования модели данных развиваются от простой начальной версии
    в законченную спецификацию приложения, используемую для генерации. При этом полная
    реляционная модель данных может быть разделена на подмодели (подсхемы), представляющие
    разные части системы, которые могут быть распределены по сети в окружении клиент-сервер в
    соответствии с архитектурой ИС.

    По нашему мнению методология DATARUN объединяет лучшие черты реляционного
    проектирования, объектно-ориентированной технологии и подхода RAD (быстрого создания
    приложений). В общем ЖЦ ИС методология DATARUN охватывает этапы ЖЦ формирования
    требований к ПО и ИО и все этапы стадий проектирования, разработки, интеграции и
    тестирования и внедрения системы (в части ПО и ИО).

    Дальнейшие шаги по созданию ИС, выполняемые на стадиях сопровождения и развития ИС, не
    раскрываются в данном докладе. Методология их выполнения базируется на тех же основных
    принципах, что и описанные методологии. Эти шаги продолжают описанный выше процесс
    развития систем моделей, представленных в комплексе развивающихся систем согласованных
    моделей.

    Моделирование в ERwin

    Место ERwin в информационном моделировании

    Процесс построения информационной модели состоит из следующих шагов:

  • определение сущностей;
  • определение зависимостей между сущностями;
  • задание первичных и альтернативных ключей;
  • определение атрибутов сущностей;
  • приведение модели к требуемому уровню нормальной формы;
  • переход к физическому описанию модели: назначение соответствий имя
    сущности - имя таблицы, атрибут сущности - атрибут таблицы; задание
    триггеров, процедур и ограничений;
  • генерация базы данных.
    ERwin создает визуальное представление (модель данных) для решаемой задачи. Это представление
    может использоваться для детального анализа, уточнения и распространения как части документации,
    необходимой в цикле разработки. Однако ERwin далеко не только инструмент для рисования. ERwin
    автоматически создает базу данных (таблицы, индексы, хранимые процедуры, триггеры для
    обеспечения ссылочной целостности и другие объекты, необходимые для управления данными).

    Средства разработки.

    Средства разработки для UNIX платформ:


  • С/С++ интерфейс
  • LibMI. Библиотека, являющаяся клиентским интерфейсом для разработки
    приложений клиент-сервер. Этот интерфейс доступен для Sun OS, Solaris, SGI
    Irix, Dec Alpha OSF1, HP-UX, Windows NT и Windows 3.1.

    Средства разработки для Windows платформ:


  • - Visual Basic. У Illustra есть абстрактный VBLIBMI интерфейс к Visual Basic и
    она предоставляет компоненты VBX controls для отзыва на серверные
    алертеры
    - Visual C++. Интерфейс к Visual C++ предоставляется вместе с LIBMI DLL. -
    Средства для работы с базами, поддерживающими ODBC. У Illustra есть
    собственный ODBC-драйвер для сервера Illustra, поэтому приложения,
    поддерживающие ODBC, например, как Microsoft Visual Basic или Access, могут
    осуществлять доступ к базам данных Illustra.
  • LibMI.

    Illustra Query Tool (IQT).

    IQT - это графический Windows (3.1, 95, NT) интерфейс запросов к серверу Illustra. Он позволяет
    вам подключиться к серверу Illustra, выполнять команды Illustra SQL и просматривать
    результаты.

    Угрозы, специфичные для СУБД

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

    Мы рассмотрим несколько угроз, возникающих при использовании злоумышленником средств
    языка SQL.

    VantageTeam Builder и GRINDERY как средства разработки приложений для NewEra и SuperNOVA

    Получив такие результаты в части генерации 4GL приложений мы задумались над тем, нельзя ли
    приспособить кодогенератор к разработке приложений с использованием других средств разработки,
    прежде всего NewEra и SuperNOVA. Дело в том, что эти средства являются объектно-
    ориентированными и поддерживающими графический интерфейс. Теоретически разработка
    приложений для средств такого класса (также, как и приложений на С++) должна вестись с помощью
    CASE-средств, поддерживающие объектно-ориентированный подход, например, с помощью
    VantageTeam OO Builder той же фирмы CADRE. Однако такие средства разработки пока не
    пользуются в России заметной популярностью, что связано, видимо, с относительной новизной
    подхода и меньшей наглядностью проектов, выполненных с помощью какой-либо из объектно-
    ориентированных методологий. Фактически многие разработчики предпочли бы выполнять анализ и
    проектирование на основе структурного подхода, а разработку интерфейса и генерацию приложения
    вести с помощью объектно-ориентированных инструментов. И, как показал наш анализ, VantageTeam
    Builder вполне может справиться с этой задачей. Для этого его достаточно оснастить соответствующей
    версией нашего генератора GRINDERY NewEra/Yourdon или GRINDERY SuperNOVA /Yourdon

    Описанный выше подход, использовавшийся нами при разработке генератора 4GL приложений,
    оказался достаточно близок к объектному. Фактически, для каждой таблицы создается объект,
    состоящий из ее (видимых и невидимых) полей, импортированных полей и строковых представлений
    словарей. А выбранный эталон программной реализации по сути близок к стандартному набору
    методов для работы с построенным объектом. Это позволяло надеяться на относительную простоту
    переноса основных решений, используемых для процедурного языка Informix-4GL, на объектные языки
    NewEra и SuperNOVA.

    Тем не менее, при построении генераторов для NewEra и SuperNOVA нам пришлось решать весьма
    сложный принципиальный вопрос: как осуществить переход между богатыми возможностями
    графического интерфейса и значительно более ограниченными возможностями алфавитно-цифрового?
    В отличие от многих универсальных (позволяющих для одного приложения создавать и такой, и
    другой интерфейсы) средств разработки (к которым, кстати, относится и SuperNOVA) мы пошли не по
    пути копирования экрана, а по пути реализации аналогичного по функциональным возможностям
    набора методов. Выбор такого подхода во многом перенес тяжесть разработки на создание
    необходимой библиотеки классов, оставив задачей кодогенератора создание файлов прототипов
    экранных форм (WIF-файлы для NewEra и LGC-файлы для SuperNOVA). В результате кодогенератор,
    создающий необходимые WIF-файлы на основе все того же проекта, разработанного с помощью
    VantageTeam Builder, был написан еще быстрее, чем генератор для разработки 4GL приложений.

    Заключение

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

    Разумеется, в небольшом докладе невозможно дать полный и глубокий анализ двух столь сложных
    программных продуктов, каковыми являются серверы СУБД Informix-ODS и Informix-XPS.
    Заинтересованный читатель найдет развернутую информацию об архитектуре и возможностях
    серверных продуктов Informix в работах .



    Что теряется

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


  • полная процедура нормализации высоких степеней и минимизации набора
    отношений не проводится или проводится редко, если же экспертиза проверки
    на соответствие даже 3НФ или БКНФ предусмотрена в CASE-средствах, эта
    возможность редко используется на практике ввиду ее громоздкости и высоких
    требований к квалификации проектировщика, использующего CASE;
  • оптимизация размещения БД на устройствах внешней памяти проводится
    "на глазок", распространенные сегодня тесты временных параметров не
    приспособлены для помощи в решении этой задачи проектирования;
  • так же "на глазок" производится оптимизация размещения БД по узлам
    распределенной БД.

    Значительно меньшее внимание в последнее время уделяется и инструментальным средствам
    автоматизации физического проектирования БД, включая математическое и натурное
    моделирование характеристик БД, в том числе - с учетом размещения по узлам распределенной
    ИС. Оптимизация размещения БД по узлам распределенной БД не поддерживается
    распространенными CASE-средствами. Отдельные инструменты и работы, включая отечественные
    исследования, не делают "погоды" в Мастерской средств проектирования, и не поддерживают
    живой школы этого направления.

    Этому есть, на наш взгляд, несколько причин:


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

    История компании. Postgres - Montage - Illustra - Informix Universal Server. Перспективы развития

    Компания образована в 1992. Базой для флагманского продукта компании выступил
    исследовательский проект Postgres в университете Беркли ( 1985-1992 гг. ). На данный момент
    порядка 250 инсталляций в 17 странах. Ключевые партнеры - Sun, Intel, Silicon Graphics, America
    On Line, Fujitsu, AVID. Ключевые рынки - финансовые и банковские услуги, Internet, мультимедиа,
    структуры государственного управления, геоинформационные системы. Объединение технологий
    Illustra и Informix - 1996 год.

    []
    []
    []

    Комплекс согласованных инструментальных средств

    Предлагаемая методология создания ИС поддерживается комплексом согласованных между собой
    инструментальных средств, который обеспечивает непрерывный цикл автоматизации процессов,
    выполняемых на всех этапах ЖЦ ИС.. Согласованность этих средств обеспечивается наличием
    интерфейсов для прямого взаимодействия и поддержкой общепринятых стандартов открытых
    систем.

    Комплекс средств такого рода позволяет строить модели, описывающие деятельность
    организации, формировать требования к ИС, быстро переходить от моделей требований к ИС к
    проекту приложений и баз данных. Он обеспечивает поддержку быстрой итеративной разработки
    приложений, их тестирование и интеграцию в систему. Заложенные в методологию и
    поддержанные этими инструментальными средствами принципы, основанные на использовании
    моделей и повторном использовании спецификаций, обеспечивают возможность быстрого
    внесения изменений как на стадиях создания ИС, так и на стадиях сопровождения и развития.

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

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


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

    Защита коммуникаций между сервером и клиентами

    Проблема защиты коммуникация между сервером и клиентами не является специфичной для
    СУБД, она присуща всем распределенным системам. Вполне естественно, что и решения здесь
    ищутся общие, такие, например, как в распределенной вычислительной среде (Distributed
    Computing Environment, DCE) концерна OSF. Разработчикам СУБД остается "погрузить" свои
    программные продукты в эту среду, что и сделала компания Informix, реализовав Informix-
    DCE/Net .

    Informix-DCE/Net открывает доступ к сервисам DCE для всех инструментальных средств Informix,
    а также любых приложений или инструментальных комплексов от независимых поставщиков,
    которые используют интерфейс ODBC

    Ключевым компонентом в реализации взаимодействий клиент-сервер в среде DCE является сервис
    безопасности. Основные функции, предоставляемые этим сервисом, - аутентификация, реализуемая
    средствами Kerberos, авторизация (проверка полномочий) и шифрование.

    Informix-DCE/Net использует все средства обеспечения безопасности, имеющиеся в DCE.
    Например, для каждого приложения клиент-сервер администратор может задать один из пяти
    уровней защиты:


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

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

    Наличие единой точки администрирования входных имен и прав доступа к базам данных и
    приложениям способствует упорядочению общей ситуации с безопасностью. Например, если
    уничтожается входное имя DCE, то администратор может быть уверен, что данный пользователь
    уже не сможет получить доступ ни к одному из системных ресурсов.

    С начала 1996 года распространяется

    С начала 1996 года распространяется версия ERwin 2.5, в которой реализован ряд новых
    функций:

  • добавлена возможность редактирования диаграммы "по месту" (без
    необходимости входа в диалог);
  • диаграммы могут теперь отображаться в нотации IE (Information
    Engineering), как дополнение нотации IDEF1X;
  • усовершенствована функция автоматической "раскладки" таблиц на
    диаграмме; введена функция автоматической "раскладки" связей;
    максимальный размер диаграммы увеличен до 12х18 страниц (216 страниц);
  • существенно усовершенствована функция печати - добавлен режим
    "preview", введены настраиваемые заголовки страниц с макроподстановкой,
    поля, масштаб печати;
  • расширен набор поддерживаемых СУБД, а также введена поддержка для
    новых версий ранее поддерживаемых СУБД: Sybase System 11, Oracle 7,
    Microsoft SQL Server 6, Informix версия 7.1, DB2 3, IBM AS/400 версия 3 и RDB
    версия 6; существенно расширена поддержка для Teradata DBS и Progress 4GL;
    расширена поддержка физических параметров хранения информации для
    объектов базы данных;
  • введена функция генерации Data Window (ERwin для PowerBuilder)
    непосредственно в библиотеке PowerBuilder;
  • при определении расширенных атрибутов можно указать атрибуты для
    первичного ключа, которые мигрируют при использовании колонки в качестве
    внешнего ключа в подчиненных таблицах;
  • помимо поддерживавшихся и ранее расширенных атрибутов в версии для
    PowerBuilder и SQL Windows, введена поддержка атрибутов колонок (метки,
    форматы отображения, сообщения об ошибках) для PROGRESS 4 GL,
    Microsoft Access, Teradata, AS/400; теперь при разработке для этих СУБД
    можно уже на стадии информационного моделирования указывать, как колонка
    из базы данных будет отображаться в форме или отчете.

    Ограничения классических методов

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

    Спустя годы и десятилетия после объявления своих классических моделей и концепций классики в
    явном виде описывали их ограниченность. Так, в [] было указано, что "при обсуждении
    моделирования семантики данных акцент делается на структурные аспекты в ущерб аспектам
    обработки. Структура без соответствующих операций или подразумеваемых методов подобна
    анатомии в отсутствии физиологии".

    Еще через 14 лет Е. Кодд и соавторы в [] фиксировали: "... обладание большой
    корпоративной БД имеет маленькое значение, если конечные пользователи не имеют возможностей
    легко синтезировать необходимую информацию из этих запасов (складов) данных. Слишком часто
    мы имеем именно такие обстоятельства."

    Наконец, наступило время, когда проектирование БД (и ИС в целом) по классическим правилам
    полноты и целостности часто стало практически бессмысленным. Весли П. Меллинг (Garthner
    Group) указал в []: "К 1990 году почти все аспекты "стандартной процедуры работы"
    с ИТ (Информационными Технологиями - прим. Е.З.) были оспорены, и вычислительные архитектуры
    вырвались из-под контроля. ... Стандарты программирования размывались, а понятие
    неизбыточных, непротиворечивых, высококачественных данных годилось разве что для груды хлама."

    Для создания корпоративной информационной системы,

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

    При создании корпоративных информационных систем необходимым слагаемым успеха помимо
    методологии, является также и комплекс согласованных инструментальных средств,
    поддерживающий эту методологию и обеспечивающий автоматизацию процессов, выполняемых
    на всех этапах ЖЦ создания ИС. Эти средства должны поддерживать быстрое построение
    корпоративных ИС, отвечающих целям и задачам организации и удовлетворяющих основным
    требованиям (открытости, переносимости и масштабируемости и т.д.), а также обеспечивать
    поддержку процессов управления проектом. Такой набор согласованных инструментальных
    средств, поддерживающих предлагаемую методологию, и приведен в докладе.

    Предложенная методология обеспечивает снижение сложности процесса создания ИС. Заложенные
    в методологию и поддержанные инструментальными средствами принципы, (разработка на основе
    моделей, проектирование от данных, повторное использование спецификаций и др.) упрощают
    разработку и обеспечивают возможность быстрого внесения изменений как на стадиях создания
    ИС, так и на стадиях сопровождения и развития.

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

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



    Литература


  • Ладыженский Г.М. Системы управления базами данных - коротко о главном. - Jet Infosystems,
    1995.

  • Ладыженский Г.М. Тиражирование данных в СУБД INGRES. - Jet Infosystems, 1994.

  • Polk T.W., Bassham L.E. Security Issues in the Database Language SQL. - NIST Special Publication
    800-8.

  • G. Chung. Informix-DCE/NET Technical White Paper. - Informix Systems Journal, Vol. 1, Number
    3, July-August 1995.

  • Manola F.A. A Personal View on DBMS Security. - in DATABASE SECURITY: Status and
    Prospects. C.E. Landwehr (Editor). Elsevier science Publishers B.V. (North Holland). IFIP, 1988, p. 23-
    34.

  • Castano S., Fugini M., Martella G., Samarati P. Database Security. - Addison-Wesley, 1995.

    []
    []
    []

    Причины появления новых требований

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

    Более того, новые возможности ИТ - вместе с рядом чисто экономических причин - привели к
    увеличению рыночных возможностей и требований потребителей, как следствие - к резкому
    усилению конкуренции в различных отраслях промышленности и услуг. Ответом послужило
    объявление императива бизнес-реинжиниринга: от BPR М. Хаммера ([]) до
    строительства киберкорпораций по Дж. Мартину ([]). В этих подходах требуется
    осуществление радикальных изменений в организации основной деятельности предприятий. В
    частности:


  • резкое снижение затрат времени, числа работников и других затрат на
    выполнение производственных функций;
  • глобализация бизнеса: работа с клиентами и партнерами в любой точке
    мира, а также работа с клиентом в режиме 24*365;
  • опора на рост мобильности персонала, снабжение работника всеми
    возможностями для самостоятельного получения конечного результата;
  • работа на будущие потребности клиента, ускоренное продвижение новых
    технологий.

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

    Также, как саму ИС нельзя рассматривать в отрыве от ее пользователей, и новое проектирование
    должно рассматриваться как интеграция трех составных частей: требований бизнес-
    реинжиниринга, человеческого фактора и методов новых ИТ. Реальное объединение этих трех
    составных частей, каждая из которых приобрела в 90-е годы качественно новое наполнение,
    создало начала того, что можно назвать Новым Системным Проектированием - Н.С.П..

    Применение ERwin существенно повышает эффективность

    Применение ERwin существенно повышает эффективность деятельности разработчиков
    информационных систем. Перечислим кратко основные получаемые преимущества:

  • существенное повышение скорости разработки за счет мощного
    редактора диаграмм, автоматической генерации базы данных, автоматической
    подготовки документации;
  • нет необходимости ручной подготовки SQL-предложений для создания
    базы данных;
  • возможность легко вносить изменения в модель при разработке и
    расширении системы;
  • возможность автоматической подготовки отчетов по базе данных; важно,
    что эти отчеты всегда в точности соответствуют реальной структуре БД;
  • разработчики прикладного программного обеспечения снабжены удобными
    в работе диаграммами;
  • тесная интеграция со средствами 4GL позволяет уже на стадии
    информационного моделирования задавать отображение данных в
    приложениях;
  • обратное проектирование позволяет документировать и вносить изменения
    в существующие информационные системы;
  • поддержка однопользовательских СУБД позволяет использовать для
    персональных систем современные технологии, что значительно упрощает
    переход от настольных систем к системам в технологии клиент-сервер
    (upsizing).


    ADABAS - основа семейства программных

    И.В.Брусенков, В.А.Кондратенков, В.Д.Силин - Software AG

    Администратор Базы Данных (Database Administration)

    Администратор базы данных позволяет разработчикам приложений и администраторам базы
    данных выполнять множество разнообразных задач по поддержке базы данных, таких как:

  • Дампировать и загружать данные и определения.
  • Обмениваться информацией об определениях с другими серверами баз
    данных.
  • Определять защиту приложения и права доступа.
  • Загружать и модифицировать кодовые таблицы для языков, отличных от
    английского.
  • Импортировать и экспортировать данные самых разнообразных
    источников, включая ASCII файлы, электронные таблицы, текстовые
    процессоры, Xbase файлы и графические программы.
    Использование Администратора Базы Данных полезно не только на этапе создания приложения,
    но также и на этапе распространения приложения среди конечных пользователей.


    []
    []
    []

    Администрирование

    Административная подсистема Informix-ViewPoint Pro содержит инструменты, которые позволяют
    в графическом режиме

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

    Альтернативные ключи

    Альтернативный ключ - это атрибут (или группа атрибутов), несовпадающий с первичным ключом и
    уникально идентифицирующий экземпляр сущности. Например, для сущности служащий
    (идентификатор служащего, фамилия. имя, отчество) группа атрибутов "фамилия", "имя", "отчество"
    может являться альтернативным ключом (в предположении, что на предприятии не работают полные
    тезки).

    Для альтернативного ключа, как и для первичного, ERwin автоматически создает индексы при
    генерации БД.


    Анализ средств проектирования информационных систем

    Современные СП могут быть разделены на две большие категории. Первую составляют CASE-
    системы (как независимые (upper CASE), так и интегрированные с СУБД), обеспечивающие
    проектирование БД и приложений в комплексе с интегрированными средствами разработки
    приложений "клиент-сервер" (например, Westmount I-CASE+Uniface,
    Designer/2000+Developer/2000). Их основное достоинство заключается в том, что они позволяют
    разрабатывать всю ИС целиком (функциональные спецификации, логику процессов, интерфейс с
    пользователем и базу данных), оставаясь в одной технологической среде. Инструменты этой
    категории, как правило, обладают существенной сложностью, широкой сферой применения и
    высокой гибкостью.

    Вторую категорию составляют собственно средства проектирования БД, реализующие ту или
    иную методологию, как правило, "сущность-связь" ("entity-relationship") и рассматриваемые в
    комплексе со средствами разработки приложений. К средствам этой категории можно отнести
    такие, как SILVERRUN+JAM, ERwin/ERX+PowerBuilder и др.

    Помимо указанных категорий, СП можно классифицировать по следующим признакам:


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

    В разряд СП попадают как относительно дешевые системы для персональных компьютеров (ПК) с
    весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных
    вычислительных платформ и операционных сред. Так, современный рынок программных средств
    насчитывает около 300 различных CASE-систем, наиболее мощные из которых так или иначе
    используются практически всеми ведущими западными фирмами.

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

    Опыт показывает, что внедрение СП осуществляется медленно, однако по мере приобретения
    практических навыков и общей культуры проектирования эффективность применения этих
    средств резко возрастает, причем наибольшая потребность в использовании СП испытывается на
    начальных этапах разработки, а именно на этапах анализа и спецификации требований. Это
    объясняется тем, что цена ошибок, допущенных на начальных этапах, на несколько порядков
    превышает цену ошибок, выявленных на более поздних этапах разработки.

    На сегодняшний день Российский рынок программного обеспечения располагает следующими
    наиболее развитыми СП:


  • Westmount I-CASE;
  • Uniface;
  • Designer/2000+Developer/2000 (ORACLE);
  • SILVERRUN+JAM;
  • ERwin/ERX+PowerBuilder.

    Приведенный список не претендует на полноту. Кроме того, на рынке постоянно появляются как
    новые (для отечественных пользователей) системы, так и новые версии и модификации
    перечисленных систем (например, CASE/4/0, System Architect и т.д.).

    Некоторое представление о возможностях наиболее развитых СП может дать краткая
    характеристика следующих программных продуктов:

    Библиотеки Sybase поддерживают локализацию POSIX

    Библиотеки Sybase поддерживают локализацию POSIX (IEEE Portable Operating System Interface
    for Computing Environments) и используют информацию о кодовых таблицах, национальном
    языке, форматах чисел, форматах валюты, форматах даты/времени.

    В библиотеках Sybase информация о локализации используется на уровнях контекста
    (приложения), соединения или элемента данных, причем элемент данных может быть колонкой,
    параметром процедуры или параметром сообщения. Локализация по умолчанию наследуется с
    верхнего уровня на нижний.

    Для поддержки локализации библиотеки Sybase:


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

    Архитектура системы SILVERRUN

    SILVERRUN состоит из трех основных подсистем: модуля построения диаграмм потоков данных BPM
    (Business Process Modeler) и двух модулей построения диаграмм "сущность-связь": концептуальных
    моделей - модуль ERX (Entity Relationship eXpert) и реляционных моделей - модуль RDM (Relational Data
    Modeler). Каждый модуль является самостоятельным продуктом и может приобретаться и использоваться
    отдельно. Для интеграции подсистем в единое целое служит менеджер репозитория WRM (Workgroup
    Repository Manager).

    Встроенный в модуль RDM генератор схем баз данных позволяет получить операторы определения
    данных (DDL) для 16 СУБД. Но для полного использования специфики каждой СУБД следует
    использовать отдельно приобретаемые мосты, позволяющие как получить схему базы данных из модели,
    так и построить модель существующей базы данных. SILVERRUN имеет мосты к следующим СУБД:
    DB2, Informix, Ingres, Oracle, Progress, SQL Base, SQL Server, Sybase.

    Для обмена данными с языками разработки приложений также используются соответствующие мосты. В
    настоящее время существуют мосты к следующим средствам разработки приложений: Object Studio,
    Omnis 7, PowerBuilder, Progress, SQL Windows, Synon 2/E, Uniface.

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

    Сама система SILVERRUN функционирует на четырех платформах: Windows, OS/2, Macintosh, Solaris.
    Коллективная разработка в стандартной версии поддерживается разделением и слиянием моделей. В
    версии SILVERRUN Enterprise поддерживается одновременный коллективный доступ к репозиторию.
    Между версиями разных платформ обеспечен обмен данными, что позволяет вести одновременную
    разработку в разнородной среде как в сетевом, так и в одиночном режимах.

    Андрей Юрьевич Тандоев

    (095) 918-1380; 362-5138
    Фирма Sybase - один из ведущих производителей промышленных СУБД, средств разработки
    приложений и других продуктов, реализующих технологию клиент-сервер. Выпуская в конце 1995
    года Sybase System 11, фирма предлагает оптимизированные по производительности средства для
    использования в каждой из трех важных областей работы (рис.1):


  • текущая деятельность организаций (обработка транзакций в режиме online -
    OLTP);
  • анализ и прогнозирование (поддержка принятия решений - DSS);
  • массовое использование на персональных компьютерах, в точках продаж,
    малых филиалах (mass deployment).


    Современные требования к продуктам клиент/серверТекущая длительностьПрогнозирование и анализРасширение бизнеса
    OLTP различные виды операцийDSS хранилища
    данных    		Массовое использование

  • уменьшение стоимости операций
  • интеграция различных подразделений

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

    		•
  • информация, доступная везде и в любое время
  • автоматизация розничной продажи, филиалов и менеджеров по продажам

    • Архивирование модели и модификация структуры данных

    Интересно и очень эффективно реализован механизм модификации структуры данных на основе
    архивной копии модели данных. Архивная копия - сохраненная в специальном формате модель
    данных.

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

    При выполнении модификации структуры таблиц БД S-Designor, во-первых, выбирает
    наиболее эффективную стратегию модификации структуры объектов БД (по возможности наименьшим
    количеством операторов), а, во-вторых, сохраняет данные в таблицах (создает временную
    таблицу, перегружает в нее данные из модифицируемой таблицы, модифицирует таблицу, возвращает
    данные в модифицированную таблицу). Процессом модификации структуры таблиц БД можно
    управлять, поскольку, имеется возможность сгенерировать пакет SQL-предложений, выполняющий
    данную модификацию.

    Примечательно также то, что S-Designor очень "чувствителен" к изменениям модели данных.
    Даже такое, на первый взгляд, незначительное изменение как допустимость значений null для
    отдельной колонки будет "опознано" и структура данных будет автоматически модифицирована. На
    pис.4 приведен пример пакета SQL-предложений, выполняющий
    модификацию структуры таблицы hourly_employee при изменении допустимости значения
    null для колонки hours_per_week(первоначально было null, модифицировано на
    not null).

    Архивирование модели и модификация структуры данных

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

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

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

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

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

    Асинхронная репликация, в отличие от 2РС, не обеспечивает полной синхронности информации на
    всех серверах в любой момент времени. Синхронизация происходит через некоторый, обычно
    небольшой, интервал времени, величина которого определяется быстродействием
    соответствующего канала связи. Для большинства задач кратковременное наличие устаревших
    данных в удаленных узлах вполне допустимо.

    Вместе с тем асинхронная репликация транзакций принципиально обеспечивает целостность
    данных, так как объектом обмена данными здесь является логическая единица работы -
    транзакция, а не просто данные из измененных таблиц.


    Автоматизируется документооборот предприятия

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

    Благодарности

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


    []
    []
    []

    Большие объекты

    DB2/2 и DB2/6000 предоставляют пользователю такие новые типы данных, как большие бинарные
    объекты (BLOBS) и большие текстовые объекты (CLOBS). BLOBS позволяют хранить данные
    любого вида размером до двух гигабайт. CLOBS имеют такие же ограничения на размер, но
    предназначены для хранения текста в виде последовательности однобайтных или двухбайтных
    символов и могут быть связаны с определенной кодовой страницей.

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

    Существенным достоинством реализации больших объектов в DB2 является применимость к ним
    некоторых возможностей SQL. Так, к большим объектам применимы функции для работы со
    строками, они могут использоваться с оператором конкатенации и с предикатом LIKE. Эти
    средства можно использовать не только для работы с текстовыми объектами, но и с двоичными.
    Например функция поиска подстроки может быть полезна как для нахождения заданной фразы в
    тексте, так и для поиска фильма, содержащего нужный кадр.

    Большие возможности при работе с большими объектами предоставляет определение новых типов
    данных и функций. Это делает возможным задать возможность поиска картины по ее элементу,
    или операцию сравнения текстов и т.д. Эти преимущества в полной мере используют реляционные
    расширители DB2, описанные ниже.


    Borland Latte

    В ноябре 1995 года компания Borland объявила о начале работ над новым инструментом для
    разработчиков приложений Internet и БД - Borland Latte. Под общим названием скрывается
    несколько инструментальных средств, облегчающих разработку информационных систем в
    концепции Intranet.


  • AppAccelerator или "Just in-time compiling"

    Итак, в соответствии с новой концепцией, клиентское приложение не хранится на винчестере
    клиентской станции, как это обычно было в классической архитектуре "клиент-сервер". Логика
    приложения хранится в application server (а им может выступать и Web-сервер) в виде множества
    "приложеньиц" - applets, и динамически подгружается по мере необходимости на клиентскую
    станцию. Этот процесс происходит достаточно быстро даже в случае медленного модемного
    соединения - обычный размер applet не превышает нескольких десятков килобайт.

    История движется по спирали... Как это все похоже на концепцию бездисковых рабочих станций в
    файл-серверной архитектуре! Только в данном случае в роли аппаратного загрузчика выступает
    стандартный (или не очень стандартный) интернетовский броузер.

    Компания Borland, предполагая, что большую часть таких станций составят рабочие места под
    Windows 95 и Windows NT, рассчитывает в ближайшее время выпустить продукт под названием
    AppAccelerator, реализующий концепцию "just in-time compiling" - компиляция на ходу. Этот
    инструмент позволяет исполнять Java-приложение не при помощи интерпретатора, а в
    компилированном виде, причем компиляция происходит в момент загрузки applet. Компиляция
    позволяет на порядок ускорить выполнение Java-приложений.


  • IDE

    С выходом в марте новой версии Borland C++ 5.0, в которую входит в качестве дополнения
    поставка интегрированной среды разработки приложений на Java (Borland Latte), разработчики
    смогут ознакомиться с новым для себя инструментом, и оценить в очередной раз качество решений
    Borland.


  • Debugger

    C января 1996 года можно получить с Web-сервера freeware-версию отладчика Java, разработанного в Borland на языке Java.


  • Component Architecture

    Но самое интересное ожидается в конце 1996 года. По моему мнению именно компонентная
    архитектура Delphi привнесла решающий вклад в успех продукта. Компания Borland предполагает
    повторить успех для среды разработки на языке Java - проектирование приложений при помощи
    компонент ожидает в будущем и этот продукт.


  • Server&AppServer execution

    Latte позволит разрабатывать приложения, исполняемые как на клиенте, так и на сервере. Или в
    любом месте многозвенной цепочки N-Tier - системы.


    CASE-система SILVERRUN

    CASE-система SILVERRUN американской фирмы Сomputer Systems Advisers, Inc. (CSA) используется для
    инструментального обеспечения анализа и проектирования информационных систем бизнес-класса. Она
    применима для поддержки любой методологии, основанной на раздельном построении функциональной и
    информационной моделей (диаграмм потоков данных и диаграмм "сущность-связь").

    Настройка на конкретную методологию обеспечивается выбором требуемого графического изображения
    символов моделей и набора правил проверки проектных спецификаций. В системе имеются готовые
    настройки для наиболее распространенных методологий: Gane/Sarson, Yourdon/DeMarco, Merise,
    Ward/Mellor, Information Engineering. Для каждого проектного понятия имеется возможность добавления
    собственных описателей.


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

    Центральная административная консоль SQL Server 6.0 заменила собой набор утилит, которые
    существовали в предыдущей версии сервера. Из этой консоли, называемой Microsoft SQL
    Enterprise Manager, администратор способен выполнять любые действия по администрированию
    системы, как бы велика она ни была. На рис. 2 хорошо видны
    несколько групп серверов.

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

    Что можно ожидать от следующей версии SQL Server

    В настоящее время проходит бета-тестирование SQL Server 6.5 - следующая версия сервера баз
    данных Microsoft. Несмотря на то что обсуждение бета-версий дело неблагодарное, давайте
    посмотрим на некоторые основные нововведения, которые планируется включить в продукт,
    запланированный к выходу во втором квартале текущего года.

    Следуя линии поддержки работы с большими объемами данных в SQL Server 6.5 планируется
    включить поддержку "хранилищ данных".

    Будут добавлены следующие возможности: аналитическая обработка данных в реальном времени
    (online analytical processing - OLAP) при запросах, тиражирование в базы данных, производимые
    другими компаниями, и поддержка программируемых устойчивых представлений и операций по
    группировке данных на нескольких серверах.


    Цикл разработки в S-Designor

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

    Концепция S-Designor - реализация классической теории информационного моделирования,
    включающей четкое разделение между концептуальной моделью данных (представление объектов
    реального мира и их взаимосвязи) и физической (отображение этих объектов в терминах, близких к
    физическому представлению). Например, связи многие ко многим. Согласно теории информационного
    моделирования и проектирования баз данных, такая связь при реализации должна быть
    детализирована добавлением третьей уточняющей таблицы. S-Designor позволяет
    представлять такие связи на концептуальном уровне модели. При генерации физической модели
    S-Designor автоматически добавляет промежуточную таблицу, таким образом детализируя эту связь.

    Цикл разработки в S-Designor

    Cобственная репликация данных SQL Remote

    SQL Remote - это система репликации (тиражирования данных) между базами данных SQL
    Anywhere, основанная на передаче сообщений. Эта система администрируется из единого центра и
    наиболее подходит для обмена данными с laptop-компьютерами и другими пользователями, связь с
    которыми есть от случая к случаю. Система SQL Remote может использовать для репликации
    средства электронной почты (MAPI, VIM, SMTP), файловый обмен и готовящийся к выходу
    механизм Sybase Messaging Services.

    SQL Remote реплицирует данные между "консолидированной" БД и одной или несколькими
    "удаленными" БД. В качестве удаленных могут выступать как сетевые серверы SQL Anywhere, так
    и локальные однопользовательские БД. SQL Anywhere поддерживает иерархическую модель
    репликации (рис.12).

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

    Изменения, проведенные в консолидированной БД, тиражируются в удаленные БД. Изменения,
    проведенные в одной из удаленных БД, попадают в консолидированную БД и затем в другие
    удаленные БД.

    Для обмена данными SQL Remote использует сообщения. Поэтому необязательно иметь прямое
    сетевое соединение с удаленными БД. Достаточно организовать обмен сообщениями, например, по
    электронной почте.

    Приложения в архитектуре клиент-сервер, работающие в режиме сессии, используют тот или иной
    сетевой транспорт (TCP/IP, IPX/SPX и др.) Точно так же приложения, работающие с сообщениями,
    используют службы сообщений, такие как Microsoft Messaging API (MAPI), Lotus Vendor
    Independent Messaging (VIM), Internet Simple Mail Transfer Protocol (SMTP) или даже простой
    обмен файлами.


    Схема репликации в SQL Anywhere
    Cобственная репликация данных SQL Remote
    репликации">


    Детальная система моделей организации.

    Главными целями создания детальной системы моделей является построение концептуальной
    модели данных и функциональной модели организации. Для достижения этих целей проводится
    детализация описания деятельности организации от уровня описания реализации общих бизнес-
    процессов в организации и списковых моделей в подразделениях до уровня детальных моделей
    подразделений, позволяющих выделить все функции подразделений, обрабатываемые
    документы, основные данные, описать регламент работы персонала и создать в итоге
    функциональную модель организации и концептуальную модель данных.

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

    Описание деятельности организации с помощью бизнес-процессов и бизнес-правил позволяет
    определить где, когда и кем выполняется каждая функция, какие данные, информационные и
    функциональные взаимосвязи для этого нужны, и откуда эти данные поступают.

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


    Документация

    В состав JAM входит полный комплект документации в электронном виде. При этом используется
    гипертекстовая система Dyna Text фирмы Electronic Book Technologies. Dyna Text доступна на
    многих платформах, поддерживаемых пакетом JAM. Печатный вариант документации
    поставляется за дополнительную плату. Если на какой-либо платформе Dyna Text система
    недоступна, то печатная документация поставляется бесплатно. Вся документация представлена на
    английском языке.


    Домены

    Часто используемые комбинации свойств можно поименовать. Такая комбинация свойств,
    называемая доменом, может наследоваться. Например, можно определить домен "Дата" для
    отображения всех колонок с датами в приложении в одном стиле, домен "Дата рождения ребенка"
    наследует все атрибуты от домена "Дата" и вносит дополнительный атрибут - цвет отображения.

    Пример определения домена показан на рис.11.

    Домены

    Достоинства реляционного и объектного подхода к построению информационных систем

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

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

    Для решения таких задач эффективны объектно-ориентированные информационные системы
    (ООИС), в которых сущности реального мира представляются как объекты данных href="#lit">[2]    . Состояние объектов описывается как значения их атрибутов, а их поведение
    (применимые к ним операции) определяется реализацией их методов. Это позволяет представлять
    объекты предметной области в естественном для них и семантически значимом виде, что
    существенно упрощает разработку и модификацию схемы данных. Реляционная модель данных
    может рассматриваться как подмножество объектно-ориентированной, что накладывает серьезные
    ограничения на использование реляционных СУБД при построении ООИС. Однако это именно то
    подмножество, которое на протяжении последних лет используется в большинстве работающих
    реляционных систем, что привело к детальной разработке этой модели. В результате современные
    РСУБД отличает совершенство реализаций, обеспечивающее высокую надежность и
    производительность, в отличие от объектно-ориентированных баз данных, находящихся сегодня
    на ранней стадии своего развития. Более того, существуют задачи , для
    которых объектный подход не дает преимуществ.


    Доступ к распределенной базе данных (интеграция/репликация данных)

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

    SOFTWARE AG включила XA-интерфейс (спецификация X/Open XO/CAE/91/300) в продукт
    ADABAS версии 2.2 для ряда платформ UNIX и операционных систем IBM mainframe.

    Продукт ENTIRE TRANSACTION PROPAGATOR поддерживает репликацию данных,
    предоставляя возможность распространения транзакций изменений в среде баз данных
    ADABAS.

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

    Доступ к удаленной базе данных (серверы баз данных)

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

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

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

    Установка этого продукта на каждом из узлов сети как на платформах серверных ЭВМ, так и
    рабочих станций клиентов, обеспечивает доставку запросов и данных между серверами баз данных
    ADABAS и их клиентами.

    На следующих схемах изображены варианты доступа к базам данных ADABAS, расположенных на
    различных серверных платформах из приложений-клиентов на рабочих станциях.

    Изображенные на рис. 5 конфигурации являются стандартными для
    доступа к серверам баз данных ADABAS со стороны клиентов на рабочих станциях под
    Windows.


    Платформа клиентов (MS Windows)
    Доступ к удаленной базе данных (серверы баз данных)


    Embedded SQL

    Sybase Embedded SQL прекомпилятор позволяет программисту использовать ANSI-операторы
    SQL в тексте программы на Си и Коболе. Для оптимизации статических запросов SQL
    прекомпилятор может генерировать хранимые процедуры. Прекомпилятор интегрирован с XA-
    интерфейсом для работы с мониторами транзакций.


    Фирма-производитель

    Американская фирма Computer Systems Advisers, Inc. (CSA) является поставщиком средств
    проектирования и создания информационных систем архитектуры "клиент-сервер", а также занимается
    консалтингом в области информационных технологий. Продукты фирмы используются в более 5000 мест
    по всему миру. Среди пользователей - известнейшие представители компьютерного бизнеса (Apple, Cray,
    Data General, IBM, Intel, Lotus Development, Texas Instruments), финансовой сферы (American Express,
    Citibank, Morgan Guarantee Trust, World Bank), производители массовых товаров и услуг (General
    Electric, Pepsicola, Pizza Hut, Polaroid), университеты (Harvard, Stanford, Yale), кинокомпании (MCI,
    Walt Disney).


    Фрагментация приложений

    Поставляемая с Informix-NewEra библиотека классов прикладного сервера (Application Server Class
    Library) предназначена для создания распределенных многозвенных приложений. В таком
    приложении на машине-клиенте обслуживается только интерфейс с пользователем, а прикладная
    бизнес-логика реализуется при помощи одной или нескольких серверных компонентов.
    Предполагается, что поддержка серверных компонентов приложений NewEra будет обеспечена для
    всех платформ, на которых могут работать серверы СУБД Informix.

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


    Функции, определяемые пользователем

    Функции, определяемые пользователем, позволяют скрывать внутреннее представление данных от
    приложения, обеспечивая некоторую инкапсуляцию данных. Они также позволяют определять
    новые операции как для базовых типов данных, так и для типов, определяемых пользователем.

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

    Для реализации этих функций используются языки программирования, а для их регистрации в
    СУБД - введенный в язык определения данных оператор CREATE FUNCTION. Фактически этот
    оператор связывает пользовательскую функцию с конкретной программой, выполняемой при
    вызове этой функции. Использование пользовательских функций вместо непосредственного
    доступа к данным может обеспечить некоторую инкапсуляцию данных, что можно использовать
    для того, чтобы скрыть от пользователя их внутреннюю структуру.

    Кроме того, DB2 поддерживает механизм перегрузки имен пользовательских функций,
    аналогичный применяемому в ООБД, однако не позволяет связывать функции с конкретными
    элементами данных, как связаны методы и объекты при объектном подходе.

    Дополнительную гибкость функциям, определяемым пользователем, придает способность
    одновременно работать как с данными DB2, так и другими данными, как, например, файлами,
    электронной почтой и др.

    Возможны два варианта взаимодействия функций, определяемых пользователем, с сервером DB2.

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

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

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


    Генерация кода - эксперты

    В процессе развития и, в том числе, визуализации средств разработки приложений, на фоне
    стандартизации пользовательского интерфейса в различных областях применения конечных
    систем, неотъемлемой частью таких инструментов стали генераторы кода и форм представления и
    ввода информации - эксперты.

    Кроме того, что Delphi включает ряд уже готовых к использованию экспертов (например, DataBase
    Form Expert, генерирующий формы и соответствующий код для простых приложений обработки
    баз данных с использованием запросов), эта среда программирования предоставляет
    разработчикам интерфейс для создания собственных экспертов, встраиваемых в IDE.

    Необходимо отметить, что функциональность таких экспертов может не ограничиваться на
    генерации кода, в силу того, что интерфейс экспертов дает возможность получения информации о
    внутренних объектах IDE, таких как палитра компонент. Вследствие этого, под общим названием
    "эксперты" могут фигурировать программные модули, позволяющие управлять повелением IDE,
    окна дизайнера и ее редактора исходных текстов, а также генерировать отчетную информацию о
    создаваемом проекте. (На приведенном выше рисунке вы можете увидеть эксперт, разработанный
    в Delphi и встроенный в IDE; функциональность этого эксперта заключается в предоставлении
    разработчику информации об иерархии наследования зарегистрированных компонент без
    компиляции; в данном случае доступ осуществляется через меню "Help", хотя возможна
    регистрация и в "галерее" шаблонов Delphi).

    Генерация кода - эксперты

    Генерация отчетов

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

    Генерация отчетов

    Генерация приложений и схем баз данных

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

    SILVERRUN не подменяет среду разработки и не содержит средств моделирования видов экранов или
    форматов отчетов. Эти функции специфичны для каждого языка разработки. SILVERRUN передает
    данные о форматах ввода, правилах редактирования, формах представления прямо в репозиторий среды
    разработки. Программисту остается расставить поля на экранах, подправить, если нужно, генерируемые
    большинством языков четвертого поколения автоматически SQL-запросы для этих экранов, определить
    систему меню - и основа работающего приложения создана.

    Генерация схемы базы данных происходит путем создания файла с SQL-операторами, в которые
    переводятся конструкции модели данных. Этот файл используется для физического создания базы данных
    на сервере. На рис. 6 приведен фрагмент схемы для СУБД Informix OnLine, полученной из модели,
    изображенной на рис. 4.

    --
    ================================================
    ===
    -- table: Order
    --
    ================================================
    ===
    create table Order
    (
    OrderNum INTEGER not null,
    OrderDate DATE default TODAY not null,
    OrderCost MONEY not null,
    CustomerName CHAR not null,
    primary key (OrderNum)
    )
    ;
    --
    ================================================
    ===
    -- referential integrity triggers section
    --
    ================================================
    ===
    -- =======================================
    -- Procedure raise_exception for errors messages
    -- =======================================
    create procedure
    messages_errors(errno INTEGER, isam INTEGER, errmsg char(255))
    raise exception errno, isam, errmsg;
    end procedure;
    --
    ================================================
    ===
    -- Controls the INSERT action on table Order.
    -- Rule : CHILD INSERT RESTRICT
    -- Parent : Customer
    -- Child : Order
    -- Direction : Order_Customer
    --
    ================================================

    ===
    create trigger tr_ins_Order insert on Order
    referencing NEW as inserted
    for each row
    when
    (
    (select count(*) from Customer
    where
    inserted.CustomerName = Customer.CustomerName
    ) = 0
    )
    (
    execute procedure messages_errors
    (
    -746,
    0,
    'Insert of "Order" denied: corresponding "Customer" does not
    exist.'
    )
    )
    ;
    --
    ================================================
    ===
    -- Controls the DELETE action on table Customer.
    -- Rule : PARENT DELETE RESTRICT
    -- Parent : Customer
    -- Child : Order
    -- Direction : Customer_Order
    --
    ================================================
    ===
    create trigger tr_del_Customer delete on Customer
    referencing OLD as deleted
    for each row
    when
    (
    exists
    (
    select * from Order
    where
    Order.CustomerName = deleted.CustomerName
    )
    )
    (
    execute procedure messages_errors
    (
    -746,
    0,
    'Delete of "Customer" denied: referencing "Order" exists.'
    )
    )
    ;
    Рис. 6. Фрагмент схемы базы данных для СУБД Informix
    OnLine

    Генерация приложений

    Современная версия S-Designor позволяет автоматически генерировать приложения.
    Приложения генерируются в интерфейсе MDI (многодокументный интерфейс). Обеспечивается
    возможностью генерации связанных окон данных (master-detail). Приложения генерируются на основе
    template, который поставляется с S-Designor. Окна данных в приложении генерируются
    согласно выбранным таблицам модели данных. Для генерации приложения достаточно указать только
    ряд необходимых параметров, таких как имя библиотеки в которой будет сохранено приложение,
    источник данных в терминах ODBC, с которым будет работать приложение, имя библиотеки,
    содержащей template, а также некоторые другие параметры.

    Имеется возможность автоматически генерировать запросы (Query) как объекты в терминах целевых
    средств разработки на основе представлений (View).


    Генератор окон - Window Painter

    Генератор окон NewEra - инструмент, который позволяет в графическом режиме создавать новые
    классы окон и визуальных объектов. Под визуальным объектом понимается группа
    взаимосвязанных органов управления окна, например, группа радиокнопок или супертаблица
    (орган управления для взаимодействия с таблицами БД) в комплекте с управляющими
    кнопками.


    Генератор отчетов - JAM/RW

    Одним из дополнительных модулей JAM является Генератор Отчетов. Компоновка отчета
    осуществляется в Редакторе Экранов JAM. Описание работы отчета осуществляется с помощью
    специального языка.

    Генератор отчетов позволяет определить:

  • Данные, выводимые в отчет. Источниками информации для отчетов
    могут быть результаты исполнения SQL-запросов (в том числе и
    сгенерированные Менеджером Транзакций), внешние источники, информация,
    введенная конечным пользователем и т.д;
  • Группировку выводимой информации. Уровни вложенности подотчетов и
    детализации не ограничены;
  • Динамическое управление исполнением отчета;
  • Форматирование вывода, включая интеллектуальное разбиение на
    страницы;
  • Заголовки и подвалы страниц и групп; использование в них внешних
    данных;
  • Дополнительную обработку с помощью JPL-процедур или внешних
    функций, написанных на языках 3-го поколения;
  • Динамическое управление исполнением отчета;
  • Устройство вывода.

    Генератор Отчетов (Report Builder)

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

  • отчеты в табличном виде
  • рулонные отчеты
  • отчеты, состоящие из нескольких разделов
  • только итоговые (суммарные) отчеты
    Генератор Отчетов позволяет просмотреть на экране дисплея вид будущего отчета и при
    необходимости внести требуемые коррективы. Текст отчета может содержать такие атрибуты
    текста, как курсив, подчеркивание, плотность печати, а также выравнивание текста, цвет и тип
    шрифта.

    Кроме построения самостоятельных отчетов, Генератор может быть использован для генерации
    отчетов для конечного пользователя следующим образом. Вы создаете основную логику отчета по
    отбору данных и разметку страниц. Затем вы передаете конечному пользователю этот отчет вместе
    с Генератором Отчетов Report Builder или утилитой Results, при помощи которых он может в
    соответствии с собственными нуждами изменить формат отчета и отбираемые данные. Подобные
    возможности по созданию шаблонов в значительной степени увеличивают возможности
    пользователей, а также освобождают разработчиков от необходимости затрачивать чрезмерные
    усилия на создание новых отчетов.


    Генератор приложений

    Генератор приложений (Application Builder) - графический инструмент для построения
    приложений, состоящих из нескольких файлов. Разработчик описывает структуру приложений в
    терминах проектов, программ, файлов. Проект может состоять из одной или нескольких
    программ, каждая программа собирается из одного или нескольких исходных файлов (рис. 3).
    Описания проектов сохраняются в системной базе данных.

    Генератор позволяет собирать как интерпретируемый, так и выполняемый вариант приложения.
    Выполняемое приложение создается в виде EXE-файла и, возможно, нескольких динамически
    загружаемых библиотек (DLL).

    Генератор приложений

    Генераторы приложений

    Входящие в состав DESIGNER/2000 генераторы разбиваются на две группы:


  • генератор сервера
  • генераторы клиентской части

    Генератор серверной части автоматически строит по спецификациям базы данных тексты
    программ на языке SQL, используя все средства определения баз данных, включая триггеры,
    хранимые процедуры и т.д.

    Генераторы клиентской части обеспечивают автоматическое формирование текстов программных
    модулей по их спецификациям, записанным в репозитарии. Все модули приложения
    классифицируются по типам, основными из которых являются экранные формы, отчеты,
    процедуры. Для каждого типа имеется свой генератор, результатом работы которого является
    программа, написанная на языке, соответствующем этому типу: генератор форм создает
    приложения для ORACLE/Forms, генератор отчетов позволяет получать процедуры на PL/SQL
    либо приложения для ORACLE/Report.

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

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

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

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

    Например, если мы хотим создать экранную форму для таблицы СОТРУДНИКИ, то нет
    необходимости включать в число используемых таблиц ОТДЕЛЫ в качестве источника для
    заполнения столбца ОТДЕЛ в таблице СОТРУДНИКИ. Генератор, анализируя структуру базы
    данных, автоматически создаст правильный список возможных значений и включит в текст
    программы все необходимые проверки на правильность вводимых данных. Такой принцип
    работы генераторов особенно существенен для поддержки прикладной системы: при
    необходимости изменения схемы базы данных (добавилась новая таблица, логически связанная с
    уже существующими, или изменился тип некоторой взаимосвязи между базовыми таблицами и
    т.п.) можно не вносить никаких изменений в старые спецификации модулей, а лишь
    перегенерировать их и все необходимые изменения в тексты программ будут внесены
    автоматически.

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

    При необходимости сгенерированный текст программы можно дополнительно доработать и
    дополнить, пользуясь непосредственно соответствующими инструментальными средствами
    разработки "нижнего уровня", входящими в состав DEVELOPER/2000.


    В этом случае появляется
    некоторая опасность несоответствия конечной версии программы спецификациям проекта, что
    особенно неудобно при возможных изменениях проекта, например схемы базы данных. Такое
    изменение требует перегенерации модулей с учетом новых таблиц и взаимосвязей, а с другой
    стороны выполнение повторной генерации "уничтожит" старую версию программы со всеми
    введенными "вручную" дополнительными фрагментами. Для такой ситуации в DESIGNER/2000
    предусмотрен специальный режим работы генераторов - регенерация. При регенерации
    происходит не замена старого программного текста на новый, а его "редактирование", когда по
    возможности вносятся лишь необходимые изменения и не корректируются отдельные
    фрагменты. При этом можно управлять уровнем изменений и запретить модифицировать
    определенные фрагменты программы (например, все, относящееся к описанию расположения
    полей или триггеры заданного типа и т.п.).

    Из дополнительных средств, входящих в состав генераторов, особый интерес представляют
    утилиты, позволяющие использовать DESIGNER/2000 не только для новых разработок,
    начинающихся с этапа постановки задачи, но и для готовых прикладных систем, которые были
    спроектированы и реализованы без использования CASE-средств. Для такой ситуации
    предусмотрена возможность реинженигинга системы - автоматического создания по работающей
    версии приложения его описания в репозитарии, т.е. спецификаций структуры базы данных,
    программных модулей типа экранных форм и отчетов, ER-модели. Полученные описания могут
    быть использованы для анализа возможностей и выявления недостатков существующей версии
    приложения, а впоследствии модифицированы в соответствии с новыми требованиями и
    условиями функционирования системы. На основе отредактированных спецификаций
    производится генерация новой версии системы.



    Графические средства конфигурирования и администрирования

    Конфигурирование и управление процессом тиражирования данных на уровне предприятия
    обычно представляет собой сложную и требующую больших затрат времени задачу. В SQL Server
    6.0 эта задача выполняется с помощью развитых графических инструментов административного
    управления и, таким образом, резко упрощается. Администраторы могут определить все аспекты
    процесса создания тиражируемых данных, диспетчирования процессов, установки подписки и
    полностью контролировать защищенность тиражируемых данных. Для каждой публикации можно
    определить записи или столбцы, входящие в публикацию, и то, какие подписчики имеют право
    обращения к каким публикациям. В каждой публикации администратор имеет полный контроль
    над доступом к ее данным.


    Графическое редактирование модели

    Все объекты модели ERwin могут редактироваться средствами, принятыми в Windows - группировка,
    копирование, удаление, перемещение, использование системного буфера. Установка цветов и
    шрифтов осуществляется в удобных диалогах.

    Компоненты модели, представленные текстом (имена сущностей, атрибутов, текстовые элементы)
    могут редактироваться непосредственно на экране.


    Характеристика языка программирования NewEra

    В отличие от языков скриптов, предлагаемых многими инструментальными системами, NewEra
    представляет собой полномасштабный высокоуровневый объектно-ориентированный язык,
    содержащий ряд встроенных средств для программирования доступа к базам данных и
    графического пользовательского интерфейса. NewEra является развитием языка Informix-4gl,
    поддерживая все его возможности за исключением операторов и встроенных функций для работы с
    экранными формами и меню.


    Характеристики проекта


    при традиционном подходе:

    Сложность проекта ~ 1850 ф.т.

    Типичная норма выработки - 18 ф.т. на человеко-месяц

    Проект потребует - 103 человеко-месяца

    5 человек - более 20 месяцев

    при спиральной модели жизненного цикла:

    Сложность проекта ~ 1850 ф.т.

    Проект потребовал - 38 человеко-месяцев

    Норма выработки - 48,5 ф.т. на человеко-месяц

    Высокая производительность проекта достигалась за счет использования средств автоматизации анализа и проектирования (CASE SilverRun), языка четвертого поколения (JAM), за счет автоматизации всей технологической цепочки (мост SR-(JAM), использования средств конфигурационного управления (PVCS), средства автоматизации тестирования QualityWorks.

    Характеристики проекта

    []
    []
    []

    Хранение информации в модели ERwin

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


    Хранимые процедуры

    Хранимые процедуры (stored procedures) представляют собой приложения, которые хранятся в базе
    данных. Обычно, в среде клиент-сервер конечные приложения располагаются на клиентской
    машине и там же выполняются. Любой доступ к базе данных из конечного приложения использует
    контакт с сервером по компьютерной сети. Когда же приложение располагается внутри базы
    данных, оно называется хранимой процедурой. Хранимые процедуры выполняются
    непосредственно на компьютере сервера базы данных.

    SQLBase использует хранимые процедуры, написанные на языке инструмента разработки
    конечных приложений SQLWindows Application Language (SAL).

    Использование хранимых процедур преследует следующие цели:


  • Повышение производительности - Так как прикладная программа
    перенесена на сервер, она не требует затрат на передачу информации по сети
    при обращении к базе данных. Кроме того, сервер обычно бывает более
    мощным компьютером, чем клиентские машины. Следовательно, те же
    операции выполняются на сервере быстрее.
  • Простота использования - Обычно, технология клиент-сервер
    подразумевает большое количество клиентов, подключенным к одному
    серверу. Использование хранимых процедур позволяет хранить приложение на
    одном компьютере, а не на каждом клиенте в отдельности. Если приложение в
    базе данных модифицируется, оно становится сразу доступно всем клиентам в
    наиболее обновленном виде.
  • Усиление защиты данных - Пользователь может получить возможность
    доступа к данным только через использование заранее запрограммированных
    процедур и не иметь прямой возможности изменять данные. Следовательно,
    набор операций, которые могут быть осуществлены пользователем, легко
    контролируются с помощью управления доступом к небольшому числу
    хранимых процедур.
  • Ускорение процесса освоения - Хранимые процедуры SQLBase пишутся на
    языке SAL. Этот язык хорошо знаком разработчикам приложений на продуктах
    Gupta. Кроме того, разработчики могут создавать и отлаживать прототипы
    хранимых процедур в среде SQLWindows и затем переносить их в базу данных

    с помощью программы SQLConsole.

    В SQLBase имеется возможность хранения двух типов процедур.


  • Хранимые команды - это SQL запрос, который хранится на сервере в
    скомпилированном виде (то есть вместе со своим планом выполнения).
    Выполнение хранимых команд производиться гораздо быстрее, чем обычных
    SQL запросов, поскольку целый ряд шагов, необходимых для выполнения
    запроса, производится в момент записи хранимой команды в базу данных. В то
    же время хранимые команды имеют ограниченную функциональность в рамках
    синтаксиса языка SQL.
  • Хранимые процедуры - это приложения, объединяющие SQL запросы и
    процедурную логику (операторы присваивания, логического ветвления и т.д.).
    Хранимые процедуры позволяют хранить на сервере сложные приложения,
    выполняющие большой объем работы без передачи данных по сети и
    взаимодействия с клиентом.

    Создание хранимых процедур

    Хранимые процедуры и хранимые команды SQLBase создаются с помощью команды STORE языка SQL или при помощи функции sqlsto() SQL/API.

    Тело хранимой процедуры состоит из следующих элементов или разделов:


  • Имя процедуры. Является идентификатором процедуры и
    используется при извлечении (retrieve) процедуры из базы данных перед ее
    выполнением.
  • Переменные. SQLBase поддерживает 5 типов данных в качестве
    переменных хранимых процедур. Все они идентичны типам данных
    SQLWindows с теми же именами.
    а
  • Number - Числовой тип данных
    а
  • Boolean - Логический тип данных с допустимыми значениями
    TRUE/FALSE
    а
  • String - Строковый тип данных
    а
  • Date/Time - Этот тип может быть использован для данных типа
    Дата, Время или Дата/Время
    а
  • Sql Handle - используется в качестве курсоров для доступа к
    базе данных

    Секция описания переменных хранимой процедуры состоит из двух блоков: блока параметров
    (Parameters) и блока локальных переменных (Local Variables).

    Блок параметров содержит переменные, которые передают информацию в хранимую процедуру
    или возвращают информацию из нее в вызывающее процедуру приложение. Блок параметров
    эквивалентен списку bind-переменных в SQL запросе.


    Хранимые процедуры SQLBase могут
    содержать параметры двух типов: для ввода и для вывода. Параметры вывода обозначаются
    ключевым словом RECEIVE перед описанием типа переменной. Эти параметры эквивалентны
    списку into-переменных в запросах SELECT.

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


  • Процедурная логика. Этот раздел начинается с ключевого слова
    ACTIONS. Он содержит всю логику и выполняемые инструкции процедуры.
    Весь код этого раздела пишется на языке SAL. Хранимые процедуры SQLBase
    поддерживают некоторое подмножество полного языка SAL. Например, в
    текущей версии SQLBase реализована поддержка только тех функций SAL,
    которые начинаются с префикса Sql ( SqlPrepare()). Поддержка
    остальных функций (начинающихся с префикса Sal) будет реализована в
    последующих версиях продукта.

    Раздел процедурной логики может также состоять из следующих необязательных секций:

    ON PROCEDURE STARTUP - Эта секция используется для процедур инициализации,
    таких как установление контакта с базой данных, компиляция запросов и т.д. Она выполняется
    только во время первого выполнения хранимой процедуры.

    ON PROCEDURE EXECUTE - Данная секция выполняется всякий раз, когда хранимая
    процедура выполняется командой EXECUTE. Во время первого выполнения эта секция
    выполняется после секции ON PROCEDURE STARTUP. Во время всех последующих команд
    EXECUTE выполняется только эта секция.

    ON PROCEDURE FETCH - Эта секция выполняется всякий раз, когда процедуре
    передается команда FETCH в случае использования процедуры в качестве result set (не забудьте,
    что хранимые процедуры ведут себя подобно запросам SELECT). При этом строки из множества
    результатов возвращаются из процедуры посредством переменных типа RECEIVE.

    ON PROCEDURE CLOSE - Данная секция выполняется в тот момент, когда для курсора,
    связанного с хранимой процедурой, происходит компиляция нового запроса или этот курсор
    отсоединяется от базы данных.


    Она используется для выполнения операций завершения, таких как
    выпуск транзакции COMMIT, отсоединение от базы данных и т.д.

    Если процедура не содержит описанных выше секций, по умолчанию предполагается, что она
    состоит из одной секции ON PROCEDURE EXECUTE.

    Хранимая процедура может быть определена как статическая или динамическая с помощью
    ключевых слов STATIC/DYNAMIC после имени процедуры. По умолчанию, хранимые процедуры
    SQLBase являются динамическими. Если процедура определяется как статическая, все SQL запросы
    в ней должны быть предварительно скомпилированы и записаны в базу данных в виде хранимых
    команд. Поэтому в статических процедурах все SQL запросы должны быть представлены в виде
    строковых констант и не могут содержать переменных. Кроме того, в статических процедурах не
    допускается использование команд типа CREATE, ALTER, DROP. Статические процедуры
    обладают гораздо более высокой производительностью по сравнению с динамическими, поскольку
    не требуют компиляции своих запросов во время выполнения.

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

    Для того, чтобы выполнить хранимую процедуру, пользователь должен обладать определенными
    привилегиями. Он может иметь право выполнить процедуру либо с привилегиями автора (execute
    with creator privilege), либо со своими привилегиями (execute with grantee privilege). Если
    пользователь выполняет процедуру с правами автора, он получает все его права по отношению к
    объектам базы данных на время выполнения процедуры. При втором способе выполнения
    изменения прав пользователя не происходит. Использование возможности расширения (изменения)
    прав пользователя на время выполнения хранимой процедуры позволяет повысить защищенность
    данных и канализировать доступ к ним через отработанные и проверенные процедуры.

    Получение кодов ошибок из хранимых процедур

    Процедура указывает на нормальное завершение возвращая нулевое значение в вызвавшее ее
    приложение.

    Если процедура возвращает ненулевое значение, оно рассматривается как ошибка.


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

    Пример хранимой процедуры

    Ниже приведен пример хранимой процедуры SQLBase, иллюстрирующей некоторые моменты,
    описанные в данной статье. Эта процедура обновляет баланс по счету AccountNum в соответствии
    с выплаченной суммой nAmount и возвращает новое значение баланса в переменной nNewBalance.
    Если при этой операции происходит овердрафт, процедура устанавливает флаг bOverDrawn.

    (Примечание: при написании хранимых процедур, также как и в коде на языке SQL, индентация
    различных блоков кода имеет критическое значение. В программу SQLConsole входит редактор
    хранимых процедур, который поддерживает нужные уровни индентации.)

    Procedure Withdraw
    Parameters
    Number: nAccount
    Number: nAmount
    Receive Number: nNewBalance
    Receive Boolean: nOverDrawn
    Local Variables
    Sql Handle: hSelect
    Sql Handle: hUpdate
    String: sSelect
    String: sUpdate
    Number: nStatus
    Actions
    On Procedure Startup
    Set sSelect = 'Select Balance from Checking where
    AccountNum=:nAccount' \
    'into :nNewBalance'
    Set sUpdate = 'Update Checking Set Balance = Balance -
    :nAmount' \
    'where AccountNum = :nAccount'
    Call SqlConnect( hSelect )
    Call SqlPrepare( hSelect, sSelect )
    Call SqlConnect( hUpdate )
    Call SqlPrepare( hUpdate, sUpdate )
    On Procedure Execute
    Call SqlExecute( hSelect )
    Call SqlFetchNext (hSelect, nStatus )
    Set nNewBalance = nNewBalance - nAmount
    If ( nNewBalance < 0 )
    Set bOverDrawn = TRUE
    Else
    Set bOverDrawn = FALSE
    Call SqlExecute( hSelect )
    On Procedure Close
    Call SqlDisconnect( hSelect )
    Call SqlDisconnect( hUpdate )

    Художник баз данных (DataBase Painter)

    Художник баз данных предоставляет интерактивные средства для создания и поддержки баз
    данных SQL. Разработчики могут создавать таблицы и представления, определять первичные и
    внешние ключи, запускать командные файлы баз данных, обеспечивать безопасность и
    редактировать данные из базы данных.

    Центральный репозиторий дизайна приложений (Central Application Design Repository) предоставляет
    развитые возможности управления хранением расширенных атрибутов столбцов, таких как
    заголовки, метки, форматы изображения, правила проверки и графические стили
    редактирования.


    Художник библиотек (Library Painter)

    Художник библиотек позволяет разработчикам совместно использовать все объекты
    приложений, такие как окна, Окна данных, меню, структуры и Объекты пользователей
    (User Objects). Эти объекты хранятся в одной или нескольких библиотеках, локализованных в одном
    месте или распределенных в сети. Возможность проверки при выдаче и возврате объектов (check-
    in/check-out) позволяет предотвратить одновременное обновление одного объекта несколькими
    разработчиками. Предоставляются также возможности поиска в библиотеках, анализа взаимосвязи и
    создания подробных отчетов для разработчиков по библиотекам и их компонентам.

    Художник библиотек предлагает также прозрачный доступ ко множеству систем контроля
    версий и систем управления конфигурацией, разработанных третьими фирмами. Разработчики,
    создающие крупные приложения, могут поддерживать несколько версий объектов и отслеживать, кто
    и когда внес данное изменение.


    Художник функций (Function Painter)

    Художник функций позволяет разработчику создавать и поддерживать функции, которые
    чаще всего представляют собой общие процедуры, неоднократно используемые в одном или
    нескольких приложениях, сокращая при этом объем повторяющегося кода.


    Художник меню (Menu Painter)

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


    Художник настроек (Preferences Painter)

    Художник настроек позволяет настраивать конфигурацию PowerBuilder в соответствии с
    привычками и вкусом разработчика.


    Художник Объектов пользователей (User Object Painter)

    Художник Объектов пользователей создает объекты, определенные пользователями, из
    стандартных элементов управления Windows, предварительно определенных объектов пользователей
    и элементов управления VBX. Художник Объектов пользователей может также создавать
    невидимые объекты пользователя, обеспечивая полное использование объектно-ориентированной
    техники разработки. Используя построитель классов C++ (C++ Class Builder), основанный на
    технологии Watcom, объекты пользователя можно реализовывать на языке C++.


    Художник Окна данных (DataWindow Painter)

    Художник Окна данных создает интеллектуальный объект данных для просмотра,
    манипулирования и обновления реляционных баз данных без необходимости программирования на
    SQL. Художник Окна данных содержит множество параметров, предоставляемых в режиме
    "укажи и щелкни кнопкой мыши", которые позволяют изменять оформление внешнего вида Окна
    данных. Не прибегая к программированию, разработчики могут создавать деловую графику,
    вычисляемые столбцы, автоматические сводки, а также осуществлять межтабличный анализ. Окна
    данных могут быть динамическими и поддерживать изменения во время выполнения приложения
    в виде незапланированных запросов и отчетов, чтобы удовлетворить самым специфическим
    требованиям конечных пользователей.


    Художник окон (Window Painter)

    Художник окон создает окна (являющиеся основным элементом интерфейса приложений) и
    элементы управления, которые могут быть частью окна. Элементами управления являются командные
    кнопки, линейки прокрутки, списки выбора, открывающиеся списки выбора, радиокнопки,
    альтернативы, элементы управления Окна данных (DataWindow) и многое другое.


    Художник переноса данных (Data Pipeline Painter)

    Художник переноса данных обеспечивает разработчикам доступ к данным и перенос данных без
    программирования, даже если они находятся в различных базах данных. Определения DataPipeline
    могут быть сохранены в виде объектов и затем использованы в приложениях.


    Художник приложений (Application Painter)

    Художник приложений определяет среду приложения, включая имя приложения и его
    пиктограмму, установленные по умолчанию цвета и шрифты, программы обработки событий
    приложений, список библиотеки, а также позволяет разработчику графически просматривать всю
    иерархию объектов приложения. Как только все объекты приложения будут созданы,
    откомпилированы и протестированы, Художник приложений создаст исполняемый файл
    (.EXE).


    Художник проектов (Project Painter)

    Художник проектов позволяет указывать порядок и параметры сборки различных
    приложений из общего набора объектов в библиотеках PowerBuilder. Определения проектов
    сохраняются в библиотеках и позволяют автоматизировать большинство действий по подготовке
    готового приложения.


    Художник структур (Structure Painter)

    Художник структур создает сложные структуры данных для использования их в
    конструкциях языка PowerScript и для связи с внешними функциями. Структуры помогают
    разработчику организовать переменные в программах и облегчают взаимодействие с внешними
    функциями.


    Художник запросов (Query Painter)

    Художник запросов предоставляет графические средства для создания запросов к базам
    данных и сохранения этих запросов в виде объектов. Объекты запросов можно использовать в
    качестве источника информации для Окна данных и отчетов, обеспечивая еще более тесную
    интеграцию с базами данных. Художник запросов полностью поддерживает графическое
    рисование SQL как для таблиц, так и для представлений. Для дополнительной гибкости пользователи
    при желании могут иметь полный доступ к оператору SQL Select.


    Идентификация модели заголовком (Title)

    Данный заголовок поддерживается в S-Designor специальным образом и служит не только
    для того, чтобы как-то приукрасить модель. Заголовок содержит идентифицирующую информацию,
    которая также хранится в центральном словаре данных и используется как при организации
    групповой разработки модели данных, так и в других целях.


    Идентификация сущностей. Сущности в ERwin

    На диаграмме сущность изображается прямоугольником. В зависимости от режима представления
    диаграммы прямоугольник может содержать имя сущности, ее описание, список ее атрибутов и другие
    сведения.

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

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

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

    Для каждого первичного ключа ERwin создает при генерации структуры БД уникальный индекс.

    Экземпляры независимой сущности могут быть уникально идентифицированы без определения ее
    связей с другими сущностями; зависимая сущность, наоборот, не может быть уникально
    идентифицирована без определения ее связей с другими сущностями. Зависимая сущность
    отображается в ERwin прямоугольником с закругленными углами.


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

    Надежда Вьюкова, Владимир Галатенко

    АО "Инфосистемы Джет"

    Informix-ViewPoint Pro

    Продукт Informix-ViewPoint Pro используется в двух качествах:

  • как вспомогательный инструмент администрирования баз данных
    Informix и репозиториев приложений;
  • как самостоятельный инструмент для разработки простейших приложений.


    Инструмент администрирования SQL Central

    SQL Central - графическое средство администрирования БД, работающее под Windows 95 и
    Windows NT 3.51. SQL Central соответствует интерфейсу Windows 95, поэтому его легко освоить и
    использовать.

    Главное окно SQL Central похоже по дизайну на Windows 95 Explorer. Оно разделено на две
    панели. В левой панели в виде дерева представлены серверы, базы данных и схемы баз данных с
    глубиной, доходящей до каждого "контейнера" - объекта базы данных. В правой панели показано
    содержимое выбранного контейнера.

    Из SQL Central осуществляются все административные действия от создания баз данных,
    загрузки/выгрузки до создания таблиц, процедур и назначения полномочий. SQL Central также
    управляет системой репликации SQL Remote, описанной выше.

    Для удобства предусмотрен drag-and-drop интерфейс, контекстная подсказка и контекстное меню
    по правой кнопке мыши.


    Инструментальная среда PowerBuilder

    Инструментальная среда разработки PowerBuilder состоит из ряда интегрированных графических
    инструментов - художников, позволяющих коллективу разработчиков проектировать, создавать,
    интерактивно тестировать и применять приложения клиент/сервер в режиме "укажи и щелкни
    кнопкой мыши". Cреда разработки PowerBuilder может быть расширена для организации
    непосредственного доступа к набору инструментальных средств разработки других фирм. Интерфейс
    пользователя PowerBuilder MDI позволяет разработчикам открывать окна нескольких художников
    одновременно, что дает возможность мгновенно получить доступ к нужному режиму работы.
    Поддержка средой разработки правой кнопки мыши упрощает и ускоряет процесс создания сложных
    приложений.


    Инструменты для создания модели в ERwin

    Основные инструменты создания модели доступны как из меню, так и через окно инструментов. С их
    помощью создаются независимые и зависимые сущности, идентифицирующие и неидентифицирующие
    связи, полные и неполные категории, неспецифические связи и текстовые элементы.

    Нажатием мыши над сущностью производится вход в один из многочисленных редакторов
    ERwin:

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

    Инструменты управления SQL-сервером

    Для анализа функционирования сервера Sybase предоставляет компоненту SQL Monitor,
    представляющую на любом компьютере-клиенте в графическом виде данные по загрузке сервера,
    вводу/выводу, интенсивности транзакций, использованию памяти сервером.

    SQL Monitor как клиент взаимодействует с SQL Monitor-сервером, выполняющемся на том же
    компьютере, что и SQL Server. SQL Monitor-сервер использует разделяемую память для доступа к
    информации о работе SQL Server, и поэтому не загружает SQL Server.


    Интеграция приложений в SQL Windows на основе современных технологий и стандартов

    Л.Бродский, Элко Технологии
    SQL Windows представляет собой объектно - ориентированную систему, предназначенную для
    профессионального разработчика.

    Объектный подход, заложенный в самом ядре системы в самых первых версиях, направлен на решение
    двух основных задач, встающих на стадии разработки любой информационной системы:


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

    С этой точки зрения SQL Windows представляет пользователям удобные и простые средства описания
    и разработки новых классов, обеспечивающих как единичное, в том числе многоуровневое, так и
    множественное наследование. В состав старшей версии продукта SQL Windows Corporate Edition
    входит система управления разработкой проектов Team Windows, тесно интегрированная со средой
    программирования.

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

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

    С этой точки зрения важное место занимает поддержка современных стандартов.
    В версии SQL
    Windows 5.0. 2 обеспечена поддержка технологии OLE 2.0. Это позволяет встраивать в приложения
    динамические объекты, обработка которых поддерживается внешними OLE 2.0. серверами, такими
    как Microsoft Excel, Word или Paint Brush. Эта технология позволяет разработчику создавать сложные
    документы и формы, содержащие в себе информацию из реляционных БД, электронные таблицы,
    текстовую информацию из разных источников, звуковые и видеоклипы. И все эти компоненты могут
    одновременно поддерживаться внутри единого рабочего пространства пользователя, без
    переключения между разными задачами.

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

    Для обеспечения создания OLE 2.0 контейнеров в составе SQL Windows поставляется c QuickOL20
    класс, который позволяет разработчику с помощью удобного графического интерфейса создавать
    OLE 2.0 контейнеры на своем рабочем пространстве.

    Обеспечивается также поддержка автоматных контроллеров OLE в среде SQL Windows. Автоматные
    контроллеры обеспечивают управление объектами - автоматами через посредство автоматного
    сервера. Автоматные объекты представляют собой OLE объекты с программируемым интерфейсом. В
    этом случае разработчик может сочетать функциональность заложенную в автоматном сервере, с той
    необходимой ему специфичной функциональностью объекта, которую он сам разрабатывает.

    SQL Windows дополнен редактором OLE классов, позволяющем определять и создавать
    функциональные классы SAL (языка программирования SQL Windows), которые также называются
    автоклассами. Функциональные классы создаются на основе библиотек типов.

    Библиотеки типов создаются при установке автоматного сервера и содержат описательную
    информацию по одному или нескольким различным типам или классам объектов. Эта описательная
    информация включает определение методов и параметров, поддерживаемым конкретным типом.


    SQL
    Windows использует описательную информацию для создания собственных функциональных классов,
    которые управляют объектом соответствующего типа. Эти классы называются также быстрыми OLE
    классами, так как не содержат реального кода автоматного объекта, а содержат только необходимые
    ссылки. Автоматный сервер обеспечивает поддержку создаваемых автоматных объектов во время
    выполнения.

    Разработчик в SQL Windows имеет возможность модифицировать OLE автоклассы путем определения
    собственных классов, наследуемых из OLE автоклассов, и добавляя в этих классах необходимую ему
    функциональность. Разработчик имеет также возможность интегрировать меню пользовательского
    интерфейса с меню автоматного сервера.

    Разработчику предоставлен Редактор параметров OLE объектов, который позволяет в удобном
    графическом виде связать источники данных приложения и их конкретные элементы с параметрами
    OLE объектов.

    Таким образом, автоматные контроллеры в SQL Windows представляют собой объекты, которые
    наследуются из создаваемых OLE автоклассов (в том числе путем множественного наследования) и
    обеспечивают пользовательскую функциональность наряду с функциональностью, заложенной в
    автоматном сервере. Связь достигается путем вызова функций из SQL Windows и передачи команд
    соответствующему автоматному серверу.

    Другим важным механизмом интеграции различных программных средств внутри приложения,
    реализованном в еще более ранних версиях SQL Windows, является динамический обмен данными
    DDE. Технология этого протокола основана на взаимодействии нескольких различных задач внутри
    приложения путем организации сессии между ними и выделении соответствующего логического
    канала сессии. Сессия в DDE инициируется DDE-клиентом и реализуется путем направления
    необходимых запросов и команд к DDE-серверу. При установлении сессии DDE-клиент указывает имя
    необходимого DDE-сервера и тему (topic) сессии. Если DDE-сервер поддерживает указанную тему,
    сессия устанавливается и логический канал выделяется.


    После установления сессии имя DDE-сервера и
    тема изменены быть не могут.

    В процессе сессии клиент и сервер могут обмениваться информацией, относящейся к одному или
    нескольким пунктам (item). Пункт должен ссылаться на данные, распознаваемые DDE-сервером.

    Программа, разработанная в SQL Windows, может выступать как в роли DDE-клиента, так и в роли
    DDE-сервера. Особое внимание заслуживает использование программ на SQL Windows в качестве
    DDE клиента, обеспечивающего взаимодействие с такими DDE серверами как Microsoft Word и Excel
    для формирования и обработки текстовой информации и электронных таблиц на основе информации
    из реляционных баз данных.

    Кроме поддержки этих технологий среда разработки в SQL Windows является открытой для
    поддержки различных компонент, реализованных сторонними разработчиками. В SQL Windows
    поддерживается механизм внешних библиотек, обеспечивающих возможность использования в SAL
    API, предоставляемых разработчиками этих систем. Так для создания интегрированных деловых
    систем, где необходима работа с большими потоками внешних документов, может быть использована
    и встроена в приложение система Fine Reader, обеспечивающая сканирование текстов и их
    распознавание. Причем указанные возможности становятся неотъемлемой частью пользовательского
    интерфейса, который сочетает различные этапы обработки информации и различные программные
    средства внутри единого приложения.

    SQL Windows поддерживает также при разработке такие популярные механизмы, как Drag and Drop, а
    также появившиеся в версии 5.0.2 закладки, позволяющие разработчику определять на едином
    рабочем пространстве информационные элементы, связанные с различными режимами работы
    пользователя, и привязывать их к разным закладкам, причем сам процесс определения закладок и
    соответствующих им информационных элементов реализован в виде удобного для разработчика
    графического интерфейса.

    []
    []
    []

    Интеграция приложений

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


    Интеграция с внешними приложениями - открытые интерфейсы

    Как следствие возможности обмена информацией с IDE, реальным кажется и интеграция среды
    разработки Delphi с внешними инструментальными средствами - системами контроля версий,
    мониторами транзакций, CASE-системами и т.п.

    Интеграция с внешними приложениями - открытые интерфейсы

    Интеграция со средствами разработки 4GL

    S-Designor поддерживает широкий спектр средств разработки 4GL. Поддержка средств
    разработки 4GL заключается в том, что на этапе проектирования модели данных обеспечивается
    возможность проектировать отображение элементов объектов, связанных с базой данных. Данную
    возможность проиллюстрируем на примере интеграции S-Designor со средством разработки
    приложений PowerBuilder фирмы PowerSoft .

    При создании окон данных (DataWindow) в PowerBuilder элементы окна отображаются
    согласно расширенным атрибутам, назначенным этим элементам. Либо действуют установки по
    умолчанию, если элементам окна расширенные атрибуты не назначены. Таким образом, расширенные
    атрибуты - это спецификации, которые управляют изображением DataWindow при его
    конструировании. Поэтому, использование расширенных атрибутов на этапе проектирования модели
    данных позволяет значительно ускорить разработку отдельных объектов в приложении, например,
    подготовку окон данных и стандартизовать пользовательский интерфейс.

    Расширенные атрибуты хранятся в репозитории средств разработки. Для PowerBuilder
    репозиторий представлен пятью таблицами, которые создает PowerBuilder в целевой БД при
    первом подключении к ней.

    Это таблицы:

  • PBCatTbl - содержит управляющую информацию, связанную с
    общим оформлением DataWindow (общие форматы отображения данных,
    заголовки колонок таблицы и так далее).
  • PBCatCol - содержит управляющую информацию, связанную с
    оформлением отдельных колонок DataWindow. Здесь же содержатся ссылки на
    форматы отображения, стили редактирования и правила.
  • PBCatFmt - содержит форматы отображения данных.
  • PBCatVld - содержит правила, которые должны выполняться при
    редактировании данных.
  • PBCatEdt - содержит стили редактирования данных.
    В S-Designor имеются возможности как импорта расширенных атрибутов в репозиторий
    целевого средства разработки, так и экспорта из репозитория в модель. Расширенные атрибуты
    можно сохранять в файлах и впоследствии при разработке новой модели данных загружать
    спроектированные ранее расширенные атрибуты в новую модель.

    В качестве расширенных атрибутов можно использовать выпадающие списки (окна данных типа Drop
    Down DataWindow). Можно создать ряд окон данных, например, для словарей. После этого
    необходимым колонкам таблиц в модели данных назначить стиль редактирования - Drop Down
    DataWindow, где этими окнами данных будут спроектированные ранее окна данных для словарей.
    После этого всегда, когда будет проектироваться основное DataWindow, в котором какие-либо
    колонки должны быть представлены в виде выпадающих списков, содержащих данные словарей, - это
    будет делаться автоматически.

    Значительно ускорить разработку приложений позволяет использование доменов. В терминах
    модели данных домен - именованный набор атрибутов объекта, который можно назначить колонке
    таблицы. Набор атрибутов домена логически делится на две части. Первую часть
    составляют расширенные атрибуты. Они используются при разработке приложений. Вторую -
    правила и ограничения, связанные с физической структурой таблиц БД. Можно определить,
    например, домен My_Date_Code для типа данных date и назначить его на колонки
    таблиц, имеющие такой тип данных. Таким образом, один раз сконструировав необходимый
    именованный набор атрибутов его можно многократно использовать и централизованно
    редактировать. При импорте расширенных атрибутов в репозиторий средств разработки S-
    Designor разложит "сам" эти атрибуты для тех колонок, на которые назначен домен
    My_Date_Code. Пример конструирования домена My_Date_Code. приведен на pис.5

    Интеграция со средствами разработки 4GL

    Интегрированная среда проектирования (Developer Designed)

  • Полностью интегрированное окружение
  • Быстрая итеративная разработка
  • Поддержка Windows 3.X, Windows 95, Windows NT, работа под Unix, Macintosh
  • Мощный язык 4GL управления данными PowerScript
  • Пространная справочная система
    PowerBuilder предоставляет полностью интегрированную среду для разработчика. Все компоненты
    приложения, такие как окна, меню, логика бизнеса, доступ к базам данных, создание баз данных,
    графика и отчеты, можно разрабатывать полностью в рамках PowerBuilder, при этом нет
    необходимости постоянно покидать среду и возвращаться в нее для выполнения каких-то
    операций.

    PowerBuilder - это быстрая итеративная среда разработки. Так как PowerBuilder имеет возможности
    независимой компиляции, интегрированной отладки и тестирования, можно создать и отладить
    приложение, не выходя из среды разработки.

    PowerBuilder полностью поддерживает Microsoft Windows, включая все сообщения Windows, элементы
    управления, многооконные приложения MDI (Multiple Document Interface), связывание и встраивание
    объектов OLE (Object Linking and Embedding), динамический обмен данными DDE (Dynamic Data
    Exchange) и вызовы динамически связываемых библиотек DLL (Dynamic Link Library) для интеграции
    с существующими приложениями на PC. Графический интерфейс пользователя GUI (Graphical User
    Interface) может быть создан разработчиком приложения без необходимости программировать на
    низком уровне, например, на языке C, или использовать комплект разработчика программ Windows
    SDK (Software Development Kit).

    PowerBuilder содержит PowerScript - мощный, похожий на Basic, язык управления данными 4GL,
    позволяющий разработчику легко включать простую и сложную деловую логику в приложения. Этот
    язык состоит более чем из 100 функций для манипулирования объектами, числами и текстом, функций
    обработки дат и времени, функций ввода/вывода, а также функций для полной поддержки OLE и DDE
    как в качестве клиента, так и в качестве сервера. Инструмент, входящий в состав PowerBuilder, -
    Художник функций (Function painter), позволяет разработчику легко расширять командный язык,
    добавляя к нему определяемые пользователем функции. Внешние функции можно декларировать,
    после чего они становятся доступными в приложениях PowerBuilder так же, как и встроенные функции,
    что позволяет взаимодействовать с внешними процедурами на 3GL, которые работают на сервере или
    клиенте.

    PowerBuilder снабжен подробной контекстно-зависимой оперативной подсказкой (Online Help),
    предоставляющей информацию из справочных руководств по PowerBuilder.


    Интеллектуальный SQL (SQL Smart)

  • Поддержка множества СУБД
  • Интеллектуальный объект Окно данных (DataWindow), управляющий
    взаимодействием с базами данных
  • Богатые возможности создания отчетов с использованием деловой графики
  • Мощные средства управления базами данных
    Возможности SQL Smart, входящего в состав PowerBuilder, обеспечивают тесную интеграцию с
    основной базой данных. PowerBuilder поддерживает широкий спектр систем управления
    реляционными базами данных и полностью использует специфические особенности каждой из них.
    Разработчики могут использовать встроенную высокопроизводительную реляционную базу данных
    WATCOM SQL для создания автономных приложений, а также для обеспечения работы приложений
    вне сервера.

    Только PowerBuilder имеет объект Окно данных (DataWindow). Интеллектуальный объект
    Окно данных позволяет манипулировать данными из реляционных баз данных без
    программирования на SQL. С помощью Окна данных можно извлекать, обновлять, добавлять,
    удалять, просматривать, печатать и сохранять данные в любом из 10 форматов файлов. Окно данных
    непосредственно управляет взаимодействием и манипуляциями с базой данных.

    Окно данных упрощает также создание отчетов. PowerBuilder позволяет создавать широкий
    спектр деловых отчетов в режиме "укажи и щелкни кнопкой мыши". Сюда относятся сложные
    ленточные таблицы, отчеты свободного формата, связанные таблицы, метки, многоколоночные
    отчеты с многоуровневыми группировкой и сортировкой, а также определенные пользователем
    вычисляемые поля, столбцы и итоговые суммы. Стандартная двухпроходная генерация отчетов
    позволяет вычислять средние значения, процентные отношения и постраничные суммы. Окна
    данных также предоставляют богатые возможности встроенной деловой графики для
    комбинирования текстовой и графической информации.

    PowerBuilder имеет интерактивные средства для создания баз данных SQL и манипулирования ими,
    избавляющие от необходимости изучения и использования SQL. Разработчики могут создавать
    таблицы и представления, определять первичные и внешние ключи, запускать командные файлы баз
    данных, обеспечивать безопасность и редактировать данные из базы данных - и все это в одной
    интегрированной среде.


    InterBase, NEXUS & Java

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


  • InterBase: 4.1-4.5 -> replication. Возможности репликации в SQL-сервере
    InterBase 4.5.
  • InterBase InterClient. Возможность удаленного доступа к таблицам InterBase
    через новый протокол доступа.
  • InterBase: NS API, CGI. Интерфейс InterBase с наиболее
    распространенными стандартами Web-серверов.
  • InterBase: UDF on Java. Возможность разработки и выполнения функций,
    линкуемых к ядру сервера, написанных на языке Java.
  • NEXUS: application server. Появление сервера приложений в многозвенной
    N-Tier системе.
  • NEXUS: business rules. Определение бизнес-правил на сервере
    приложений.
  • NEXUS: several SQL-servers. Сервер приложений может работать с
    несколькими источниками данных.
  • 3-Tier -> N-Tier. Естественное преобразование архитектуры клиент-сервер
    в N-Tier архитектуру.

    Пример: система торгов на бирже.


    Вашему вниманию предлагается описание реальной системы, реализованной с использованием
    части новых технологий. Эта система представляет собой модель биржи ценных бумаг, где
    брокерское место может работать как интернетовское удаленное клиентское место или как
    клиентское место в локальной сети. Каждый клиент может работать с данными при помощи
    стандартного броузера Netscape или при помощи эмулятора терминала (правда, в этом случае он
    будет вынужден покупать и продавать акции вслепую - история торгов, характеристики компаний
    представляются в виде графиков - в текстовом терминале такие возможности отсутствуют.

    Архитектура системы - слабый клиент, Web-сервер, сервер приложений, InterBase 4.0 для AIX -
    стандартное решение для Intranet. Вся система может работать как в Internet, так и в закрытой
    внутренней сети. Производительность системы удивила даже разработчиков - никто не ожидал
    таких результатов, имея опыт разработки клиент-серверных систем.
    Безопасность - в модели
    реализовано кодирование передаваемых данных алгоритмом RSA, который всегда можно
    поменять на другой; данные передаются по сети в зашифрованном виде. Количество одновременно
    работающих клиентов может достигать, в зависимости от типа аппаратуры до нескольких тысяч
    подключений одновременно. Место администратора торгов сделано по классической клиент-
    серверной схеме, минуя многозвенную цепочку. Клиентское место администратора разработано на
    Delphi, сервер приложений представляет из себя расширение Web-сервера, написанное на C и
    комплект UDF для InterBase, написанный также на С. Разработка заняла 2 месяца.

    Почему InterBase.

    Естественный вопрос, который может возникнуть у специалистов, почему выбран InterBase в
    качестве основы для такой разработки. Ведь в последнее время появилось достаточно много Web-
    расширений известнейших SQL-серверов - например, Oracle, Sybase, Informix и др. Фактически,
    причин было несколько:


  • перспективность работы в этом направлении. Как уже рассказывалось
    выше, Borland предприняло ряд шагов по обеспечению разработчиков в Intranet
    инструментарием, применение которого кажется нам целесообразным.
  • многоплатформенность InterBase. InterBase реализован для более чем 20
    платформ, список этот постоянно расширяется, поэтому разработчики не
    скованы необходимостью использования платформы прототипа системы.
  • беспрецедентная открытость InterBase, как инструмента. Именно
    возможность подключения функций, написанных на С разработчиками,
    позволяет обеспечить высокую производительность системы в целом.
  • самонастраиваемость сервера.

    Технические особенности InterBase 4.0.

    Вкратце перечислим основные особенности InterBase 4.0:


  • многоплатформенность: - NetWare, Windows NT, SCO UNIX, AIX, IRIX,
    Solaris, HP/UX, open VMS, NextStep и др. (более 20 платформ)
  • архитектура множественных поколений записи - возможность
    безблокировочной работы и быстрого восстановления после сбоев.
  • Возможность работы с "моментальным снимком" базы и поддержка DSS.


  • триггеры и хранимые процедуры
  • декларативная ссылочная целостность
  • поддержка online complex processing
  • соответствие стандарту SQL89 и драфт-стандарту SQL III
  • определяемые пользователем функции
  • сигнализаторы событий
  • поддержка 2 Phase Commit
  • поддержка больших двоичных объектов и массивов (размерность - до16)
  • интеграция с широко распространенными инструментами разработчика -
    Delphi, Paradox, BC++, Visual dBase, CASE-средства третьих фирм.

    Инициативы Borland в отношении Internet

    Процитируем несколько строчек из пресс-релиза компании Borland:

    Borland объявила две фазы реализации решений для Internet.

    Первая из них, по словам Пола Гросса, вице-президента компании, заключается в расширении уже
    существующих продуктов Borland дополнительными Internet-инструментами. В ближайших планах
    реализации такого подхода компании - обеспечение поддержки разработки Java-приложений в
    Borland C++ 5.0 и выпуск Visual dBase Internet Tools.

    Вторая фаза, как было описано Гроссом, состоит в предоставлении заказчикам Intranet-решений -
    внутрикорпоративных сетевых систем на базе стандартов и средств Internet.

    " Ядро технологий Delphi, которые позволили достичь огромного успеха на рынке рабочих групп,
    также обеспечит наш успех и на рынке Intranet-инструментов", отмечает Пол Гросс. "Мы
    убеждены, что Java, как стандарт программирования для Internet, в сочетании с новейшими
    инструментальными технологиями, представленными в Delphi, станет платформой для
    распределенных вычислений в Intranet."

    Borland отмечает, что Borland C++ 5.0, планируемый к выпуску в конце этого квартала, включает
    средства разработки и отладки Java-приложений. Среда разработки предоставляет первый
    графический отладчик для Java, позволяющий разработчикам находить и исправлять ошибки в
    приложениях, написанных на языке Java. Компания, также, объявила о планах и
    продемонстрировала "just-in-time" компилятор (транслятор в машинный код) под
    названием AppAccelerator, позволяющий увеличить производительность существующих Java-


    приложений в 5- 10 раз. Application Accelerator планируется к выпуску в составе Borland
    C++ Development Suite 5.0 в конце этого квартала.

    Отладчик и AppAccelerator являются первыми компонентами, которые, в дальнейшем,
    будут интегрированы в единый инструмент визуальной разработки форм в стиле Delphi для
    языка Java. В ноябре 1995 года Borland анонсировала такой продукт под кодовым названием
    Latte.

    Borland официально объявила о планах создания InterBase InterClient - расширении InterBase,
    поддерживающем Java. Этот инструмент принесет большой выигрыш корпоративным
    пользователям InterBase. В дальнейшем, Borland также планирует предложить сервер приложений
    под кодовым названием "Nexus" для удаленного доступа к базам данных на основе Java. Это
    позволит Intranet-разработчикам получить действительно трехуровневое (three-tier) окружение со
    всеми преимуществами много-платформенности и соответствующих стандартов протоколов.

    С 9 февраля до 31 марта 1996 года разработчики могут свободно получить предварительную
    версию графического отладчика Borland для Java-приложений через Web-сервер компании - .

    []
    []
    []

    Интерфейс к CASE структурного анализа и дизайна - JAM/CASEi

    Интерфейс к CASE структурного анализа и дизайна в некотором отношении подобен интерфейсу к
    СУБД. Одной из основных задач CASE является разработка структуры БД. Информация о
    структуре БД хранится в репозитории CASE. Модуль JAM/CASEi позволяет осуществить обмен
    информацией между Визуальным Репозиторием Объектов JAM и репозиторием CASE
    аналогично тому, как структура БД импортируется в Репозиторий

    JAM непосредственно из БД. Отличие заключается в том, что в случае интерфейса к CASE этот
    обмен является двунаправленным, т.е. информацию из Репозитория JAM можно экспортировать в
    репозиторий CASE.

    Интерфейс к CASE структурного анализа и дизайна - JAM/CASEi

    Интерфейс к Мониторам Транзакций - JAM/TPi

    Модули JAM/TPi используются при разработке приложения трехзвенной модели "клиент-сервер" с
    применением мониторов транзакций.

    Рис. 5 представляет схему реализации трехзвенной архитектуры "клиент-сервер" с использованием
    JAM, JAM/TPi-Client и JAM/TPi-Server.

    При разработке клиентской части трехзвенной модели модуль JAM/TPi-Client позволяет в методах
    объектов использовать вызовы сервисов монитора транзакций. Наличие модуля JAM/TPi-Client
    расширяет синтаксис JPL командами, ориентированными на работу с мониторами
    транзакций.

    При разработке сервера приложений модуль JAM/TPi-Server позволяет разрабатывать сервисы
    монитора транзакций, используя современную 4GL технологию, а не только традиционный для
    мониторов транзакций 3GL интерфейс.

    Интерфейс к Мониторам Транзакций - JAM/TPi

    Интерфейс к СУБД - JAM/DBi

    JAM ориентирован на работу с реляционными SQL-серверами БД. Средством взаимодействия
    JAM-приложений с СУБД является SQL. При разработки приложений БД SQL-запросы являются
    составными частями методов объектов приложения. Модуль JAM/DBi осуществляет корректную
    передачу SQL запроса соответствующей СУБД и прием и обработку результатов исполнения
    запроса (включая и коды аварийного завершения при невыполнении запроса). Аргументами
    запросов (т.е. источниками и приемниками информации) могут выступать объекты JAM
    (интерфейсные элементы) и переменные JPL. В случае аварийного завершения запроса существует
    возможность самостоятельной обработки кода аварийного завершения.

    На рис. 3 представлена архитектура взаимодействия JAM и СУБД с помощью модулей
    JAM/DBi.

    Интерфейс к СУБД - JAM/DBi

    Интерфейс программирования серверов Open Server

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

    Технология и библиотеки OpenServer, входящие в состав Sybase System 11, позволяют
    разрабатывать собственные приложения, использующие данные от технологического
    оборудования. Для приложений клиента такие программы "выглядят" как хранимые процедуры на
    Sybase-совместимом сервере базы данных.

    Другое применение Open Server - разработка серверных компонент для математической или
    криптографической обработки данных. Обработчик Open Server может быть использован как
    приложением-клиентом, так и вызван из хранимой процедуры SQL Server.

    Примером применения технологии Open Server может служить реализация доступа к электронной
    почте из хранимых процедур.


    Интерфейсы к СУБД

    ERwin поддерживает прямой интерфейс с основными СУБД: DB2 версии 2 и 3, Informix версий 5.1,
    6.0, 7.1, Ingres, NetWare SQL, ORACLE версий 6 и 7, Progress, Rdb версий 4 и 6, SQL/400 версий 2 и
    3, SQLBase версий 5 и 6, SQL Server версий 4 и 6, Sybase версии 4.2, Sybase System 10 и 11, Watcom
    SQL. Отметим, что поддерживаются как самые современные, так и предыдущие версии основных
    СУБД (рис.8).

    Интерфейсы к СУБД

    Интерфейсы прикладных программ

    Программные интерфейсы ко всем службам, предоставляемым архитектурой Sybase, реализуются
    через API Open Client и Open Server. Программные интерфейсы Open Client/Server независимы от
    платформы. Среди поддерживаемых платформ DOS, Windows, MVS/CICS, Macintosh, NetWare,
    Windows NT, OS/2, UNIX (все главные варианты), VMS и OpenVMS.

    При разработке приложений-клиентов на языке 3-го поколения используются библиотеки с Cи-
    интерфейсом: DB-Library, CT-Library или ODBC (только под Windows).

    При разработке приложений серверного типа используется библиотека Open Server. Этот набор
    блоков для построения сервера может использоваться, например, для доступа к нестандартному
    оборудованию или построения шлюзов.


    Интерфейсы программирования клиента:библиотеки DB- Library и CT-Library

    DB-Library использовалась в предыдущих версиях Sybase для разработки приложений. Sybase
    System 11 обеспечивает обратную совместимость с DB-Library.

    CT-Library впервые появилась в Sybase System 10. Она используется в новых приложениях, в том
    числе для написания приложений с использованием асинхронной обработки, возможностей
    распределенной обработки, одновременным использованием Open Client и Open Server.

    Все продукты Sybase используют механизм сообщений об ошибках. В библиотеках этот механизм
    реализован через callback-модель, т.е. функции приложения, асинхронно вызываемые при
    возникновении ошибочных ситуаций и сообщений.


    INTERNET и INTRANET

    О применении технологий Internet для построения корпоративных информационных систем
    заговорили уже давно. Заманчиво было бы использовать опыт надежного и удобного соединения
    разнородных вычислительных ресурсов в единую систему, уже обкатанный в Internet, для решения
    внутрикорпоративных задач. Основные проблемы, которые встречаются на этом пути - это
    отсутствие стабильных стандартов, что характерно для бурно развивающегося рынка.

    Давайте посмотрим, какими возможностями обладает разработчик при использовании
    технологий Internet в проекте закрытой корпоративной сети.


  • TCP/IP

    Первое и самое главное - сетевой протокол ТСP/IP фактически реализован для любых типов сетей.
    Любая аппаратурная экзотика поддерживает этот протокол.


  • коннект

    Коннект клиентского броузера к WEB-серверу осуществляется исключительно легко. Многие
    проблемы, которые были в прежней архитектуре клиент-сервер, когда клиентское приложение
    напрямую осуществляет доступ к SQL-серверу, снимаются при использовании технологии Internet.
    На сервере требуется меньше памяти, логика коннекта позволяет "удерживать" коннект даже при
    физическом обрыве линии. Поскольку взаимодействие интернетовских броузеров с хостом
    отлаживалось в самых разных условиях, по-разному передаются различные куски информации.
    Так например, в расчете на медленное соединение вначале клиенту передается текстовая
    информация, и только потом докачиваются графические или другие большие двоичные объекты.
    Пользователь модемной линии может не дожидаться докачки всего изображения и принять
    решение о переходе к новой странице информации.


  • данные: файлы, текст, ссылки, изображение, 3D, звук

    Понимание того, что ограниченность типов данных является препятствием к широкому
    применению классических реляционных СУБД, привела к расширению типов данных,
    используемых современными SQL-серверами. Например, InterBase может оперировать
    расширенным типом данных BLOb - большими двоичными объектами. А броузеры Internet могут
    воспринимать текстовую информацию, ссылки на ресурсы (URL), изображение, звук, оперировать

    присоединенными файлами.


  • отработанный механизм маршрутизации и логики коннекта

    Надежность механизмов маршрутизации Internet позволяет строить сколь угодно сложную и
    разветвленную сеть.


  • меры безопасности

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


  • многоплатформенность

    В свое время Internet так или иначе справился с этой проблемой. И в настоящее время мы можем
    пользоваться результатами: стандартные броузеры реализованы для всех мало-мальски значимых
    платформ, новые стандарты (например, язык Java) также ориентированы на применение на всем
    разнообразии используемой техники и операционных сред.


  • текущая ситуация

    Мы только что обсудили преимущества интернетовской технологии для реализации
    внтрикорпоративной системы, и что же, какова ситуация в настоящий момент, насколько
    приемлемым кажется использование этой технологий для менеджеров информационных сетей
    больших корпораций? Завставляет задуматься тот факт, что, по утверждениям экспертов,
    соотношение пользователей внутрикорпоративных сетей к пользователям Internet - 5:1.


  • отсутствие стандартов

    И все-таки, следует подчеркнуть, что бурное развитие Internet, подобно бурному росту юноши-
    акселерата, результатом своим имеет множество проблем. Трудности роста - скажут многие.
    Разработчику большой системы приходится иметь дело со множеством неустоявшихся стандартов,
    или, что очень опасно для будущего системы - со стандартом де-факто, пока еще не принятым, но
    уже достаточно распространенным. При оценке возможной стоимости системы следует учитывать
    это обстоятельство. Так родителям подростка разумно планировать будущие затраты на покупку
    новой одежды взамен той, что станет мала через полгода-год.

    INTRANET: информационная система


  • клиент-сервер.... или... ?

    Мы составили себе определенное впечатление об INTRANET, как о системе, каждый клиент
    доступается к данным Web-сервера посредством своего броузера. Но является ли такая
    архитектура архитектурой клиент-сервер? Ведь в классическом понимании на клиентское
    приложение возлагаются некие дополнительные задачи - дополнительная логика. Позволяет ли
    стандартный броузер решать такие задачи?

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


  • логика на сервере

    Слабость клиента заставляет размещать логику приложения на сервере; фактически, для
    реализации не только системы подачи информации (или рекламного гипертекстового сервера)
    требуется существенно дописывать функционирование стандартного Web-сервера, превращая (или
    дополняя) его в application server.


  • логика на клиенте

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

    Сейчас пока трудно предсказать, какой язык сможет разрешить все противоречивые требования к
    нему, однако, наиболее перспективным кандидатом на роль интернетовского эсперанто является
    язык Java, разработанный компанией Sun Microsystems.


  • N-tier ?

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


  • связь с БД

    Мы не обсудили еще один очень важный аспект построения сложной системы - это сложность
    поддержания данных в целостном и структурированном виде для систем Intranet. Наиболее
    распространенная технология, когда данные представлены в виде гипертекстовых страниц,
    связанных перекрестными ссылками, не слишком применима для корпораций, имеющих дело с
    потоком часто обновляемой и меняющейся информации. Технология реляционных баз данных
    доказала свою применимость для таких случаев. Поэтому весьма важно знать о совместимости
    подхода Internet к использованию SQL-сервера в качестве хранилища информации. В прессе уже
    звучали заявления различных ведущих компаний о решении тем или иным способом этой
    проблемы.


  • формирование страниц "на лету"

    Фактически основным требованием является обеспечить Web-сервером формирование
    гипертекстовых страничек для клиентского броузера, исходя из результатов запроса к SQL-серверу
    и шаблона такой странички.

    О создании инструментов создания таких систем объявили практически все ведущие компании:
    Oracle, Informix, Sybase, Borland, Microsoft, IBM..., но, раз уж статья посвящена технологиям
    компании Borland, остановимся на особенностях решений компании Borland.


  • Visual dBase Internet Tools

    Реализовать логику Web-сервера можно по-разному, и один из новых инструментов компании
    Borland предназначен для значительного количества приверженцев Visual dBase.


    Visual dBase
    Internet Tools позволяет реализовывать, с одной стороны, как клиентское приложение,
    получающее доступ к Internet, так и серверную логику для Web-сервера, работающего под
    управлением Windows NT.


  • Delphi components

    Такой расширяемый инструмент, как Delphi, естественно не мог остаться без внимания как
    Borland, так и третьих фирм, специализирующихся на написании компонент. Сейчас существует
    уже целый спектр работоспособных решений для Delphi, от компонент для создания собственных
    броузеров до компонент, позволяющих создавать application server в многоярусной (N-Tier)
    архитектуре информационной системы Internet/Intranet.


  • Paradox & CGI

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


  • InterBase InterClient

    Планируется выпуск специального дополнительного линка для SQL-сервера компании Borland,
    позволяющего обращаться за данными к серверу непосредственно из интернетовского
    клиента.

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


  • NEXUS

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


  • JAVA и LATTE

    Что же такого привлекательного имеется в новом языке программирования Java?

    Java - это язык, во многом похожий на C++, однако имеющий несколько весьма неожиданных
    черт. Строгая типизация, как в языке Паскаль, отсутствие множественного наследования и строгое
    определение интерфейса объектов, поддержка многопотоковости на уровне языка, ввод-вывод в
    парадигме сокетов - вот основные особенности Java. При загрузке броузером приложения (applet -
    буквально "приложеньица") на языке Java происходит его верификация интерпретатором Java, а
    затем и исполнение. Такой способ исполнения позволяет избежать заражения системы
    вирусом.

    Базовый интерпретатор Java занимает совсем немного места - для Windows 95 он составляет всего
    145 Кб - поэтому перенос всей системы для новой операционной и аппаратной платформы не
    составляет труда, и это чувствуется - все новые и новые компании объявляют о своей поддержке
    этого языка.

    Инвертированные индексы

    Атрибуты, составляющие альтернативный ключ, однозначно (уникально) идентифицируют
    экземпляры сущности. В ERwin можно также составлять группы атрибутов, которые не
    идентифицируют уникально экземпляры сущности, но часто используются для доступа к данным. Для
    каждой такой группы атрибутов ERwin создает неуникальные индексы.

    Одни и те же атрибуты сущности могут входить в несколько различных групп ключей.


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

    Набор расширенных хранимых процедур SQL Server включает процедуры работы с почтовыми
    ящиками. Сервер может получить указание прочесть текущую почту и обработать ее (лучше всего
    это задание оформить как периодически выполняемую задачу). В сообщении размещается вызов
    хранимой процедуры или набор команд T-SQL. Сервер читает текст сообщения и выполняет
    размещенные в нем команды. Результат исполнения присоединяется к письму, посылаемому в
    ответ, в виде текстового файла или файла в формате CSV (поля, разделенные запятыми), который
    можно непосредственно "взять" в электронную таблицу или импортировать в базу данных.
    Естественно, возникает вопрос о предохранении данных от несанкционированного доступа.
    Ограничение числа лиц, которые могут получать таким образом информацию, может быть
    организовано различным образом, и тут необходимо позаботиться о защите доступа как со
    стороны SQL Server, так и со стороны ПО, занимающегося отправкой почты. Для каждого
    пользователя, который посылает запросы на сервер, можно завести соответствующий набор прав,
    которые смогут эффективно ограничить диапазон действий, позволительных для него.

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

    SQL Server способен "понять", кто пишет письмо. Можно также ограничить обрабатываемую
    почту только письмами, которые имеют определенный текст в разделе Subject. Все это вместе
    взятое позволяет утверждать, что если в организации четко соблюдается дисциплина хранения и
    назначения паролей, то риск несанкционированного доступа к конфиденциальной информации
    может быть сведен до минимума. Кроме того, на электронную почту можно возложить
    обязанности по получению/передаче только безобидной информации, доступ к которой не
    нуждается в серьезной защите.


    Использование наследования

    По умолчанию вновь генерируемый оконный класс является наследником системного класса
    ixWindow. Однако программист может указать в качестве базового и другой оконный класс,
    созданный ранее. Например, если требуется, чтобы все окна приложения содержали логотип
    фирмы, то достаточно сгенерировать оконный класс с желаемым графическим компонентом и
    указывать этот класс в качестве базового для других окон приложения.


    Источники информации:


  • Материалы 6-й Ежегодной Конференции Разработчиков Borland.
  • Периодические издания (1995 год): Delphi Informant, Delphi Developer, Microsoft System
    Journal, Dr. Dobb Journal, Компьютерр-Пресс и др.
  • WWW-серверы: Borland, Miller Friman, Turbo Power, ProtoView, Popkin Software, InterSolv,
    AOL и др.
  • "Delphi Developers Guide", S.Tiexeira & X. Pacheco, SAMS Publishing / Borland PRESS.
  • Каталоги программных продуктов "Delphi Only Tools" ZAC Catalog, "Delphi
    Power Tools" Informant Communications Group.

    []
    []
    []

    Ядро системы

    Ядро системы включает в себя следующие основные компоненты:


  • Редактор Экранов. В состав Редактора Экранов входят:
  • Среда разработки экранов;
  • Визуальный Репозиторий Объектов;
  • Собственная СУБД JAM - JDB;
  • Менеджер Транзакций;
  • Отладчик;
  • Редактор Стилей;
  • Редактор Меню;
  • Набор вспомогательных отдельных утилит;
  • Средства изготовления промышленного релиза приложения;

    Общая схема взаимодействия компонент ядра JAM представлена на рис 1.

    Ядро системы

    JAM7 - инструмент разработки переносимых приложений архитектуры "клиент-сервер"

    Ю.Петров, Компания Аргуссофт
    Инструментарий разработки приложений JAM разработан и распространяется фирмой JYACC
    (США) и название продукта расшифровывается как JYACC's Application Manager. Фирма JYACC
    является частной и была создана в 1978 году. С 1978 по 1985 год фирма занималась консалтингом в
    области информационных технологий. В 1985 году была выпущена первая версия JAM. На
    сегодняшний день поставляется 7-я версия пакета. Вместе с тем JYACC не прекращает и
    деятельности в консалтинговой сфере.


    Язык четвертого поколения 4GL PROGRESS

    Язык Четвертого Поколения PROGRESS (4GL) является функционально полным
    высокоуровневым , объектно-ориентированным языком разработки приложений, который
    позволяет удовлетворять всем требованиям, предъявляемым к современным приложениям, в тоже
    время уменьшая сложность и повышая производительность их разработки.

    4GL содержит все необходимые программные конструкции для решения самых различных
    аспектов программирования сложных приложений без необходимости прибегать к менее
    эффективным и менее переносимым языкам третьего поколения. Кроме этого, 4GL обеспечивает
    поддержку и переход между тремя основными принципами программирования:
    структурированным, событийно-управляемым и объектно-ориентированным, - от Вас не требуется
    осваивать новые принципы программирования для того, чтобы успешно работать с PROGRESS.
    Для завершения процесса разработки промышленного приложения Вам потребуются средства
    разработки не только логики взаимодействия с пользователем, но также потребуются средства для
    решения таких важных задач, как:

  • Автоматический контроль транзакций и блокирование записей
  • Получение и обработка информации из баз данных
  • Сложные вычисления и обработка данных
  • Пакетная обработка
  • Генерация отчетов
  • Целостность базы данных и требования безопасности
  • Поддержка двухбайтовых кодировок
    Язык 4GL содержит все функции и операторы, необходимые для удовлетворения
    вышеперечисленных требований. Но, в отличие от остальных инструментальных средств, менее
    ориентированных на разработку приложения в архитектуре клиент/сервер, PROGRESS не требует
    от Вас использования различных языков программирования для отдельного программирования
    обработки данных на клиенте, серверных процессов и пакетной обработки на сервере. Все это
    уменьшает стоимость затрат по изучению языка и продолжению разработки. Кроме этого Вы
    можете интегрировать другие приложения и Си-код в PROGRESS, используя интерфейсы DDE,
    DLL и именованные каналы, так же, в том числе наш собственный интерфейс Вызова Внешних

    Процедур ( Host Language Interface) для использования внешних процедур на языке Си.

    Язык 4GL является легко переносимым средством, позволяющим снизить издержки или вообще
    исключить их при использовании приложения на различных программных и аппаратных
    платформах.

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

    PROGRESS 4GL является первым объектно-ориентированным языком четвертого поколения,
    который вводит понятие инкапсулированных процедурных объектов. Это позволяет Вам
    использовать высокопроизводительную среду 4GL для разработки и дальнейшей модификации
    многократно используемых объектов пользовательского интерфейса и объектов данных, не
    затрачивая дополнительных сил и средств на изучение объектно-ориентированных языков
    третьего поколения, таких как Cи++ и SmallTalk.

    Приложения, разработанные с использованием Построителя Интерфейса, и отчеты,
    сгенерированные при помощи утилиты Results или Построителя Отчетов, легко могут быть
    модифицированы и расширены с помощью средств языка 4GL, обеспечивая, таким образом,
    максимальное соответствие разрабатываемого приложения требованиям пользователей.

    Как и все остальные средства Среды Разработки Приложений PROGRESS, язык 4GL наследует все
    центрально хранимые в Словаре Данных умолчания (такие, как проверка правильности ввода,
    форматы отображения и правила целостности данных). Наследование этих установок уменьшает
    стоимость разработки приложения и снижает затраты по его поддержке в дальнейшем).

    PROGRESS 4GL включает полный набор языковых средств для управления объектами,
    построения циклов и логических условий, обработки всех типов данных, а также имеет полный
    набор операторов для обработки реакции пользователя при разработке событийно-управляемых
    приложений.

    Если вы знакомы с такими языками, как COBOL, BASIC или С, то изучение PROGRESS 4GL не
    составит для Вас труда. Также Вам должны понравиться системы высокоуровневых умолчаний и
    операторы, присущие среде 4GL.

    Если Ваши приложения ориентированы на использование во всем мире, то PROGRESS 4GL
    предоставит Вам в распоряжение средства поддержки самых разнообразных кодировок, включая
    двухбайтные, используемые в странах Азии.

    JPL - внутренний процедурный язык программирования JAM

    В состав Редактора Экранов входит JPL - процедурный интерпретируемый язык
    программирования с синтаксисом, похожим на синтаксис C. В JPL доступны следующие
    возможности:
  • Скалярные переменные и одно- и двумерные массивы;
  • Управляющие конструкции - if, else, for, while, break и next;
  • Передача параметров в функции и возврат значений.
    Все JPL-функции оформляются в виде JPL-модулей. JPL-модуль является набором нескольких
    именованных функций и не более одной неименованной функции. Неименованная функция есть
    JPL-код от начала модуля до первой именованной процедуры и, очевидно, может отсутствовать в
    модуле, если он начинается сразу с именованной процедуры. Из неименованной процедура
    доступны именованные. JPL-модули могут быть трех типов:
  • Модуль экранного объекта (vidget module). Хранится вместе с
    объектом. Неименованная процедура исполняется при возникновении события
    validation для данного момента;
  • Экранный модуль (screen module). Хранится вместе с экраном.
    Неименованная процедура исполняется при загрузке экрана, именованные
    процедуры могут являться обработчиками событий всех объектов данного
    экрана;
  • Внешний модуль (external module). Хранится в отдельном файле.
    Загружается в память или принудительно, или при вызове процедуры с именем
    этого файла. Возможна принудительная выгрузка. Неименованная процедура
    исполняется при загрузке модуля. Внешние модули целесообразно
    использовать для хранения универсальных процедур.
    Экранные модули и модули объектов хранятся как в текстовом, так и в прекомпилированном (в
    некоторый промежуточный код) виде. Доступны для редактирования в Редакторе Экранов.
    Внешние модули хранятся в виде текстовых файлов. С помощью специальной утилиты текстовые
    внешние модули могут быть прекомпилированы. Прекомпилированные внешние модули могут
    храниться в библиотеках экранов.

    Визуальный Репозиторий Объектов

    Реализация принципов объектно-оpиентиpованного программирования осуществлена в JAM
    следующим образом. Каждый элемент приложения с определенными свойствами и методами (в

    качестве которых выступают обработчики событий) является объектом. Одной из составных частей
    ядра JAM является Визуальный Репозиторий Объектов, в котором можно сохранять созданные
    объекты. Визуальный Репозиторий Объектов является специальным типом библиотеки экранов и
    соответствующим образом организован. Т.е. Репозиторий состоит из так называемых входов
    (entries). которые выглядят как экраны с базовыми объектами на них. Текущая установка свойств и
    методов является базовой. Для использования какого-либо базового объекта достаточно перенести
    его мышью с входа Репозитория на проектируемый экран. При изменении свойств и/или методов
    базового объекта эти изменения распространяются на всех потомков данного объекта. Реализован
    механизм управляемого наследования свойств и методов, при котором можно запретить
    наследование части или всех свойств/методов. Вся работа с Репозиторием осуществляется в
    Редакторе.

    Поддержка групповой разработки

    Ядро JAM имеет встроенный интерфейс к системам управления многоверсионными проектами и
    групповой разработки (PVCS на платформе Windows и SCCS на платформе UNIX). При этом под
    управление этих систем передаются библиотеки экранов и/или Репозитории. При отсутствии таких
    систем JAM самостоятельно реализует часть функций поддержки групповой разработки.

    Редактор Меню

    Позволяет разрабатывать и отлаживать системы меню. Реализована возможность построения
    пиктографических меню (так называемые toolbar). Меню могут сохраняться как в отдельных
    файлах, так и в экранных библиотеках. В одном файле может быть несколько поименованных
    меню. Назначение каждого конкретного меню тому или иному объекту приложения
    осуществляется в Редакторе Экранов.

    Собственная СУБД JAM - JDB

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


    хранимых процедур, триггеров и так называемых view. В результате с помощью JDB можно
    построить БД, идентичную целевой БД (с точностью до отсутствующих в JDB возможностей) и
    разработать значительную часть приложения не загружая сеть и сервер. В состав JAM входит
    утилита интерактивного SQL для JDB.

    Отладчик

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

    Набор вспомогательных отдельных утилит

    Утилиты JAM представляют три группы:

  • Конвертор файлов экранов JAM в текстовые файлы. JAM сохраняет
    экраны в виде двоичных файлов собственного формата. В ряде случаев
    (например для изготовления проектной документации) необходимо текстовое
    описание экранов;
  • Конфигурирование устройств ввода/вывода. JAM и приложения,
    построенные с его помощью, не работают непосредственно с устройствами
    ввода/вывода. Вместо этого JAM обращается к логическим устройствам
    ввода/вывода (клавиатура, терминал, отчет). Отображение логических
    устройств в физические осуществляется с помощью развитых средств
    конфигурирования;
  • Обслуживание библиотек экранов. Осуществляются традиционные
    операции с библиотеками.

    Средства изготовления промышленного релиза приложения

    Приложения, разработанные с использованием JAM, не требуют так называемых run-time систем и
    могут быть изготовлены в виде исполняемых модулей. Для этого разработчик должен иметь
    компилятор C и редактор связей. Для изготовления промышленного релиза в состав JAM входит
    файл сборки (makefile), исходные тексты (на языке C) ряда модулей приложения и необходимые
    библиотеки.

    Классификация информационных систем

    По масштабам применения современные АС подразделяются на три основные класса:
  • Настольные - для работы одного человека. К ним следует отнести Автоматизированное
    Рабочее Место (АРМ) бухгалтера малого предприятия, АРМ кассира, АРМ расчетчика
    заработной платы и.т.д. Внедрение таких программ не вызывает особых трудностей и для
    хороших систем может исчисляться днями.

    Классификация информационных системОсновные проблемы возникают при объединении
    информации с разных участков учета - так как рабочие данные специалистов хранятся на
    разных компьютерах, и возникает много рассогласований. Например, один и тот же объект
    (материал, товар, изделие) на разных АРМах может иметь разные коды.
  • Офисные - для работы отдела. К такого рода системам следует отнести сетевые бухгалтерские
    программы, программы автоматизации торгового зала, сетевые складские программы и.т.д.
    Сотрудники всего отдела могут одновременно работать с единой базой данных, выполняя
    отдельную функцию управления предприятием. Внедрение систем этого класса значительно
    сложнее настольных : требуется упорядочение плана счетов, составление общего справочника
    поставщиков и потребителей, настройка на учетную политику предприятия, обучение
    персонала и т.д.

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

    Рассмотрим корпоративные системы, которые только в настоящее время стали появляться на
    нашем рынке, и в скором времени неизбежно станут столь же популярны, как и на Западе. Может
    показаться, что корпоративные системы нужны только крупным предприятиям. На самом деле те
    проблемы, которые в них решаются, актуальны для любой фирмы.
    Ниже приводятся отличительные черты современных корпоративных систем.

    Классификация продуктов Oracle

    Все многообразие продуктов фирмы Oracle можно разделить на следующие группы (смотри
    таблицу):


  • Oracle7 Server - ядро СУБД и дополнительные компоненты ядра
    (опции). Они необходимы для хранения, поиска, извлечения, обработки и
    администрирования данных;
  • инструментальные средства разработки приложений. Это, в первую
    очередь, набор средств разработчика Developer/2000, а также
    прекомпиляторы с языков 3GL и библиотека CALL-интерфейса;
  • средства автоматизации проектирования и разработки (CASE-средства) -
    Designer/2000;
  • средства для конечных пользователей. Это набор средств
    Descoverer/2000, офисная система Oracle Office, средства хранения и
    обработки текстов Text Server (c Context и CoAutor);
  • средства для анализа данных и создания OLAP (online analyse processing)
    приложений - Express - продукты;
  • средства для обеспечения работы продуктов Oracle в компьютерной сети.
    Это SQL*Net с драйверами различных сетевых протоколов, средства
    управления сетью, кодирования данных, преобразования протоколов;
  • средства для взаимодействия с пакетами других фирм. Это шлюзы по
    данным (Transparent Gateway) к различным СУБД и процедурные шлюзы;
    ODBC драйвер, Oracle Objects for OLE, универсальный пакет связи Oracle Glue;
  • продукты для рабочих групп - Workgroup/2000. К этой группе относится
    нерасширяемое ядро Oracle для персональных компьютеров,
    однопользовательский персональный Oracle, средства разработки небольших
    приложений-Oracle Power Objects. Продукты для рабочих групп отличаются
    компактностью, простотой установки и использования, а так же низкими
    ценами;
  • готовые прикладные системы - Oracle Applications. Среди них наиболее
    известными являются: Oracle Financial - финансовые, Oracle Manufacturing -
    управление производством, Oracle Human Resources - кадры, бухгалтерия;
  • новые направления. К этой группе можно отнести продукты для работы с
    мультимедиа (Media Server, Media Net, Media Objects), средства для работы с
    БД по медленным и ненадежным сетям (радиомодемы, телефоны, сотовая
    связь) - Oracle Mobile Agents, средства для работы с БД по Internet (WWW
    Viewer и WWW сервер).


    Коллективная разработка(Enterprise Enabled)

  • Менеджер общей библиотеки объектов
  • Центральный репозиторий дизайна приложений
  • Интерфейсы к широкому спектру продуктов других фирм.
    Уникальный графический подход PowerBuilder к разработке поддерживает большие коллективы
    разработчиков информационных систем при помощи менеджера общей библиотеки объектов
    (Common Object Library Manager) и центрального репозитория дизайна приложений (Central
    Application Design Repository). Менеджер библиотеки осуществляет проверку при выдаче и возврате
    (check-in/check-out) для предотвращения одновременного обновления одного объекта несколькими
    разработчиками, предоставляет возможности поиска в библиотеках, анализирует взаимосвязи, а также
    создает подробные отчеты для разработчиков по библиотекам и их компонентам. Менеджер
    библиотеки может быть расширен для интеграции с инструментами лидеров CASE-индустрии
    популярными системами контроля версий других фирм, таких как PVCS фирмы Intersolv Corporation,
    позволяя разработчикам использовать уже сделанные инвестиции в эти продукты.

    PowerBuilder также имеет центральный репозиторий дизайна приложений (Central Application Design
    Repository), который доступен всему коллективу разработчиков и позволяет им определять
    расширенные атрибуты таблиц и столбцов, такие как заголовки и метки. Центральный репозиторий
    дизайна позволяет стандартизировать и ускорять процесс разработки приложений.

    PowerBuilder - открытая среда разработки, включающая интерфейсы с лучшими представителями
    технологии программного обеспечения в среде клиент/сервер. Средства CASE, системы контроля
    версий, инструменты соединения узлов, мультимедиа, обработка образов, перьевой ввод, DCE и
    многие другие технологии полностью интегрируются при помощи открытого интерфейса API к
    библиотекам, разработанным компанией Powersoft.


    Компиляторы

    Продукт Informix-NewEra содержит два типа компиляторов и, соответственно, два способа сборки
    приложений:

  • Модули NewEra -> файлы с интерпретируемым кодом -> объединенный
    файл с интерпретируемым кодом
  • Модули NewEra -> модули на языке С -> объектные модули ->
    выполняемая программа
    В ходе разработки и отладки приложений используется первый способ, поскольку компиляция в
    интерпретируемый код выполняется быстрее и с ним может работать отладчик. Для изготовления
    производственных версий применяется второй способ.


    Компоненты диаграммы ERwin и основные виды представлений диаграммы

    Диаграмма ERwin строится из трех основных блоков - сущностей, атрибутов и связей. Если
    рассматривать диаграмму как графическое представление правил предметной области, то сущности
    являются существительными, а связи - глаголами.

    Выбор между логическим и физическим уровнем отображения осуществляется через линейку
    инструментов или меню. Внутри каждого из этих уровней есть следующие режимы отображения:

  • Режим "сущности" - внутри прямоугольников отображается имя
    сущности (для логической модели) или имя таблицы (для физического
    представления модели); служит для удобства обзора большой диаграммы или
    размещения прямоугольников сущностей на диаграмме.
  • Режим "определение сущности" служит для презентации диаграммы другим
    людям.
  • Режим "атрибуты". При переходе от предметной области к модели
    требуется вводить информацию о том, что составляет сущность. Эта
    информация вводится путем задания атрибутов (на физическом уровне -
    колонок таблиц). В этом режиме прямоугольник-сущность делится линией на
    две части - в верхней части отображаются атрибуты (колонки), составляющие
    первичный ключ, а в нижней - остальные атрибуты. Этот режим является
    основным при проектировании на логическом и физическом уровнях.
  • Режим "первичные ключи" - внутри прямоугольников - сущностей
    показываются только атрибуты/колонки, составляющие первичный ключ.
  • Режим "пиктограммы". Для презентационных целей каждой таблице может
    быть поставлена в соответствие пиктограмма (bitmap).
  • Режим "показ глагольной фразы". На дугах связей показываются
    глагольные фразы, связывающие сущности (для логического уровня) или
    имена внешних ключей (для физического уровня).
    Диаграмма может занимать более чем один экран и более чем один лист при печати. Для обзора
    модели предусмотрены, кроме прокруток экрана, режимы уменьшения/увеличения изображения,
    отображение всей модели, отображение выделенной части модели.


    Концепции INTERNET и INTRANET для создания корпоративных приложений в архитектуре клиент- сервер

    Инструментарий компании Borland

    Александр Сергеев, Демоцентр клиент-серверных технологий

    Концепции построения и реализации информационных систем, ориентированных на анализ данных

    А. Сахаров, Oracle

    Сегодня, практически в любой организации сложилась хорошо всем знакомая ситуация: - информация вроде бы, где-то и есть, её даже слишком много, но она неструктурированна, несогласованна, разрознена, не всегда достоверна, её практически невозможно найти и получить.

    Именно на разрешение этого противоречия - отсутствие информации при наличии и даже избытке и нацелена концепция Хранилищ Данных (Data Warehouse). В основе концепции Хранилищ Данных лежат две основополагающие идеи:
  • Интеграция ранее разъединенных детализированных данных:

    -исторические архивы,

    -данные из традиционных СОД,

    -данные из внешних источников в едином Хранилище Данных, их согласование и возможно агрегация.

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

    Автором концепции Хранилищ Данных (Data Warehouse) является Б.Инмон, который определил Хранилища Данных, как: "предметно ориентированные, интегрированные, неизменчивые, поддерживающие хронологию наборы данных, организованные для целей поддержки управления", призванные выступать в роли "единого и единственного источника истины" обеспечивающего менеджеров и аналитиков достоверной информацией необходимой для оперативного анализа и принятия решений.

    Наиболее распространённой на сегодня ошибкой, является попытка найти в концепции Хранилищ Данных некий законченный рецепт реализации информационной аналитической системы. Тем более, это не некий готовый программный продукт или некое готовое универсальное решение. Цель концепции Хранилищ Данных - прояснить отличия в характеристиках данных в операционных и аналитических системах, определить требования к данным помещаемым в целевую БД Хранилища Данных, определить общие принципы и этапы её построения, основные источники данных, дать рекомендации по решению потенциальных проблем возникающих при их выгрузке, очистке, согласовании, транспортировке и загрузке в целевую БД.

    Предметом концепции Хранилищ Данных являются сами данные.
    После того как традиционная СОД реализована и начинает функционировать, она становится ровно таким же самостоятельным объектом реального мира, как и любое, производственный процесс. А данные, которые являются одним из конечных продуктов такого производства, обладают ровно теми же свойствами и характеристиками, что и любой промышленный продукт: сроком годности, местом складирования (хранения), совместимостью с данными из других производств (СОД), рыночной стоимостью, транспортабельностью, комплектностью, ремонтопригодностью и т.д.

    И именно с этой точки зрения рассматриваются данные в Хранилищах Данных. То есть, её предметом являются не способы описания и отображения объектов предметной области, а собственно данные, как самостоятельный объект предметной области, порожденной в результате функционирования ранее созданных информационной систем.

    Для правильного понимания данной концепции необходимо понимание следующих принципиальных моментов:
  • Концепция Хранилищ Данных - это не концепция анализа данных, скорее это концепция подготовки данных для анализа.
  • Концепция Хранилищ Данных не предопределяет архитектуру целевой аналитической системы. Она говорит о том, какие процессы должны выполняться в системе, но не о том, где конкретно и как эти процессы должны выполняться.
  • Концепция Хранилищ Данных предполагает не просто единый логический взгляд данные организации (как иногда это трактуется). Она предполагает реализацию единого интегрированного источника данных.

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

    Очевидно, что для определённых классов приложений, это решение вполне корректно. Но следует заранее понимать все ограничения им накладываемые.

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

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

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

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

    Аналитические системы всегда предъявляли существенно более высокие, чем традиционные СОД, требования к аппаратному обеспечению и программному обеспечению. И, приступая к построению аналитической системы, следует понимать, что её реализация практически невозможна без разрешения таких вопросов как:
  • Неоднородность программной среды.
  • Распределенность.
  • Защиты данных от несанкционированного доступа.
  • Построения и ведения многоуровневых справочников метаданных.
  • Эффективное хранение и обработка очень больших объемов данных.

    Основополагающим отличием Хранилищ Данных от традиционных СОД является то, что они практически никогда не создаются на пустом месте. И практически всегда, конечное решение будет разнородным (с точки зрения производителей программных средств, принципов построения, операционных систем) .

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

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

    Хранилища Данных уже по своей природе являются распределенным решением.

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

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

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

    Наличие развитых средства защиты и ограничения прав доступа.

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


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

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

    В таких системах, часто оказывается недостаточно защиты обеспечиваемой в стандартных конфигурациях коммерческих СУБД (обычно уровень защиты по классу "C2 Orange Book".) Региональный менеджер должен видеть только те данные, которые относятся к его региону, а менеджер подразделения не должен видеть данные, относящиеся ко всей фирме. Но, для повышения эффективности доступа к данным, в целевой БД Хранилища Данных, все эти данные, как правило, хранятся в виде единой фактологической таблицы. Следствием этого, является то, что средства реализации должны поддерживать ограничения доступа не только на уровне отдельных таблиц и их колонок, но и отдельных строк в таблице (класс "B1 Orange Book").

    Не менее остро стоят и вопросы авторизации и идентификации пользователей, защиты данных в местах их преобразования и согласования, в процесс их передачи по сети (шифрование паролей, текстов запросов, данных).

    В заключение хотелось бы остановиться на двух моментах. Во первых, не следует искать в концепции Хранилищ Данных что-то совершенно принципиально новое, о чём не говорилось и не писалось ранее и чему нельзя найти аналогий в прошлом. Её реальное значение состоит в том, что Концепция Хранилищ Данных, составляет: "часть ответа со стороны информационных технологий на вопрос: "Что мы делаем дальше?". И подобно многим новациям в технологиях, этот термин используется для того, чтобы описать обезоруживающую по своей простоте концепцию, которая имеет потенциал развиться со временем во что-то более сложное и значительное ".


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

    И во вторых. Несмотря на то, что стоимость аналитических систем даже сегодня остается достаточно высокой, а методологии и технологии реализации таких систем находятся ещё в стадии их становления, уже сегодня, экономический эффект обеспечиваемый ими существенно превышает эффект от традиционных оперативных систем.

    Эффект от правильной организации, стратегического и оперативного планирования развития бизнеса трудно заранее оценить в цифрах, но очевидно, что он в десятки и даже сотни раз может превзойти затраты на реализацию таких систем. Однако не следует и заблуждаться. Эффект обеспечивает не сама система, а люди с ней работающие. Поэтому не совсем корректны декларации типа:система Хранилищ Данных будет помогать менеджеру принимать правильные решения". Cовременные аналитические системы не являются системами искусственного интеллекта и они не могут ни помочь, ни помешать в принятии решения. Их цель своевременно обеспечить менеджера всей информацией необходимой для принятия решения. А какая информация будет запрошена и какое решение будет принято на её основе, зависит только от конкретного человека.

    []
    []
    []

    Концептуальное описание предметной области

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

    В качестве стандартного средства информационного моделирования в современных CASE-
    методологиях используется в том или ином виде аппарат моделей "сущность-связь" или ER-
    моделей (Entity Relationship Model). Этот формализм позволяет представлять информационные
    потребности в виде, наглядном и удобном для восприятия, что делает их хорошим средством
    коммуникации между проектировщиками и пользователями в процессе уточнения постановки
    задач.

    Теоретической основой этого подхода является известная модель "сущность-связь", введенная
    Ченом в 1976 году и получившая широкое развитие и распространение в
    качестве средств концептуального проектирования баз данных. В основе модели Чена лежит
    представление о том, что предметная область состоит из отдельных объектов, находящихся друг с
    другом в определенных связях. Объекты описываются различными параметрами или атрибутами;
    однотипные объекты описываются одним и тем же набором параметров и объединяются в
    множества или классы; такие классы называются сущностями. Конкретные объекты, составляющие
    класс , называются экземплярами соответствующей сущности. Между сущностями
    специфицируются взаимосвязи различного вида: один к одному, один ко многим и др.

    В CASE-методологии фирмы ORACLE используется некоторый специальный вид модели Чена,
    близкий к бинарной ER-модели. В этом случае взаимосвязи могут быть определены только между
    двумя сущностями. Кроме того, для взаимосвязей нельзя задавать атрибутов.

    Для наглядного представления общей структуры предметной области все такие спецификации

    изображаются в графическом виде - в виде ER-диаграммы. На этой диаграмме объекты
    изображаются прямоугольниками, а связи - линиями, соединяющими соответствующие
    прямоугольники. Задание типа связи ("один к одному", "многие к одному" и т.д.) означает
    введение некоторого семантического ограничения. На диаграмме для каждого типа взаимосвязи
    используется свое графическое изображение: если любой экземпляр сущности A может быть связан
    с несколькими экземплярами сущности B, то со стороны прямоугольника-сущности A линия,
    выражающая взаимосвязь, дополняется специальным символом (рис. 9). Кроме того, для связи
    можно указать, является ли она обязательной для входящих в нее сущностей. Если любой
    экземпляр сущности A обязательно должен быть связан с каким-либо экземпляром сущности B, то
    прилегающая к прямоугольнику "A" половина линии - сплошная, в противном случае она -
    пунктирная.

    Концептуальное описание предметной области

    Конфигурации программно-технических средств

    Программно-технические средства для реализации распределенных клиент-серверных
    приложений, поддерживаемых продуктами Software AG, могут включать в себя следующие
    компоненты:


  • главные ЭВМ (ГЭВМ) верхнего уровня системы (типа IBM mainframe, UNIX-
    суперсерверы);
  • серверные ЭВМ (CЭВМ) среднего и малого классов (UNIX-серверы, OS/2,
    Windows NT);
  • блоковые (типа IBM 3270) и символьные (типа VT 100 или ASCII)
    терминалы;
  • низкопроизводительные ПЭВМ (типа IBM PC/XT/286/386-MS DOS);
  • высокопроизводительные ПЭВМ (типа IBM PC/486/Pentium-MS Windows,
    OS/2);
  • опорную сеть и протоколы (FDDI/Ethernet и/или TCP/IP, SPX/IPX и др.);
  • программные продукты других фирм для доступа к базам данных,
    обработки и коммуникации, поддерживающие общепризнанные протоколы
    межпрограммного взаимодействия и связные протоколы (ORACLE, INFORMIX,
    SYBASE, NOVELL, IBM, MICROSOFT и др.).


    Корпоративные сети и базы данных

    Виктор Олифер, Центр Информационных Технологий
    Эпитет "корпоративный" часто используется для характеристики продуктов вычислительных
    систем. Корпоративными могут быть названы почти все типы элементов вычислительной системы,
    от концентраторов и маршрутизаторов до серверов и операционных систем - разве что сетевые
    адаптеры редко удостаиваются такой чести. Эта характеристика также применяется и к системам
    управления базами данных : Oracle, Informix, Sybase, DB2 - все это примеры СУБД, которые часто
    называются корпоративными. Среди специалистов и производителей существуют различные
    толкования этого термина (равно, как и любого другого), поэтому иногда бывает трудно понять,
    почему производитель называет свое детище корпоративным, а продукцию конкурентов - нет.
    Интуитивно с прилагательным "корпоративный" связывается образ чего-то крупного, мощного,
    производительного и надежного. Тем не менее, хочется иметь более твердую почву под ногами, и
    основания для этого есть. Имеется несколько устоявшихся признаков корпоративности, и их
    можно применять универсально, как к аппаратуре, так и к программным продуктам, в том числе и
    базам данных. Наличие этих признаков гарантирует хорошую работу продуктов в корпоративной
    сети. Эти признаки тесно связаны с особенностями и спецификой корпоративных сетей, поэтому
    для четкого формулирования требований к корпоративным базам данных необходимо ясное
    понимание особенностей корпоративных сетей.

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

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

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

    Аналогичным образом некоторые СУБД поступают и с коммуникационными функциями
    операционных систем. Примерами здесь могут служить такие компоненты баз данных как Oracle
    SQL*Net или Ingres Net, в которых реализованы популярные транспортные протоколы. Понятно,
    что дублирование транспортных функций ОС дополнительными компонентами СУБД происходит
    не от хорошей жизни, а от ограниченности сетевых возможностей универсальных операционных
    систем: отсутствия тех или иных протоколов или низкоскоростной их реализации.

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

    Очевидно, что использование единой транспортной системы для всех приложений вычислительной
    системы облегчило бы жизнь и пользователям, и администраторам. И в этом направлении
    корпоративные сети быстро развиваются, позволяя своим пользователям отказаться от


    транспортных услуг отдельных, хотя и очень важных приложений и использовать общие средства.

    Итак, что же такое корпоративные сети? В англоязычной литературе этот вид сетей чаще
    называется "enterprise-wide networks" (дословно - сеть масштаба предприятия), а в нашей стране
    прижился другой термин иностранного происхождения - корпоративные сети, что, на наш взгляд,
    больше соответствует самой сути таких сетей. Термин "корпоративная" отражает с одной стороны
    величину сети, так как корпорация - это крупное, большое предприятие. С другой стороны, этот
    термин несет в себе смысл объединения, то есть корпоративная сеть - это сеть, получившаяся в
    результате объединения нескольких, как правило, разнородных сетей. Кроме того, дух
    корпоративности - это дух некоего единства, общности, и в этом смысле корпоративные сети - это
    сети, в которых неоднородные компоненты живут в счастливом согласии.

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

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


    приложений.

    Превышение количественными изменениями некоторой критической массы и породило новое
    качество - корпоративную сеть.

    Термин "корпоративность" связывает описанный вид сетей с принадлежностью их одному
    предприятию, причем крупному. Этот признак не является главным, а просто отражает тот факт,
    что крупномасштабная, гетерогенная и хорошо интегрированная сеть чаще всего получается в
    результате усилий предприятия при объединении своих отдельных сетей в единую
    информационную систему. Поэтому, если сеть обладает отмеченными выше особенностями, но не
    принадлежит одной корпорации, то ее все равно можно назвать корпоративной.

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


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

    Сети отделов или рабочих групп используются группой людей, объединенных решением
    общей задачи, такой, например, как бухгалтерский учет или маркетинг. Главной целью сетей
    отделов является разделение ресурсов, таких как приложения, данные, лазерные принтеры и,
    возможно, низкоскоростные модемы. Обычно сети отделов имеют один или два файловых сервера
    и не более чем 30 пользователей. Сети отделов, как правило, не разделяются мостами на подсети


    (сегменты). Даже когда сети отделов соединены в корпоративную сеть, большая часть трафика
    локализуется в сети отдела, потому что именно в ней выполняется большая часть работы. Как
    правило, пользователи в 80% случаев обращаются к локальным ресурсам, а в 20% случаев - к
    удаленным ресурсам.

    Сети рабочих групп и отделов обычно создаются на основе какой либо одной сетевой технологии -
    Ethernet, Token Ring, или, если в рабочей группе происходит обмен большими объемами
    информации (например, мультимедийными файлами), то высокоскоростные протоколы, такие как
    FDDI, Fast Ethernet или 100VG-AnyLAN.

    Такая сеть обычно использует одну или максимум две сетевые ОС. Чаще всего это сеть с
    выделенным сервером NetWare 3.x или Windows NT, или же одноранговая сеть, например сеть
    Windows for Workgroups. Все пользователи рабочей группы или отдела пользуются СУБД одного
    типа, чаще всего настольными СУБД типа dBase, Paradox или FoxPro, пользующимися файловым
    сервером для хранения разделяемых данных.

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

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

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

    Итак, следующим шагом в эволюции сетей является объединение локальных сетей нескольких
    отделов в единую сеть здания или группы зданий. Такие сети называют сетями кампусов. Сети
    кампусов могут простираться на несколько километров, но при этом глобальные соединения не
    требуются. Сети кампусов имеют позвоночник (backbone) или главную сеть, и подсети,
    подобные ребрам. Для повышения производительности предприятия иногда используют
    маршрутизаторы, однако чаще подсети присоединяются к позвоночнику с помощью мостов или
    быстродействующих многопортовых мостов нового поколения - коммутирующих концентраторов
    (switching hubs).

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

    Именно на уровне сети кампуса начинаются проблемы интеграции.


    В общем случае, отделы уже
    выбрали для себя компьютеры и приложения (а, следовательно, и сеть), которые подходят им
    наилучшим образом. Однако, то, что подходит отделу продаж, может не подойти, например,
    отделу разработчиков. Типы компьютеров, сетевых операционных систем, сетевого аппаратного
    обеспечения могут отличаться в каждом отделе. Например, инженерный отдел может использовать
    операционную систему UNIX и сетевое оборудование Ethernet, отдел продаж может использовать
    операционные среды DOS/Novell и оборудование Token Ring. Очень часто сеть кампуса соединяет
    разнородные компьютерные системы, в то время как сети отделов используют однотипные
    компьютеры. Часто сети кампусов оказываются соединенными случайным образом. Например, два
    отдела, которые работают вместе, могут соединить свои компьютерные системы, а уже затем к ним
    захочет присоединиться третий отдел. Отсюда вытекают сложности управления сетями кампусов.
    Администраторы должны быть в этом случае более квалифицированными, их нужно специально
    обучать. В случае сбоев и отказов администратору уже недостаточно проверить надежность
    соединения разъема. Нужны более изощренные средства оперативного управления сетью.

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

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

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


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

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

    Важное значение приобретает время реакции приложений в корпоративной сети - при динамичном
    рынке для успешной борьбы с конкурентами решения необходимо принимать в реальном
    масштабе времени, что требует соответствующей организации корпоративной сети и ее
    приложений, в том числе СУБД, способной оперативно отрабатывать запросы к данным
    (поддержка режима On Line Transaction Processing, OLTP). В то же время в большой
    корпоративной сети обеспечить хорошее время реакции особенно сложно - этому мешает высокая
    интенсивность потока запросов, создаваемых сотнями и тысячами сотрудников корпорации,
    необходимость производить поиск данных в базах колоссальных размеров, невысокая скорость
    глобальных линий связи между отделениями корпорации, замедление скорости взаимодействия в
    шлюзах, согласующих неоднородные компоненты различных подсетей. В корпоративных системах
    предыдущих поколений с таким положением вещей мирились - особенно крупные базы данных
    хранились централизованно на мейнфреймах и обеспечивали доступ к данным в пакетном режиме,
    не дающем быстрой реакции на запрос. Теперь же требования работы в реальном времени стали
    для корпораций насущной необходимостью и одним из основных требований, предъявляемых к


    корпоративным сетям и корпоративным приложениям.

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


  • масштабируемость, то есть способность одинаково хорошо работать в
    большом диапазоне различных количественных характеристик сети,
  • совместимость с другими продуктами, то есть способность работать в
    сложной гетерогенной среде интерсети в режиме plug-and-play.

    Очевидно, в корпоративной сети могут использоваться не только продукты класса
    корпоративных, но и продукты уровня отделов и рабочих групп. Корпоративные продукты
    используются на магистрали сети, там, где они организуют разделение ресурсов между большим
    количеством пользователей, в пределе - между всеми пользователями корпорации. Продукты же
    рабочих групп предоставляют свои ресурсы в основном только членам своей рабочей группы,
    поэтому их производительность, надежность и другие свойства могут быть гораздо более
    скромными, чем у корпоративных продуктов. Поэтому в одной и той же сети успешно справляются
    со своими обязанностями и СУБД Access компании Micosoft, работающая на 486-х персоналках и
    СУБД Oracle, работающая на суперсерверах компаний Digital, Hewlett-Packard или Tricord. Access
    обеспечивает, например, разделение данных только для 12 сотрудников небольшого
    вспомогательного отдела, а Oracle предоставляет доступ к жизненно важной для корпорации
    информации (о выпускаемых ею продуктах, объемах продаж, производственных планах и т.п.) для
    всех сотрудников корпорации, в том и для упомянутых сотрудников вспомогательного отдела.
    Oracle может выполнить эту задачу, так как является корпоративным продуктом, а Access с ней бы
    не справился, так как это продукт уровня рабочей группы, он и не разрабатывался для поддержки
    большого числа пользователей и больших массивов данных. Соответственно возможностям
    различаются и цены корпоративных продуктов и продуктов рабочих групп.

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

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

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


    Но за эти
    удобства приходится расплачиваться решением проблем распределенности, репликации и
    синхронизации.

    В идеале сетевая справочная информация должна быть реализована в виде единой базы данных, а
    не представлять собой набор баз данных, специализирующихся на хранении информации того или
    иного вида, как это часто бывает в реальных операционных системах. Например, в Windows NT
    имеется по крайней мере пять различных типов справочных баз данных. Главный справочник
    домена (NT Domain Directory Service) хранит информацию о пользователях, которая используется
    при организации их логического входа в сеть. Данные о тех же пользователях могут содержаться и
    в другом справочнике, используемом электронной почтой Microsoft Mail. Еще три базы данных
    поддерживают разрешение низкоуровневых адресов: WINS - устанавливает соответствие Netbios-
    имен IP-адресам, справочник DNS - сервер имен домена - оказывается полезным при подключении
    NT-сети к Internet, и наконец, справочник протокола DHCP используется для автоматического
    назначения IP-адресов компьютерам сети. Ближе к идеалу находятся справочные службы,
    поставляемые фирмой Banyan (продукт Streettalk III) и фирмой Novell (NetWare Directory Services),
    предлагающие единый справочник для всех сетевых приложений.

    Справочная служба Streettalk уже давно выпускается компанией Banyan и является наиболее
    отработанным продуктом этого типа. Многие третьи фирмы купили у компании Banyan лицензию
    и используют службу Streettalk в своих системах.

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


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

    Другим характерным примером специфики корпоративных сетей является подход к построению и
    поддержке распределенных приложений.

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

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


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

    Сервер приложений должен базироваться на мощной аппаратной платформе (мультипроцессорные
    системы, часто на базе RISC-процессоров, специализированные кластерные архитектуры). ОС
    сервера приложений должна обеспечивать высокую производительность вычислений, а значит
    поддерживать многонитевую обработку, вытесняющую многозадачность, мультипроцессирование,
    виртуальную память и наиболее популярные прикладные среды (UNIX, Windows, MS-DOS, OS/2).
    В этом отношении сетевую ОС NetWare трудно отнести к корпоративным продуктам, так как в ней
    отсутствуют почти все требования, предъявляемые к серверу приложений. В то же время хорошая
    поддержка универсальных приложений в Windows NT собственно и позволяет ей претендовать на
    место в мире корпоративных продуктов.

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

    Поэтому корпоративные приложения эффективнее строить с применением асинхронной связи


    между отдельными частями. В этом случае необходимо иметь дополнительную службу
    (относящуюся к так называемому классу middleware), которая принимала бы запросы от
    клиентской части приложения, вела бы очередь таких запросов (желательно на диске для
    повышения отказоустойчивости) и планировала бы загрузку сервера. Асинхронный способ
    взаимодействия предъявляет менее жесткие требования к устойчивости физической связи между
    клиентом и сервером, что особенно важно для коммутируемых глобальных каналов, которые в
    общем случае всегда могут разделять части приложений в корпоративной сети. Примерами
    продуктов, которые поддерживают асинхронную передачу сообщений между клиентами и
    серверами, являются системы DECmessage Q от Digital Equipment, Message Express от Momentum
    Software и Copernicus от New Paradigm Software.

    В корпоративных сетях для связи клиентских и серверных частей приложений кроме используются
    и ряд других средств, относящихся к классу middleware, а не только упомянутые средства
    асинхронной обработки сообщений (message-oriented midleware, MOM). Широко используемые в
    сетевых операционных системах и сетевых утилитах средства удаленного вызова процедур RPC
    также относятся к классу middleware. Кроме того, в этот класс входят мониторы обработки
    транзакций (transaction processing monitors, TP), осуществляющие прием потока запросов
    транзакций от клиентов и осуществляют балансировку этих потоков при передаче их на серверы
    баз данных, постановку их в очередь, архивацию и восстановление после сбоев. Перспективным,
    но пока еще не нашедшими практического воплощения являются средства брокеров запроса
    объектов (object request broker, ORB), которые работают подобно средствам асинхронной
    обработки запросов, но только с привлечением концепции объектно-ориентированной
    технологии.

    Использование средств класса middleware в корпоративных сетях связано с необходимостью
    упорядочить хаотический поток запросов от огромного числа клиентов к большому количеству
    серверов, создать некоторые регулирующие эти потоки механизмы, подобно регулировщикам


    движения на оживленных городских магистралях.

    Важную роль в обеспечении необходимых свойств корпоративной сети играет структура
    транспортной системы и ее согласованность.

    Транспортная система корпоративной сети должна обеспечивать:


  • передачу пакетов через разнородные сети с совершенно различными
    принципами организации транспортных операций,
  • многоуровневое иерархическое построение (наличие магистрали сети, к
    которой присоединяются транспортные артерии нижних уровней),
  • хорошую структуризацию за счет разделения сети на подсети небольшого
    размера с регулярными связями,
  • поддержку быстрых протоколов, таких как FDDI, Fast Ethernet и 100VG-
    AnyLAN, для устранения узких мест.

    Объединение транспортных потоков отдельных сетей в корпоративной сети происходит за
    счет использования общего для всех сетей магистрального протокола сетевого уровня модели OSI,
    который правильнее было бы назвать межсетевым.

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

    К сожалению, существует большого количество протоколов сетевого уровня, равно как и
    протоколов канального уровня. Все они решают одну задачу, но несколько разными способами,
    поэтому сетевым интеграторам и администраторам приходится в больших сетях иметь дело
    одновременно с несколькими сетевыми протоколами. Очень популярными протоколами сетевого
    уровня, использующимся для объединения сетей, входящих в корпоративную сеть, является
    протоколы IP и Novell IPX.

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


    этих сетей действуют свои правила внутренней доставки пакетов, а их совместная работа
    становится возможной благодаря наличию общего протокола сетевого уровня.

    В последнее время роль объединяющего протокола сетевого уровня все чаще выполняет сетевой
    протокол IP, ведущий свое происхождение от сети Internet и операционной системы Unix. Для
    этого протокола существуют стандарты его использования над всеми основными протоколами
    канального уровня локальных сетей, таких как Ethernet, Token Ring, FDDI, Fast Ethernet и 100VG-
    AnyLAN, а также над протоколами глобальных сетей - X.25, frame relay, PPP. Уже имеется
    спецификация для использования IP над протоколами таких перспективных сетей как АТМ - так
    называемая спецификацией Classical IP. Важным достоинством IP является его высокая
    эффективность при работе на относительно низкоскоростных глобальных линиях связей.
    Протокол IPX фирмы Novell был изначально разработан для объединения небольшого числа
    локальных сетей, поэтому он расточительно использует полосу пропускания линий связи и не так
    хорошо работает на магистралях корпоративных сетей, как IP, хотя Novell в последнее время
    предпринимает немало усилий для улучшения своего стека коммуникационных протоколов.

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

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


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

    Целью вычислительной сети является предоставление пользователям доступа ко всем ресурсам
    сети. Но не всем пользователям нужен постоянный доступ ко всем ресурсам. В большинстве
    случаев им нужен доступ к ресурсам сети их отдела, и только изредка - доступ к удаленным
    ресурсам. Поэтому сеть предприятия часто реализуется как совокупность подсетей. Большинство
    сетей разрабатывается на основе структуры с позвоночником, к которому через мосты и
    маршрутизаторы присоединяются подсети. Эти подсети обслуживают различные отделы. Подсети
    могут делиться и далее на сегменты для обслуживания рабочих групп.

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


  • Сегментация уменьшает общий сетевой трафик. При достижении
    трафиком границы 30%-40% от полной пропускной способности, пользователи
    сети Ethernet начинают чувствовать значительное уменьшение
    производительности сети из-за постоянных коллизий. В сетях Token Ring также
    при достижении трафиком границы 20%-30% от предельной пропускной
    способности, конкуренция за доступ к кольцу начинает приводить к заметным
    задержкам.
  • Пользователи взаимодействуют в основном с пользователями и ресурсами
    своего отдела. Здесь применимо правило 80/20 - около 80% трафика является
    локальным, а 20% идет в удаленные сегменты. Путем сегментации сети на
    подсети отделов можно значительно уменьшить трафик, проходящий через
    всю сеть, и тем самым повысить производительность сети.
  • Подсети увеличивают гибкость сети. При построении сети как
    совокупности подсетей каждая подсеть может быть адаптирована к
    специфическим потребностям рабочей группы или отдела. При этом эти
    подсети могут взаимодействовать.
  • Подсети повышают безопасность данных. Помещая пользователей


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

    Сети должны проектироваться на двух уровнях: физическом и логическом. Логическое
    проектирование определяет места расположения ресурсов, приложений и способы доступа
    пользователей к ресурсам. Физическое проектирование определяет точное задание типов устройств
    (марку и модель), мест прокладки кабеля, типов глобальных сервисов (протокол, тип передающей
    среды, типы модемов и т.д.). Соотношение между логическим и физическим уровнями
    проектирования в некотором смысле аналогично соотношению между функциональной и
    принципиальной электрическими схемами. Например, использование повторителя создает в сетях
    стандартов 10Base-T, 10Base-F и Token Ring физические сегменты - отрезки кабеля, соединяющие
    по схеме "точка-точка" станции. Однако логически эти отрезки представляют по прежнему один
    сегмент, моноканал в случае Ethernet'а и логическое кольцо для сетей Token Ring. Применение же
    мостов, маршрутизаторов и шлюзов приводит к появлению логических сегментов, локализующих
    трафик внутри себя.

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


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

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

    Особую важность приобретают для корпоративной сети вопросы безопасности данных. С
    одной стороны, в крупномасштабной сети объективно существует больше возможностей для
    несанкционированного доступа - из-за децентрализации данных и большой распределенности
    "законных" точек доступа, из-за большого числа пользователей, благонадежность которых трудно
    установить, а также из-за большого числа возможных точек несанкционированного подключения
    к сети. С другой стороны, корпоративные бизнес-приложения работают с данными, которые
    имеют жизненно важное значение для успешной работы корпорации в целом. И для защиты таких
    данных в корпоративных сетях применяется весь спектр имеющихся средств защиты -
    избирательные или мандатные права доступа, сложные процедуры аутентификации пользователей,
    программная и аппаратная шифрация, локализация трафика и т.п.

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


    аппаратуры и данных на всех уровнях: кабельных связей, источников питания, процессоров,
    компьютеров, маршрутизаторов, репликация баз данных, кластеризация вычислений.

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

    Создать крупномасштабную гетерогенную среду для проверки свойств корпоративности не только
    сложно, но и накладно. Поэтому существуют специальные лаборатории, которые занимаются
    тестированием и сертификацией продуктов на предмет пригодности их для работы в
    корпоративной сети. В частности, такие услуги и потребителям и производителям оказывает
    американская фирма The Tolly Group, которая с помощью специального оборудования может
    создавать сложную гетерогенную среду, соответствующую требованиям заказчика, и испытывать в
    ней новое оборудование или программную систему. Клиентами The Tolly Group являются и
    компании-призводители, заинтересованные в получении лого "Enterprise Ready", причем не только
    новички, завоевывающие рынок, но и такие гранды как Cisco, IBM, Motorola-Codex, 3Com,
    Wellfleet и многие другие.

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

    []
    []
    []

    Краткое описание методики и состава работ по предпроектному обследованию

    Предпроектное обследование предприятия предусматривает изучение и описание:
  • организационной структуры предприятия;
  • технологических процессов предприятия;
  • системы документооборота предприятия;
  • связей предприятия с внешними организациями.
    Созданная модель предприятия анализируется по следующим направлениям:
  • распределение функций между подразделениями;
  • выявление дублирования функций;
  • выявление перегруженности или недогруженности отдельных элементов
    модели;
  • выявление скрытых ресурсов предприятия.
    В основу методики обследования положен принцип "черного ящика": вначале в роли "черного
    ящика" выступает предприятие в целом, затем каждый из его отделов, затем - отдельные
    процессы внутри отдела (например, заказ товаров) и т.д.

    Обследование предприятия проводится "сверху вниз":
  • исследование целей и общей организационной структуры предприятия и
    описание его связей с внешними организациями;
  • изучение ответственности, функций и обязанностей каждого отдела;
  • изучение документооборота каждого отдела;
  • изучение связей с другими подразделениями предприятия;
  • изучение внешних связей каждого отдела.
    В результате обследования вырабатываются:
  • Рекомендации по реинжинирингу предприятия (в данном случае употребляется второе
    значение слова реинжиниринг- реструктуризация предприятия, в отличие от значения
    обратное проектирование применительно к CASE-средствам), вплоть до комплекта служебных
    инструкций:
    Краткое описание методики и состава работ по предпроектному обследованию

    Краткое описание методики и состава работ по предпроектному обследованию

  • Проект базы данных корпоративной информационной системы предприятия:

    Краткое описание методики и состава работ по предпроектному обследованию

    Краткое описание методики и состава работ по предпроектному обследованию
    Краткое описание методики и состава работ по предпроектному обследованию
  • Конфигурация вычислительной сети:
    Краткое описание методики и состава работ по предпроектному обследованию
  • Предложения по набору программно-технических средств:
  • Операционные системы:
  • Семейство сетевых ОС корпорации Novell основано на
    концепции интегрированной вычислительной архитектуры (NICA - Novell
    Integrated Computing Architecture), которая позволяет создать открытую
    сетевую среду, интегрирующую ресурсы серверов, настольных компьютеров,
    больших и мини- ЭВМ и поддерживающую на рабочих станциях разные
    операционные системы: Windows, DOS, OS|2, UNIX, Macintosh;

  • Microsoft Windows NT характеризуется приоритетной
    многозадачностью, встроенной сетевой поддержкой, защищенностью,
    многопоточностью, поддержкой широкого спектра компьютерных платформ,
    симметричной мультипроцессорной обработки и т.д.;
  • SCO Open Server обеспечивает возможность работы до 30
    процессоров и хорошую отказоустойчивость при выполнении
    клиент/серверных приложений.
  • SCO UnixWare 2.1 основана на самой современной версии
    ядра UNIX - System V UNIX, имеет отказоустойчивую файловую систему,
    обеспечивает интеграцию с TCP/IP и NetWare рабочими средами.
  • Средства построения сетей:
  • сетевое оборудование Cabletron, Bay Networks, 3Com, Chipcom;
  • высококачественные Brand Name компьютеры фирм Compaq,
    Gateway, Tricord для серверов и рабочих станций.
  • Средства программирования:
  • Centura Team Developer - мощная среда разработки
    приложений, обеспечивающая широкие возможности масштабирования
    приложений и интеграцию корпоративных систем с Internet;
  • Centura Ranger - сервер баз данных, реализующий средства
    универсальной репликации данных;
  • Centura Web Data Publisher - система, обеспечивающая
    эффективную и безопасную передачу данных через Internet;
  • Centura Application Server - система, обеспечивающая
    возможности разделения приложенийCentura
  • Системы управления базами данных:
    SQLBase Server - новая версия сервера реляционных баз
    данных, включающая средства репликации данных;
  • семейство Sybase SQL Server - семейство серверов,
    ориентированных на задачи, связанные с быстрой обработкой транзакций в
    реальном масштабе времени, с системами принятия решений, обслуживанием
    большого числа пользователей и т.д.;
  • Microsoft SQL Server - специально разработан для систем с
    распределенной обработкой данных;
  • Informix Universal Server Engine - поддерживает
    разнообразные типы данных и предусматривает возможность расширения,
    через интерфейс АPI работает с DataBlade-модулями;
  • Oracle Server - универсальный сервер, поддерживающий
    распределенные базы данных, параллельные системы, а также включающий
    новые средства поддержки хранилищ данных.
  • Предложения по использованию и разработке прикладных программ.
    href="../../pictures/it/ofis96/133_13.gif">рис.~300K

    Компания ЭЛКО Технологии готова по заказам пользователей выполнить программные
    проекты любой степени сложности. Мы принимаем на себя ответственность за выполнение всех
    требований заказчика, за эффективное функционирование и развитие систем.

    []
    []
    []

    Критерии выбора

    Традиционно при обсуждении проблемы выбора СП (в особенности CASE-средств) большое
    внимание уделялось особенностям реализации той или иной методологии анализа предметной
    области (E-R, IDEF0, IDEF1Х, Gane/Sarson, Yordon, Barker и др.). Безусловно, богатство
    изобразительных и описательных средств дает возможность на этапах стратегического
    планирования и анализа построить наиболее полную и адекватную модель предметной области. С
    другой стороны, если говорить о конечных результатах - базах данных и приложениях, то
    обнаруживается, что часть описаний в них практически не отражается, оставаясь чисто
    декларативной (на выходе мы в любом случае получим описание БД в табличном представлении с
    минимальным набором ограничений целостности и исполнимый код приложений, большую часть
    которых составляют экранные формы, не выводимые непосредственно из моделей предметной
    области). Опытные аналитики и проектировщики всегда с большими или меньшими
    трудозатратами придут к нужному конечному результату независимо от того, какая конкретно
    методология или ее разновидность реализована в данном инструменте. Это, конечно, не означает,
    что методология не важна, напротив, отсутствие или неполнота описательных средств могут с
    самого начала значительно затруднить работу над проектом. Однако, зачастую на первом плане
    оказываются другие критерии, невыполнение которых может породить гораздо большие
    трудности.

    Может создаться впечатление, что если можно сформировать необходимую аппаратную
    платформу из компонентов различных фирм-производителей, то так же просто можно выбрать и
    скомплексировать разные инструментальные средства, каждое из которых является одним из
    мировых лидеров в своем классе. Однако в случае инструментальных средств в настоящее время, в отличие от оборудования, отсутствуют международные стандарты на основные свойства конечных продуктов (программ, баз данных и их сопряжение). Однако, поскольку составные части проекта должны быть интегрированы в единый продукт, следовательно, имеет смысл рассматривать не любые, а только сопряженные инструментальные средства, которые в принципе могут быть ориентированы - даже внутри одного класса - на разные методологии; при этом необходимо отбирать в состав комплекса СП средства, поддерживающие по крайней мере близкие методологии, если не одну и ту же.

    Исходя из перечисленных выше соображений, примем в качестве основных критериев выбора СП следующие критерии:

    Поддержка полного жизненного цикла ИС с обеспечением эволюционности ее
    развития.

    Полный жизненный цикл ИС должен поддерживаться "сквозной" технологической цепочкой
    средств разработчика, обеспечивающей решение следующих задач:


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

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

    Обеспечение целостности проекта и контроля за его состоянием.

    Данное требование означает наличие единой технологической среды создания, сопровождения и


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

    Невыполнение требования целостности в условиях разобщенности разработчиков и временной
    протяженности крупного проекта может означать утрату контроля за его состоянием.

    Независимость от программно-аппаратной платформы и СУБД.

    Требование определяется неоднородностью среды функционирования ИС. Такая независимость
    может иметь две составляющих: независимость среды разработки и независимость среды
    эксплуатации приложений. Она обеспечивается за счет наличия совместимых версий СП для


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

    Один из дополнительных факторов, который при этом следует учитывать - это способ
    взаимодействия с СУБД (прямой или через ODBC), поскольку использование ODBC может
    заметно ухудшить производительность и надежность интерфейса.

    Поддержка одновременной работы групп разработчиков.

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

    Помимо перечисленных основных критериев, предварительный анализ при выборе СП должен
    учитывать следующие аспекты:

    Возможность разработки приложений "клиент-сервер" требуемой конфигурации.

    Подразумевается сочетание наличия развитой графической среды разработки приложений
    (многооконность, разнообразие стандартных графических объектов, разнообразие используемых
    шрифтов и т.д.) с возможностью декомпозиции (partitioning) приложения на "клиентскую" часть,
    реализующую пользовательский экранный интерфейс и "серверную" часть. При этом должна
    обеспечиваться возможность перемещения отдельных компонентов приложения между "клиентом"
    и "сервером" на наиболее подходящую платформу, обеспечивающую максимальную


    эффективность функционирования приложения в целом, а также возможность использования
    сервера приложений (менеджера транзакций).

    Открытая архитектура и возможности экспорта/импорта.

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

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

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

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

    Что касается стоимости, следует учитывать возможность получения бесплатной пробной лицензии
    (trial license), стоимость лицензии на одно рабочее место СП, скидки, предоставляемые фирмой в случае приобретения большого количества лицензий, необходимость приобретения run-time версий для эксплуатации приложений и т.д.


    В то же время стоимость продукта должна рассматриваться не сама по себе, а с учетом ее соответствия возможностям продукта.

    Простота использования.

    Учитываются следующие характеристики:


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

    Обеспечение качества проектной документации.

    Это требование относится к возможностям СП анализировать и проверять описания и
    документацию на полноту и непротиворечивость, а также на соответствие принятым в данной
    методологии стандартам и правилам (включая ГОСТ, ЕСПД). В результате анализа должна
    формироваться информация, указывающая на имеющиеся противоречия или неполноту в
    проектной документации. Должна быть также обеспечена возможность создавать новые формы
    документов, определяемые пользователями.

    Использование общепринятых, стандартных нотаций и соглашений.

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

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


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


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

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

    Курсоры

    Контакт клиента с сервером SQLBase является постоянным. Сеанс контакта с базой данных
    инициируется клиентом с помощью команды CONNECT и прекращается командой
    DISCONNECT. Во время сеанса клиент выпускает одну или несколько транзакций к базе данных.
    SQLBase относится СУБД транзакционного типа, основанного на концепции курсоров (cursor) в
    отличие от технологии процессов базы данных (db-process).

    Курсор в SQLBase имеет много самых разных значений. Прежде всего, курсор - это идентификатор
    контакта пользователя с базой данных (или административного контакта с сервером SQLBase).
    Далее, с курсором связаны скомпилированные запросы на языке SQL, извлеченные из базы данных
    и подготовленные к выполнению хранимые команды и процедуры, а также полученные в
    результате выполнения запросов, команд и процедур множества результатов (result sets). Наконец,
    курсор также определяет положение (строку) в текущем result set'е, обрабатываемым клиентским
    приложением.

    В SQLBase, так же как и в Oracle, не существует специальной команды, определяющей начало
    транзакции подобно BEGIN WORK или BEGIN TRANSACTION. Транзакция автоматически
    начинается с первого запроса к базе данных, последовавшего за окончанием предыдущей
    транзакции. Для указания окончания транзакции служат команды, приведенные на рис. 4.

    Рис. 4. Команды окончания транзакции SQLBase

    Команда
    Описание
    ROLLBACK
    		Неудачное окончание транзакции. Изменения
    не записываются в базу данных. Блокировки, связанные с данной
    транзакцией сбрасываются.
    COMMIT
    		Удачное окончание транзакции. Изменения
    записываются в базу данных. Блокировки, связанные с данной
    транзакцией сбрасываются.
    SAVEPOINT
    		Удачное окончание части длительной
    транзакции. Частичные изменения записываются в базу данных. Эта
    команда используется во время длительных транзакций (например, ввода
    большого количества данных) для фиксации прохождения некоторого
    этапа. Если при дальнейшей обработке транзакции произойдет ее откат
    (ROLLBACK), все изменения, сделанные до последней команды
    SAVEPOINT, останутся в базе данных.
    <
    SQLBase поддерживает именованные и распределенные транзакции. Именованные транзакции
    позволяют объединять несколько курсоров от одного клиента в процесс, изолированный от других
    процессов в той же базе данных. Это позволяет организовать работу клиента с базой
    одновременно в нескольких режимах. Например, клиент может выделить в своем приложении 2
    именованные транзакции "Проводка" и "Баланс". При этом ошибка выполнения запроса по
    одному из курсоров транзакции "Проводка" приведет к откату только этой транзакции и не
    окажет никакого действия на курсоры транзакции "Баланс".

    Описание распределенных курсоров приведено ниже в разделе "Распределенные базы
    данных".

    Существует также разделение курсоров по объекту контакта.

    Курсоры базы данных используются для выполнения запросов к базе данных (предложений
    SELECT, INSERT, UPDATE, DELETE), а также выполнения команд конфигурирования базы
    данных (CREATE, ALTER, DROP, GRANT, REVOKE и т.д.).

    Курсоры сервера применяются для операций, непосредственно связанных с функционированием
    сервера SQLBase. К ним относятся процедуры архивирования и восстановления (BACKUP и
    RESTORE), команды создания, активизации и удаления баз данных (CREATE DATABASE, DROP
    DATABASE, INSTALL DATABASE, DEINSTALL DATABASE), а также команды, изменяющие
    параметры и режимы работы SQLBase в целом.

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

    Литература

    1. Date C.J. 1987. What is distributed database? InfoDB, 2:7

    2. Г.М.Ладыженский. Технология "клиент-сервер" и мониторы транзакций. "Открытые

    []
    []
    []


  • Г. Барон. Параллельные архитектуры серверов баз данных. Jet Info, Вып. 1, 1995.

  • Н. Вьюкова. Архитектура сервера INFORMIX-OnLine Dynamic Server 7.1 и
    коммуникационные средства. Jet Info, Вып. 2, 1995.

  • Н. Вьюкова. Сервер для кластерных и массово-параллельных архитектур. Открытые системы,
    N 4, 1995.

    []
    []
    []

  • К.Дэйт. Руководство по реляционной СУБД DB2., М.: Финансы и статистика, 1988.
  • Г.Буч. Объектно-ориентированное проектирование с примерами применения.
    М.: Конкорд, 1992.
  • T.Moynihan. Objects Versus Functions in User-Validation of Requirements: Which Paradigm Works
    Best? Proceedings of the International Conference on Object Oriented Information Systems, 1994.
  • Object Oriented Applications Using Relational Databases/ IBM International Technical Support
    Centers, 1994.
  • IBM White Pare. Object Support and the DB2 Family. Data Management Solutions, 1994/
  • К.Вон. Технология объектно-ориентированных баз данных. Открытые системы, осень 1994.
  • Sean Brady. DB2 V2 Technical Overview/ Proceedings of the IDUG 4th Annual Conference, 1995,
    V.1, p.145.

    []
    []
    []

  • Barker, R. (1990). CASE*Method Entity Relationship Modelling. Wokingham, England, Addison-
    Wesley.
  • Barker, R. and Longman, C. (1993). CASE*Method Function and Process Modelling. Wokingham,
    England, Addison-Wesley.
  • Barker, R. et al. (1990). CASE*Method Tasks and Deliverables Modelling. Wokingham, England,
    Addison-Wesley.
  • Barker, R. and Clegg, D. (1994). CASE*Method Fast-Track A RAD Approach. Wokingham,
    England, Addison-Wesley.
  • Hickman, L. and Longman, C. Foreword by Barker, R.(1994). CASE*Method Business Interviewing.
    Wokingham, England, Addison-Wesley.
  • Hammer, M. and Champy, J. (1993). Reengineering the Corporation: A Manifesto for Business
    Revolution. Harper Collins, New York.
  • Chen, P.P. (1976). The Entity-Relationship Model: Toward a Unified View of Data. ACM
    Transactions on Database Systems N1

    []
    []
    []


  • А.Закис, М.Макаров, Н.Приезжий. Применение интегрированной CASE-технологии фирмы
    Wesmount для разработки информационных систем. DBMS/RE, #2, 1995.
  • А.М.Вендров. Один из подходов к выбору средств проектирования баз данных и приложений.
    СУБД, #3, 1995.
  • E. Yourdon & L.L. Constantine. Structure Design, Fundamentals of a Discipline of Computer Program
    and System Design. Yourdon Press, Englewood Cliffs, 1979.
  • P.P. Chen (editor). Entity Relationship Approach to System Analysis and Design. North
    Holland Publishing Company, 1980.

    []
    []
    []

    Менеджер Переводов (Translation Manager)

    Менеджер Переводов упрощает задачу перевода приложений PROGRESS на другие языки. Это
    средство может быть также использовано для упорядочения терминологии в рамках организации
    или отдела. При использовании Менеджера Переводов, процесс перевода не требует от Вас
    специальных предварительных приготовлений. Нет необходимости выделять текст в отдельный
    файл или набор файлов, что, несомненно, упрощает разработку, так как все текстовые сообщения
    остаются в модулях приложения. После того, как разработка приложения завершена, Менеджер
    Переводов запускается для поиска в компонентах приложения текстовой информации, включая
    заголовки, тексты в меню, разъяснительную информацию и т.д. Исходное приложение при этом не
    изменяется.

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

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

    Использование Менеджера Переводов - это еще один пример того, как обеспечивается полная
    поддержка всех этапов разработки приложений в среде PROGRESS.


    Место SQL Anywhere среди СУБД для рабочих групп

    Нам было особенно интересно изучить новую версию Watcom SQL после работы с продуктами
    фирмы Sybase (система 10) и знакомства с Microsoft SQL 6.0. На наш взгляд, новой версии SQL
    Anywhere 5.0 приданы все качества СУБД для рабочих групп, какие существуют на сегодняшний
    день у конкурентов, и кое-что еще, делающее этот продукт технически лидером - собственная
    система репликации, основанная на механизме передачи сообщений и электронной почте.

    С другой стороны, SQL Anywhere подкреплен совместимостью с линией продуктов Sybase System
    11, характеристики которой рассматривались недавно в ComputerWorld и PC Week href="#lit">[4].

    Все эти факторы (включая и ценовой) делают выбор SQL Anywhere весьма привлекательным для
    массового использования как на "нижних" уровнях больших информационных систем, так и в
    качестве ядра относительно небольших разработок.


    Методологические основы проектирования

    Е. Ойхман, О. Евсеев, С. Паронджанов, Компания Аргуссофт (Москва)

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

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

    Статические и динамические модели строятся только для основных видов деятельности организации и только в том объеме и с той степенью подробности, которая обеспечивает формирование требований к ИС. При определении требований кинформационным системам это позволяет ограничиться представлением только информационных процессов, связанных с оказанием услуг клиентам.

    Информационные системы разбиваются на совокупность архитектур, каждая из которых описывает различные аспекты ИС с разных точек зрения. Это позволяет разделить формирование требований к ИС на ряд итерационно выполняемых шагов, на каждом из которых решаемые задачи построения моделей и исследования вариантов архитектур имеют меньшую размерность и более просты, чем вся задача определения требований к ИС в целом.

    При построении моделей используется принцип проектирования по методу "сверху вниз" и "от общего к частному", что позволяет упростить решение задач без потери качества и ограничиться представлением в моделях только главных деталей и в том объеме, который необходим для определения набора требований к конкретной архитектуре информационной системы на очередном уровне ее детализации.

    При построении статических и динамических моделей целесообразно использовать объектно-ориентированный подход, который позволяет снизить размерность и трудоемкость проектирования моделей за счет их разумной декомпозиции и выделения повторно используемых типовых фрагментов, которые используются в качестве базовых конструктивных элементов моделей.

    Использование этих соглашений дает реальную основу для преодоления трудностей, связанных с размерностью моделирования крупномасштабных организаций при определении требований к их информационным системам.

    Подход основан на использовании мощных средств для построения моделей: CASE-средств для построения статических моделей и автоматизации моделирования функций, данных и структуры организации и информационной системы, и интеллектуальных средств для построения динамических моделей организации и информационной системы и проведения динамического моделирования процессов.

    Методическая схема итерационного проектирования информационных систем и уточнения требований к ним, а также реинжиниринга бизнес-процессов при помощи современных средств интеллектуального динамического моделирования заключается в следующем.

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

    На первом шаге строятся "главные" статические и динамические модели основных видов деятельности организации, раскрывающие ее основные бизнес-процессы на всех уровнях управления. Уровень детализации этих моделей выбирается достаточно крупным, исходя из требований получения оценок времени выполнения процессов основных контуров управления организации.

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

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

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

    Создание адекватных и продуктивных динамических моделей представляет собой достаточно сложную самостоятельную проблему, от эффективности решения которой зависит не только точность формируемых требований к ИС, но и сама возможность успешной реализации проекта. Преодоление "проклятия размерности" приобретает особую важность при построении динамических моделей крупномасштабных корпоративных систем. Такие модели при попытке их построения согласно традиционной схеме последовательного наращивания описаний бизнес-процессов с преобладанием стратегии "поиска в глубину" потенциально могут включать в себя сотни и тысячи взаимосвязанных операций, потоков и функций их преобразования.


    Это может не только вызвать задержки в построении моделей, но и превратить их создание в интеллектуально емкий самопоглощающий процесс.

    Анализ требований к средствам динамического моделирования, связанных с этими проблемами, показывает, что в настоящее время наиболее удовлетворительными инструментальными средствами, обладающими необходимыми свойствами, являются интеллектуальные системы моделирования, обработки информации и управления реального времени, основанные на последних практических достижениях в области инженерии знаний и искусственного интеллекта.

    Наиболее мощными инструментальными средствами такого типа являются: динамическая интеллектуальная система G2 фирмы Gensym (USA) и ее дочерняя моделирующая система ReThink. Эти средства позволяют преодолеть основные трудности, связанные с размерностью задач моделирования крупномасштабных организаций, и обеспечивают пользователю следующие важные преимущества:

  • возможность быстрого построения структурно-логических описаний сложных комплексов взаимодействующих между собой объектов, динамических процессов, потоков и баз при представлении моделируемых архитектур ИС. Быстрота разработки моделей принципиально важна, так как моделирование должно служить не сдерживающим фактором, а ускорителем процесса проектирования систем;
  • возможность представления логико-динамических процессов обработки информационных и материальных потоков системы на разных уровнях детализации архитектур с использованием обобщений, адекватных данным уровням детализации. Имеется возможность описывать одни и те же процессы с разной степенью детализации, а также закладывать в модель алгоритмы функционирования организации в виде бизнес-правил, формулируемых экспертами, а при описании архитектур ИС - представлять в модели обобщенные правила логической организации процессов обработки информации, ограничения и свойства моделируемых архитектур;
  • возможность прототипирования динамических моделей архитектур, т.е. представление их в принципиально открытой, реконфигурируемой, модифицируемой, уточняемой и детализируемой форме.


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

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

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

    Телефоны авторов: 288-24-36, 288-10-90

    []
    []
    []

    Методология DATARUN и CASE-система SILVERRUN

    С. Панащук, Компания Аргуссофт
    При разработке крупных информационных систем необходим как единый методологический подход к
    процессу проектирования, так и средства автоматизированной поддержки этого подхода. Методология
    DATARUN и CASE-система SILVERRUN обеспечивают эти требования на уровне, соответствующем
    современному состоянию развития программной инженерии.


    Методология DATARUN

    Высокая динамичность рынка требует от организаций быстрого развития информационно-
    технологической инфраструктуры. Одной из ее наиболее важных и дорогостоящих составляющих
    является информационная система, для реализации которой применяются современные технологии:
    архитектура клиент/сервер, распределенные базы данных, сложные сети коммуникаций, развитые
    интерфейсы пользователя. Все это ставит перед разработчиком проблему выбора инструментальных
    средств и технологий для ведения проекта.

    Создание сложной информационной системы невозможно без единого интегрированного подхода к
    процессу разработки. Такой подход часто оформляется в виде коммерчески доступной методологии
    проектирования. Методология служит двум целям: 1) обеспечивает концептуальную основу для всего
    процесса разработки; 2) предоставляет технологию руководства проектом.

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

    DATARUN - уникальная концепция в ряду методов. Эта методология гарантирует, что на каждой стадии
    выполняется только существенная для целей проекта работа, облегчающая быстрое создание
    приложений. Повторения и избыточность в спецификациях исключаются, создается управляемая,
    основанная на моделях форма итеративной разработки. Исходные версии объектов доступны для
    непосредственного использования на следующих фазах проектного цикла. Создаваемая информационная
    система описывается рядом последовательных моделей, каждая из которых является развитием
    предыдущей и наследует правила и данные, определенные в более ранних моделях. Наследование
    свойств позволяет многократно использовать различные спецификации на всех уровнях прикладного
    проекта.

    Методология DATARUN ведет заказчика и разработчика информационной системы по всем этапам

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

    Методология DATARUN обеспечена средствами автоматизированной поддержки:

  • Для управления проектной деятельностью имеется система Software
    Engineering Companion, позволяющая детально расписывать ведение проекта,
    распределять проектные роли среди исполнителей, контролировать выполнение
    заданий.
  • Детальное изложение техник моделирования данных и бизнес-функций,
    проектирования баз данных, создания приложений содержится в гипертекстовой
    системе Software Engineering Guidelines.
  • Автоматизация проведения проектных работ обеспечивается CASE-системой
    SILVERRUN.
    Предоставляемая этими средствами среда проектирования дает возможность руководителю проекта
    контролировать выполнение работ. Каждый участник проекта, подключившись к системе, может
    уточнить содержание и сроки выполнения порученной ему работы, изучить технику ее выполнения в
    гипертексте по технологиям, и вызвать инструмент (модуль SILVERRUN) для реального выполнения
    работы.

    Такой автоматизированный комплекс поддержки выполнения проектов, основанный на современной
    методологии проектирования и эффективном CASE-средстве, создает все необходимые условия для
    быстрого создания сложных информационных систем с высоким качеством.

    Microsoft SQL Server Distributed Management Framework (SQL- DMF)

    С появлением SQL Server 6.0 Microsoft предложил на рынке сервер с масштабируемой
    архитектурой управления, наиболее оптимальным образом подходящей к быстро меняющимся
    задачам, которые встают перед системами архитектуры клиент-сервер. Microsoft SQL Server
    Distributed Management Framework (SQL-DMF) имеет трехуровневую объектно- ориентированную
    архитектуру, которая предоставляет компоненты, сервисы и инструментарий, необходимые для
    управления распределенными серверами в масштабе предприятия.(Рис.5)

    Microsoft SQL Server Distributed Management Framework (SQL- DMF)

    Microsoft SQL Server

    Д.Артемов, Microsoft
    Подобно тому как Windows NT является базовой операционной системой, на которой работают
    приложения BackOffice, Microsoft SQL Server для Windows NT является основным средством
    обработки больших объемов информации в масштабе предприятия. Новая версия SQL Server
    значительно расширена для повышения производительности СУБД, упрощения
    администрирования, повышения надежности и скорости обработки данных.


    Middleware: модель сервисов распределенных систем

    Г. Ладыженский, Jet Infosystems системы ()

    Сообщение подготовлено на основе концепции, изложенной в статье Филиппа Бернштейна (Philip A.Bernstein) "Middleware - A model for Distributed System Services", напечатанной в журнале Communications of the ACM (February 1996 - Volume 39, Number 2), а также собственных соображений и опыта работы автора.













    Middleware: основные понятия

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

    Серверы в локальных вычислительных сетях (ЛВС) обычно поддерживают обработку файлов и приложения, опирающиеся на модель файлового сервера - например, электронную почту, доски объявлений, подготовку документов и сетевую печать. Локальные серверы поддерживают службу каталогов и обеспечивают пользователям возможность поиска интересующих их сервисов и подключения к ним. Серверы в глобальной сети обычно поддерживают доступ к базам данных, корпоративным каталогам, электронным библиотекам, или приложения обработки транзакций. Некоторые серверы обеспечивают шлюзы к сервисам, которые предлагаются вне рамок организации - например, к услугам туристических фирм, информационно-поисковым службам, службам новостей (погода, котировки ценных бумаг) или службам, поддерживающим электронный обмен документами с деловыми партнерами. Ряд компаний реорганизуют бизнес-процессы таким образом, чтобы максимально эффективно использовать указанные возможности и объединить прежде изолированные друг от друга источники информации.

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

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

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

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

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

    Другой способ, применяемый производителями для разрешения проблемы разнородности - поддержка стандартных протоколов. Стандартные протоколы делают возможным взаимодействие программ. Говоря о взаимодействии (interoperate), мы имеем в виду, что программа в составе одной системы имеет доступ к программам и данным в составе другой системы.


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

    Чтобы помочь потребителям решить проблемы разнородности и распределенности и сделать возможной реализацию информационных служб, производители предлагают сервисы распределенной системы которые обладают стандартными программными интерфейсами и протоколами. Такие сервисы называются сервисами промежуточного (среднего) слоя (middleware services), поскольку располагаются "в середине", занимая промежуточный уровень между операционными системами и сетевым программным обеспечением с одной стороны, и приложениями, ориентированными на конкретную прикладную область - с другой стороны.

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

    Разработчикам необходимы высокоуровневые интерфейсы, которые скрывают неоднородность сетей и протоколов, и позволяют им (разработчикам) сконцентрировать внимание на решении специальных проблем прикладной функциональности - на той области деятельности, где они сильны и реально создают дополнительную стоимость.

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

    Для многих приложений программный интерфейс, предоставляемый ПО промежуточного слоя, фактически определяет вычислительную среду. Например, многие приложения трактуют таким образом языки четвертого поколения (4GL), мониторы обработки транзакций (TP) (IBM CICS, Digital ACMSxp), и офисные интегрированные системы ( Lotus Notes, LinkWorks).

    Унаследованные приложения (legacy applications), разработанные еще до того, как мобильное ПО промежуточного слоя стало фактическим стандартом, также могут воспользоваться его сервисами. Можно определить унаследованное приложение как набор функций и воспользоваться коммуникационными сервисами ПО промежуточного слоя для обеспечения удаленного доступа к этим функциям. Для этой цели можно, например, воспользоваться реализацией Common Object Request Broker Architecture (CORBA) консорциума Object Management Group (OMG).

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

    Сервисы ПО промежуточного слоя

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

    Сервис ПО промежуточного слоя (middleware service) - сервис общего назначения, который располагается между платформами и приложениями ().


    Под платформой мы подразумеваем набор низкоуровневых сервисов и элементы обработки, определяемые парой: архитектурой процессора и API операционной системы, например, Intel x86 и Win32, Sun SPARCstation и SunOS, IBM RS/6000 и AIX, Alpha AXP и OpenVMS, или Alpha AXP и Windows NT.

    Middleware: модель сервисов распределенных систем

    Рис.1. Программное обеспечение промежуточного слоя

    Сервис ПО промежуточного слоя определяется интерфейсами прикладного программирования и протоколами, их поддерживающими. Сервис может иметь множество реализаций, соответствующих спецификациями его интерфейса и протокола, как, например, различные реализации DCE RPC и протокола IBM 3270. Как и многие системные категории, ПО промежуточного слоя трудно точно определить в техническом смысле. Тем не менее, компоненты ПО промежуточного слоя обладают рядом свойств, которые, взятые в совокупности, свидетельствуют о том, что данный компонент не является сервисом, специфичным для приложения или платформы. Компоненты ПО промежуточного слоя являются общими для различных приложений и прикладных областей; они функционируют на разных платформах, распределены и поддерживают стандартные интерфейсы и протоколы. Ниже мы опишем каждое из этих свойств.

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

    Сервис ПО промежуточного слоя должен иметь реализации для разных платформ. В противном случае это - специфический сервис платформы. Например, системы управления реляционными базами - это ПО промежуточного слоя.


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

    Если сервис является распределенным, это также усиливает интероперабельность, поскольку приложения на разных платформах могут использовать его для коммуникаций и/или обмена данными. Чтобы охватить как можно больше платформ, сервисы ПО промежуточного слоя разрабатывается как переносимые (portable). Это означает, что их можно перенести (портировать) на другую платформу, предприняв при этом небольшие и заранее предсказуемые действия.

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

    В идеале, сервис ПО промежуточного слоя поддерживает стандартный протокол (например, TCP/IP или семейство протоколов ISO OSI), или, по крайней мере, опубликованный протокол (например, SNA LU62 корпорации IBM). Таким образом можно разработать множество реализаций сервиса, и все они будут взаимодействовать между собой. Однако, если сервис ПО промежуточного слоя действительно работает на всех популярных платформах, его можно рассматривать как стандартный, даже если его протоколы не опубликованы. Такое свойство имеет, например, большинство СУБД.

    Сервис ПО промежуточного слоя должен поддерживать стандартный API. Он (сервис) является прозрачным (transparent), по отношению к API, если к нему обеспечен доступ посредством API, но при этом не требуется модификация самого API.

    Если производитель ПО обеспечивает широкий охват платформ и обладает значительной долей рынка, то поддерживаемый им API и протокол можно рассматривать как фактический стандарт, даже если ни API, ни протокол не поддерживают другие производители. Например, в реляционных СУБД ORACLE и SYBASE поддерживаются собственные диалекты языка SQL, и даже при этом рассматриваются большинством потребителей как фактический стандарт. Аналогично монитор обработки транзакций CICS корпорации IBM использует собственные API и протокол (LU6.2), и, тем не менее, является фактическим стандартом.

    Вопрос о том, относится ли данный сервис к ПО промежуточного слоя, со временем решается по-разному. Компонент, который в данный момент рассматривается как часть платформы, может в будущем стать ПО промежуточного слоя. В результате реализация ОС упростится, а сервисы, предоставляемые данным компонентом, станут общедоступными для всех платформ. Например, мы рассматривали традиционную файловую систему как стандартный компонент операционных систем, каковой она несомненно была во всех коммерческих ОС, разработанных до 1980 года. Однако сегодня мы часто рассматриваем файловую систему как ПО промежуточного слоя - имея в виду, например, реализации, соответствующие стандарту API X/Open C-ISAM.

    Напротив, ПО промежуточного слоя может встроено в платформу, чтобы улучшить ее производительность и повысить коммерческую ценность платформы. Например, интерфейсы протоколов транспортного уровня часто рассматривались как продукты, обеспечивавшие доступ к коммуникационным сервисам, как продукты, независимые от ОС. Теперь они обычно включаются в ОС.

    Ввиду того значения, которое имеют стандартные интерфейсы для переносимости приложений, а стандартные протоколы - для их взаимодействия, По промежуточного слоя стало объектом усилий по стандартизации. Некоторые из них были предприняты организациями, вырабатывающими стандарты - например, ISO и ANSI, некоторые - консорциумами производителей, такими как X/Open, OSF и OMG, а некоторые спонсировались компаниями, имеющими значительную долю рынка ПО - например, архитектура Windows Open Services Architecture (WOSA) стала результатом усилий корпорации Microsoft.


    Иногда отдельный сервис получает гигантское распространение и поэтому становится фактическим стандартом, как, например, PostScript (Adobe), монитор транзакций CICS (IBM) и Network File Service (Sun Microsystems).

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

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

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


    Некоторые из них недоступны на многих популярных платформах, что ограничивает потребителя в выборе платформ и сужает его возможности при работе в неоднородных системах. Это замечание относится, например, к реляционным СУБД Rdb корпорации Oracle (ранее система принадлежала DEC) и DB2 (IBM).

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

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

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

    Интегрированная среда

    Интегрированная среда (framework) - это среда программирования, которая спроектирована с целью упрощения разработки и управления приложениями для домена специализированных приложений (). Интегрированная среда (ИС) определяется интерфейсом прикладного программирования, интерфейсом с пользователем и инструментарием. В дополнение к сервисам ПО промежуточного слоя, которые ИС импортирует из других продуктов, она может также включать собственные сервисы. Приведем примеры ИС. Это - так называемые офисные системы (Lotus Notes, Microsoft Office, DEC LinkWorks), мониторы транзакций (IBM CICS, DEC ACMSxp, BEA Systems Tuxedo, Transarc Encina), языки четвертого поколения (Uniface, Cognos и Focus), системы автоматизированного проектирования (Mentor Graphics Falcon, DEC Powerframe), CASE-системы (HP SoftBench, Texas Instrument Composer, Anderson Consulting Foundation, DEC COHESIONworX), и системы управления распределенными ресурсами (HP OpenView, Tivoli Management Environment, IBM NetView).

    Middleware: модель сервисов распределенных систем

    Рис.2. Интегрированная среда

    ИС - это один из видов ПО промежуточного слоя.

    Иногда сервисы ПО промежуточного слоя расширяются до масштабов ИС. Так произошло с инструментарием для работы с реляционными СУБД. Иногда набор сервисов интегрирован в такой степени, чтобы фактически превращается в ИС. Например, в OSF DCE интегрированы сервис RPC, сервис имен, сервис аутентификации, служба времени, сервис идентификации и файловый сервис. Отметим, что в DCE нет как такового обобщенного интерфейса пользователя, и весь интерфейс прикладного программирования DCE - это, собственно, API упомянутых выше сервисов. Тем не менее, DCE поддерживает контекст вызовов (по идентификатору пользователя), и обеспечивает прозрачный вызов сервисов для упрощения некоторых операций.

    Поскольку ИС опирается на сервисы ПО промежуточного слоя, постольку ИС является потребителем услуг ПО промежуточного слоя. Точно также приложение, которое опирается на ИС, является ее клиентом, и, опосредовано - потребителем сервисов ПО промежуточного слоя.


    Приложения уходят от непосредственного вызова сервисов ПО промежуточного слоя и опираются в основном на ИС. Эта тенденция аналогична другой, имевшей место в прошлом тенденции, когда приложения уходили от прямого использования сервисов, предоставляемых платформой, и опирались на сервисы ПО промежуточного слоя.

    Один из методов, при помощи которого упрощается API ИС - сохранение контекста вызова различных сервисов. Например, в большинстве ИС вызовы сервисов требуют в качестве параметров идентификатор пользователя (для контроля доступа) и идентификатор устройства (для установления связи). ИС трактует эти идентификаторы как контекст приложения, но не как параметры, упрощая таким образом API. Например, CASE-система COHESIONworX поддерживает контекст, включающий имя пользователя, имя дисплея и рабочую область, содержащую каталоги файлов и указатели на объекты. Поддержка контекста не является уникальным свойством ИС. Сервис тоже может поддерживать контекст, хотя этот контекст обычно бывает локальным по отношению к данному сервису. Например, DCE RPC сохраняет идентификатор пользователя между вызовами RPC.

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

    ИС может поддерживать собственные, приватные сервисы ПО промежуточного слоя. Обычно это происходит потому, что интегрированной среде необходим сервис, а такого стандартного сервиса ПО промежуточного слоя не предоставляет. Например, многие мониторы транзакций используют частную реализацию RPC, однако при наличии DCE, некоторые из них заменяют свои собственные реализации RPC стандартной.

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


    Примерами могут послужить различного рода редакторы, средства помощи, менеджеры форм, компиляторы, отладчики, средства мониторинга производительности.

    Мониторы обработки транзакций

    Для иллюстрации концепции ПО промежуточного слоя, рассмотрим один из видов ИС - мониторы обработки транзакций (Transaction Processing Monitor - TPM). Основная функция TPM - это управление потоком запросов между терминалами или другими устройствами и прикладными программами, которые могут обрабатывать эти запросы. Запрос (request) - это специфическое сообщение, инициирующее выполнение транзакции. Приложение, которое выполняет транзакцию, обычно получает доступ к менеджерам ресурсов, например, к СУБД. Типичный TPM включает функции управления транзакциями, средства для организации межпроцессного взаимодействия, средства управления очередями запросов и средства управления формами и меню ().

    Middleware: модель сервисов распределенных систем

    Рис. 3. Архитектура монитора обработки транзакций

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

    TPM поддерживают традиционные возможности межпроцессного взаимодействия, когда один процесс передает некоторый фрагмент своего контекста другому процессу - и все это в рамках одной транзакции. Это, как правило, либо взаимодействие по схеме "равный-с-равным" ("отправить сообщение", "получить сообщение", или стандартный либо несколько модифицированный механизм RPC ("отправить запрос", "получить ответ").

    Менеджер очереди - это специализированный менеджер ресурсов, обеспечивающий хранение запросов в долговременной памяти (на диске) с целью гарантированной поддержки надежного межпроцессного взаимодействия и гарантированного выполнения транзакций. Основные операции менеджера очередей - помещение запроса в очередь и выборка запроса из очереди.


    Менеджер распределенных очередей обеспечивает гарантированную передачу запросов из одной очереди в другую.

    Традиционно в TPM эти функции были реализованы как специальные сервисы интегрированной среды, которые, в свою очередь, опираясь только на сервисы платформы. Сегодня многие из этих сервисов ИС определены как сервисы ПО промежуточного слоя. Разрабатываемые сегодня TPM обращаются к таким стандартным сервисам, как менеджеры записей, менеджеры транзакций и менеджеры очередей.

    Делаются попытки стандартизации API и протоколов всех описанных выше сервисов. Так, например, консорциум X/Open работает над стандартами API для управления транзакциями и коммуникациями (стандарт X/Open ATMI - Application - Transaction Management Interface), а ISO - над стандартным протоколом для управления очередями.

    Традиционно большинство TPM зависели от платформы, для которой и были созданы. Современные мониторы обработки транзакций опираются на сервисы ПО промежуточного слоя и обладают большей переносимостью, так как в их основу положены сервисы ПО промежуточного слоя, которые переносимы сами по себе.

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

    TPM обычно включает инструментарий прикладного программирования. Например, в него может входить словарь данных, используемый менеджером форм, приложениями и СУБД. Digital использует для этой цели собственный словарь данных Common Data Dictionary/Repository (для интеграции TPM ACMS, реляционной СУБД Rdb, менеджера форм DECforms).

    TPM также включает средства системного управления и мониторинга. Они позволяют отображать состояние транзакции или запросов, следить за показателями производительности системы и настраивать ее параметры. Функции управления и мониторинга могут быть реализованы в обособленной ИС. Она объединяет средства управления и мониторинга TPM и средства управления платформой и СУБД. Тогда мы имеем единообразный способ мониторинга и контроля за всеми доступными ресурсами.

    Интеграция сервисов ПО промежуточного слоя

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

    Допустимы самые различные критерии оценки приложений и ПО промежуточного слоя и вообще программных систем. Среди них - удобство в использовании, степень распределенности и интегрируемости, соответствие стандартам, расширяемость, возможности интернационализации, управляемость, производительность, переносимость, надежность, масштабируемость и безопасность. Мы называем эти параметры общими свойствами системы (pervasive attributes), поскольку они применимы ко всей системе в целом, а не только к ее компонентам.

    Разумеется, пользователи хотели бы иметь информационные системы с высокими показателями по каждому из свойств. Этой цели можно достичь, разрабатывая приложения на основе сервисов ПО промежуточного слоя. При этом системные проектировщики могут предпринять усилия по улучшению качественных показателей системы за счет специальных стандартизованных решений.

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


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

    Тенденции

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

    Современное ПО промежуточного слоя недолго будет оставаться разнородным. Поэтому, разрабатывая новую сервис ПО промежуточного слоя, производитель должен немедленно найти способ сделать этот сервис стандартом де-факто. Разработчики приложений не станут использовать сервис, не будучи уверены в том, что он станет фактическим стандартом.

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

    []
    []
    []

    Моделирование, анализ и реорганизация деловой деятельности

    Средства анализа деловой деятельности - новый компонент, не имеющий аналогов в предыдущих
    версиях CASE - продуктов фирмы ORACLE. Он предназначен для описания и анализа
    деятельности организации или компании, визуального представления основных технологических
    процессов, способов коммуникации и т.п. Включение этого компонента в общую интегрированную
    среду DESIGNER 2000 связано с быстро развивающимся в последние годы новым направлением
    менеджмента, известным под названием анализ и реорганизация деловой деятельности (Business
    Process Reengineering).

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

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

    Входящие в состав DESIGNER 2000 средства моделирования процессов полностью отвечают этим
    требованиям. Использование средств мультимедиа, включая визуализацию, звуковое
    сопровождение, видеоизображение, анимацию, позволяет дополнительно повысить
    выразительность моделей процессов и обеспечивает возможность исследовать их динамические
    характеристики.

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


    Моделирование, анализ и реорганизация деловой деятельности

  • базовый процесс;
  • шаг процесса;
  • поток данных;
  • хранилище данных;
  • организационная единица;


    • Моделирование данных

    В процессе первичного анализа данных, собранных из разных источников, необходимо выявить основные
    информационные понятия (сущности) и их взаимосвязи. Эта деятельность поддерживается модулем ERX, в
    который встроена экспертная система, помогающая реструктурировать "сырую" информацию и привести
    ее к виду, допускающему реализацию в реляционной СУБД. На рис. 2 показана структура данных, а нa
    рис. 3 - модель "сущность-связь" в третьей нормальной форме, автоматически
    построенная модулем ERX из этой структуры и нормализованная в процессе ответов пользователя на
    задаваемые системой вопросы.

    На рис. 4 показана созданная в ERX модель, перенесенная в модуль
    реляционного моделирования RDM и доработанная для непосредственной реализации в реляционной базе
    данных. В нижней части символов таблиц показаны действия над записями. В генерируемой мостом схеме
    базы данных это будут соответствующие триггеры. А три колонки справа от имен столбцов таблиц
    отражают действия, производимые над этими столбцами при операциях считывания, присваивания и
    модификации значений. Также можно определять глобальные действия на уровне всей модели (в схеме
    базы данных - хранимые процедуры). Таким образом достигается не только определение конструкций
    реляционной СУБД, но и объектно-ориентированное расширение реляционной модели.

    Data structure
    Name : Заказ
    Composition :
    Заказ Номер
    Заказ Дата
    Покупатель Имя
    Покупатель Адрес
    Продукт
    Продукт Название
    Продукт Цена
    Продукт Количество
    Продукт Стоимость
    Заказ Стоимость
    Рис. 2. Структура данных, на основе которой будет строится
    ER-модель

    Моделирование данных

    Моделирование процессов

    Диаграммы потоков данных, создаваемые в SILVERRUN, соответствуют современному развитию
    принципов структурного анализа. В системе имеется возможность изменять внешний вид символов
    диаграмм и выбирать отображаемые в них дескрипторы, включая определяемые пользователем. На рис. 1 показан экран определения нотации модуля BPM. Также можно выбирать
    набор правил, проверяемых процедурой анализа корректности модели. В SILVERRUN встроено
    несколько предопределенных нотаций и наборов правил, соответствующих наиболее известным методам
    построения DFD: Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor.

    Моделирование процессов

    Моделируются бизнес-процессы

    Пояснять, что такое бизнес-процессы в документообороте, вряд ли нужно - каждый специалист
    сталкивается с ними ежедневно. Например, бизнес-процесс покупки материалов состоит из
    получения счета, его оплаты, получения материалов по накладной и их оприходования на
    склад. Этому сопутствует оформление и подписание определенного набора документов href="../../pictures/it/ofis96/133_3.gif">(Рис.~300K). Из подобных бизнес-процессов, в сущности, и
    состоит вся оперативный документооборот предприятия. Корпоративные системы нового
    поколения позволяют предприятию самостоятельно моделировать в системе свои бизнес-
    процессы. Это значит, что, продумывая внедрение нового бизнес-процесса, руководитель
    самостоятельно или с помощью своего специалиста по компьютерам описывает его в своей
    корпоративной системе, определяя при этом, какие документы участвуют в процессе и кто из
    специалистов отвечает за действия с этими документами. Больше руководителю не придется ни
    инструктировать своих специалистов, ни контролировать последовательность действий или
    правильность оформления документов - система просто не позволит персоналу делать ошибки
    или нарушать технологию работы.
    Моделируются бизнес-процессы

    Наиболее примечательные возможности S-Designor

    Чем хорош и примечателен S-Designor? В первую очередь тем, что это - профессиональное
    средство информационного моделирования и разработки структур данных. Помимо "широко
    известных" функций для CASE-средств такого уровня добавлены мощные средства групповой
    разработки и генерация приложений для целевых средств разработки. Примечателен S-
    Designor тем, что концептуально целостно построен и имеет строгую практическую
    направленность. Ниже освещены некоторые наиболее интересные возможности S-Designor.



    Направления дальнейшего развития

    Дальнейшее развитие PowerBuilder связывается с новой версии 5.0, которая должна появиться в первой
    половине 1996 года.

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

    Новая версия выйдет для платформ Windows 95, Windows NT, Windows 3.X и будет поддерживать
    разработку как 32, так и 16 разрядных приложений. На платформе NT будут поддерживаться
    двухбайтовые символы. Затем последуют версии PowerBuilder для UNIX и Macintosh. В новой версии
    реализована полная поддержка элементов управления Windows 95, таких, как диалоги с закладками,
    иерархические списки и т.д. Полностью поддерживается OLE 2.0.

    Добавлена возможность построения многоуровневых приложений средствами PowerBuilder,
    распределяя различные компоненты приложений по сети. Для передачи данных будут поддерживаться
    протоколы Winsock, Named Pipes и Sybase Open Client/Server.

    Расширены возможности PowerScript, пополнился список встроенных функций. Улучшены Окна
    Данных, которые теперь смогут отображать информацию из базы данных непосредственно
    используя элементы управления OLE (OCX) или в формате RTF.

    Новая версия PowerBuilder обещает стать надежным основанием для разработок сложных приложений
    клиент/сервер масштаба предприятия.


    []
    []
    []

    Настройка режимов отображения

    Диаграммы информационных моделей современных информационных систем обычно весьма велики,
    вследствие чего работать со всей диаграммой достаточно сложно как на стадии проектирования
    информационной модели, так и при разработчикам прикладного программного обеспечения. ERwin
    дает возможность работать не со всей диаграммой, а с логически законченной группой сущностей,
    называемой предметной областью (Subject Area). Переключение отображения с одной предметной
    области на другую производится выбором из раскрывающегося списка.

    Например, рассмотрим информационную модель для некоторого абстрактного предприятия. В
    информационной системе задействованы бухгалтерия, склад, кадры. В этом рассмотренные в первом
    примере сущности (сотрудник, история работы, доход) могут быть выделены в отдельную предметную
    область "кадры".

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

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

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


    Несколько процессов, работающих с сетевыми соединениями

    В предыдущей версии Sybase System 10 сетевым обменом занимался только один процессор в SMP-
    архитектуре. Это ограничивало масштабируемость сервера на симметричной мультипроцессорной
    архитектуре, так как было "узким местом" при увеличении числа процессоров. В версии Sybase
    System 11 сетевым обменом могут заниматься все процессоры.


    Несколько выводов

    Если попытаться сделать выводы из всего описанного выше, то необходимо прежде всего отметить
    следующее:

  • Входящий в состав VantageTeam Builder кодогенератор является весьма
    мощным и гибким средством, позволяющим свести значительную долю рутинной
    работы программиста по написанию программ "по образцу" к однократному
    написанию этих самых образцов. Причем в отличие от многих билдеров вы
    можете непосредственно видеть сгенеренный текст и вносить изменения как в
    него, так и в те шаблоны, по которым он генерится.
  • VantageTeam Builder в комплекте с генератором GRINDERY позволяет
    использовать один и тот же проект для генерации приложений на таких различных
    языках, как Informix-4GL, NewEra и SuperNOVA. Это, в частности, позволяет
    упростить переход от Informix-4GL к NewEra и само освоение объектных подходов
    к разработке приложений.


    NewEra как универсальный язык программирования

    Программа на языке NewEra состоит из одного или нескольких файлов (модулей). Различаются
    программные и заголовочные модули. Оператор INCLUDE "имя_файла" позволяет включить в
    тело модуля текст другого файла. Имеется стандартный набор управляющих операторов.

    Определены интерфейсы для вызовов С-функций из программ NewEra и функций NewEra из
    программ на языке С.

    Множество встроенных типов данных NewEra соответствует набору типов данных,
    поддерживаемых СУБД Informix, и включает, в частности, типы данных для работы с большими
    бинарными объектами.

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

    Поддерживаются записи и многомерные массивы - два вида структурных необъектных типов,
    унаследованных от языка Informix-4gl.


    NewEra - новая линия инструментальных средств компании Informix

    Н. Вьюкова
    Средства разработки приложений и средства доступа к базам данных для конечного пользователя
    занимали значительное место в деятельности компании Informix с момента ее зарождения. Спектр
    продуктов Informix в этой области охватывает потребности и предпочтения самых разных групп
    разработчиков - от профессионалов до прикладных специалистов, не имеющих навыков
    программирования. Ниже перечислены исторические предшественники Informix-
    NewEra:

  • Informix-SQL - инструмент программирования на языке SQL.
  • Informix-ESQL/C - среда программирования на языке С со встроенным SQL.
  • Informix-ESQL/COBOL - среда программирования на языке COBOL со
    встроенным SQL.
  • Informix-4GL - инструмент программирования на языке 4-го поколения (4GL)
    со встроенным SQL, включает компилятор языка 4GL, средства построения
    экранных форм и меню.
  • Informix-4GL-RDS+ID - версия Informix-4GL со средствами быстрой
    разработки (RDS) и интерактивной отладки (ID).
  • Informix-HyperScript Tools - инструмент создания приложений в среде
    Windows, Unix и др. Позволяет программировать меню, диаграммы,
    электронные таблицы, экранные формы.
  • Informix-ViewPoint - средство доступа к базам данных, позволяет
    непрограммным способом создавать графические формы, отчеты,
    запросы.
    Informix-NewEra - последнее "детище" Informix в области средств разработки, на котором
    сосредоточены в настоящее время значительные усилия компании. Сохранив определенную
    преемственность по отношению к продуктам линии 4GL, NewEra обладает рядом принципиально
    новых свойств, важнейшие из которых - объектная ориентация и инструментарий визуального
    программирования.

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

    приложения. Важнейшие характеристики Informix-NewEra:

  • Многоплатформность, кросс-платформность. Informix-NewEra работает
    в системах MS Windows, OSF/Motif и Macintosh. Приложения или компоненты
    приложений, разработанные на одной платформе, могут работать на других
    платформах.
  • Объектно-ориентированный характер инструмента. Преимущества данного
    подхода - переиспользуемость кода, бизнес-моделирование, хорошая
    приспособляемость приложений к меняющимся требованиям, простота
    сопровождения, интегрируемость с библиотеками от независимых
    поставщиков. Допустимо использование внешних библиотек, разработанных на
    С и С++.
  • Поддержка наряду с объектно-ориентированными разработками
    традиционного структурного программирования.
  • Поддержка групповых разработок. Программисты совместно используют
    библиотеки, файлы исходных кодов и ресурсов. Возможно применение
    системы управления версиями и конфигурациями PVCS (Intersolv).
  • Стилистическое единообразие пользовательского интерфейса
    обеспечивается за счет механизма наследования и поддержания репозитория
    данных. В репозитории хранятся такие элементы интерфейса, как цветовое и
    шрифтовое оформление, маски ввода и форматы вывода данных, правила
    верификации, заголовки и метки столбцов, используемые при выводе, и т. п.
  • Открытость создаваемых приложений по отношению к используемой СУБД.
    В комплект поставки входят библиотеки взаимодействия с СУБД Informix, а
    также с СУБД, доступными через интерфейс ODBC. Определен объектный
    интерфейс для создания других аналогичных библиотек доступа к СУБД.
  • Преемственность по отношению к Informix-4gl. Благодаря существенной
    совместимости языков NewEra и 4gl, возможен перенос приложений 4gl в среду
    Informix-NewEra.
  • Возможность создания распределенных многозвенных приложений, в
    которых обработка данных отделена от обслуживания интерфейса с
    пользователем.
    Комплекс Informix-NewEra включает следующие инструментальные средства:

  • Инструменты визуального программирования - генератор окон и генератор составных


    органов управления;
  • Компиляторы и интерпретатор языка NewEra;
  • Компилятор файлов сообщений и справок;
  • Генератор приложений;
  • Интерактивный символьный отладчик программ на языке NewEra;
  • Электронная документация, доступная в интерактивном режиме;
  • Набор примеров элементарных приложений (рецептов);
  • Демонстрационные базы данных;
  • Вспомогательный продукт Informix-NewEra ViewPoint Pro, который содержит;
  • инструменты администрирования баз данных и репозитория данных NewEra;
  • средства для построения простых приложений без программирования на SQL или каких-
    либо других языках.
    Подробные характеристики основных компонентов Informix-NewEra приведены в последующих
    разделах.

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

  • Используя средства администрирования ViewPoint Pro, создать
    репозиторий приложения, описав в нем связи между таблицами, атрибуты
    внешнего представления данных для таблиц и столбцов - шрифты, цвета,
    заголовки и т. п.
  • Создать при помощи визуальных инструментов макет прикладной системы
    в виде серии окон, отражающей общую структуру приложения и
    пользовательский интерфейс. Описать поведение органов управления окон.
  • Создать программные модули, реализующие классы и процедуры для
    содержательной обработки данных и поддержки некоторых компонентов
    пользовательского интерфейса.
  • Создать файлы сообщений, используемые в приложении.
  • Создать новый проект в рамках генератора приложений, собрать
    приложение.
  • Отладить его при помощи отладчика, возвращаясь по мере необходимости
    к предыдущим шагам.

    NonStop SQL/MP: Параллельная система управления реляционными базами данных

    Ричард Галдерман, Tandem Computers

    (Тезисы доклада)
    В докладе рассматриваются следующие вопросы:


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

    В первой части доклада обсуждается основной набор открытых стандартов, поддерживаемых в
    NonStop SQL/MP. В частности, внимание уделяется возможностям локализации системы с
    использованием национальных языков.

    Вторая часть посвящена архитектурным особенностям системы. Основными качествами
    архитектуры являются ее параллельность архитектуры и высокая степень масштабируемости.
    Этому способствует наличие автоматической оптимизации запроса основанная на языке SQL, в ходе
    которой оценивается целесообразность распараллеливания выполнения запроса.

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

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


    []
    []
    []

    Новые средства администрирования

    Для управления из единой точки многосерверной распределенной средой нужны новые средства
    администрирования. Поэтому вместе с Oracle 7.3 будет поставляться такое средство -
    ENTERPRISE MANAGER. Он придет на смену утилите Server Manager. Enterprise Manager имеет
    GUI интерфейс. Он позволяет анализировать состояние и управлять сетью, администрировать все
    узлы многосерверной архитектуры Oracle, управлять запуском и выполнением работ в различных
    узлах (в том числе и по заранее заданному расписанию), описывать события на серверах, которые
    интересуют администратора, контролировать возникновение этих событий, а также описывать
    действия, которые будут выполняться при возникновении событий. Например, при переполнении
    tablespace на сервере А, там будет автоматически выполняться команда расширение
    tablespace.

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

    Enterprise Manager состоит из базовой части - консоли и группы дополнительных компонент
    (applications). Консоль реализует стандартные функции Server Manager по управлению instance,
    объектами и схемами, безопасностью (привилегии, роли, профили), хранением данных (tablespace,
    rolsback, ...), репликацией, распределением новых версий программ, сетью. Консоль также
    позволяет запускать копирование/восстановление БД, экспорт/импорт и загрузчик. Можно
    выполнять и команды SQL или скрипты.

    Дополнительные компоненты позволяют выполнять мониторинг и настройку БД, собирать
    статистику, просматривать и реорганизовывать пространство в tablespace. Особенно интересна
    компонента Performance Monitor, идущая на смену режиму Monitor в SQL DBA. Она не только
    позволяет динамически отслеживать состояние баз данных, но и представит его в виде диаграмм, а
    также соберет статистику, на основе которой еще одна компонента Oracle Expert выдаст Вам

    рекомендации по настройке БД и подготовит скрипты, выполняющие эту настройку.

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


    ядро СУБД и дополнительные компоненты ядра (опции)
    Oracle7 ServerTrusted Oracle7Parallel Server Option
    Parallel query OptionAdvanced Replication OptionDistributed Option
    Text Server OptionVideo OptionWebServer Option
    Spatial Data Option


    инструментальные средства разработки приложений
    Developer/2000Oracle CALL interface
    Oracle FormsTranslation Manager
    Oracle ReportsSQL*Module
    Oracle GraphicsOracle Precompiler (C, Cobol, PL/I,Ada, Pascal)
    Oracle Book
    Oracle Browser
    Procedural Builder
    SQL*Plus


    средства для конечных пользователей
    Descoverer/2000Oracle Office
    Oracle BrowserOracle Office MHS Gateway
    Oracle DataQuery


    TextServer with Context


    CASE средства
    Designer/2000Oracle CASE Exchange
    Process Modeller
    System Modeller
    System Designer
    Wizards
    Server Generator
    Forms Generator
    Reports Generator


    средства для анализа данных и создания OLAP (Express)
    Oracle Express ServerOracle Financial Analyzer
    Oracle Sales AnalyzerOracle Analyzer


    средства для обеспечения работы продуктов Oracle в компьютерной сети
    Oracle MultiProtocol InterchangeOracle Network Manager
    Sequre Network ServicesOracle Names Server
    Protocol Adapters (TCP/IP, SPX/IPX, DecNet, Async, NetBios, Named Pipes, LU6.2, APPC,
    Banyan Vines, X25, AppleTalk, DCE)


    средства для взаимодействия с пакетами других фирм
    ODBC DriverTransparent Gateways
    Oracle GlueProcedural Gateway
    Oracle Objects for OLE


    продукты для рабочих групп - Workgroup/2000
    Personal Oracle7Workgroup Server7
    Oracle Power Objects


    готовые прикладные системы - Oracle Applications
    Oracle ManufacturingOracle Human Resources
    Oracle Financial


    новые направления
    Oracle Media ObjectsOracle Mobile Agents
    Oracle Power Viewer


    []
    []
    []

    Новые возможности и тенденции

    С.Кузнецов, Центр Информационных Технологий, Открытые системы ()

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

    Все это верно, но как и всегда, не совсем. Можно выделить несколько основных факторов, которые влияли на технологию управления базами данных и построения информационных систем в прошедшем году.

    Первый фактор состоит в постепенном, эволюционном внедрении сравнительно новых технологий в наиболее известные программные продукты управления базами данных. Компании Oracle, Informix, Sybase, IBM, Computer Associates хотя и разными способами оснащают свои серверы объектными механизмами.

    Informix и Computer Associates приобрели готовые постреляционные системы и произвели их интеграцию со своими реляционными серверами.

    Компания Informix выбрала объектно-реляционное направление развития, приобретя систему (и компанию целиком) Illustra. В течение года была выполнена интеграция этой системы с сервером OnLine, результатом чего стало появление объектно-реляционного Универсального Сервера. Похоже, что Informix наиболее близко подошел к уровню все еще не появившегося стандарта SQL-3.

    Компания Computer Associates решила использовать объектно-ориентированный подход для развития своего серверного продукта CA-OpenIngres. CA использует объектно-ориентированную систему Jasmine компании Fujitsu. В отличие от Informix, компания CA не стала производить интегрированный сервер.
    Вместо этого обеспечивается возможность доступа к реляционным базам данных OpenIngres в объектно-ориентированном интерфейсе системы Jasmine. Если учитывать, что CA через систему шлюзов уже сравнительно давно обеспечивает доступ из OpenIngres к таким распространенным "унаследованным" базам данных как CA-Datacom, CA-IDMS, IMS и т.д., то фактически, через Jasmine обеспечивается доступ и к таким базам данных.

    Компании Oracle, Sybase и IBM также объявляют о переходе к постреляционным механизмам доступа к данным, базируясь на объектно-реляционном подходе. Однако эти компании эволюционизируют свои продукты, не прибегая к приобретению готовых постреляционных систем, а развивая собственные программные средства (часто в сотрудничестве с другими компаниями).

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

    Второй фактор заключается в интенсивно развивающемся применении технологии Internet для построения корпоративных систем. Наиболее активно используются информационные службы Всемирной Паутины (World Wide Web - WWW), поддерживающие распределенные гипертекстовые структуры. Web-браузеры предоставляют удобный и легко осваиваемый интерфейс. Базовый язык разработки Web-страниц HTML в совокупности с протоколом взаимодействия Web-сервера и Web-клиента HTTP обеспечивают, в частности, возможности заполнения форм на стороне клиента и передачи заполненных форм серверу.

    Естественно, у пользователей появилось желание получить возможность доступа в интерфейсе WWW не только к гипертексту, но и к обычным базам данных. Этого можно добиться разными способами, например, с использованием CGI-скриптов или API на стороне Web-сервера или с применением Java-апплетов на стороне Web-клиента (рис. 1 и рис.2, соответственно).

    Новые возможности и тенденции

    Рис. 1. Доступ к базе данных на стороне сервера

    Новые возможности и тенденции

    Рис. 2. Доступ к базе данных на стороне клиента

    С другой стороны, все большее число ведущих производителей серверов баз данных обеспечивают в своих продуктах встроенные возможности Web-сервера, тесно интегрированные с возможностями управления базами данных. В частности, в последних вариантах серверов INFORMIX-OnLine обеспечивается не только доступ к базам данных через средства WWW, но и возможность хранения HTML-документов в реляционных базах данных.

    Как кажется, Internet/Intranet-ориентированные информационные системы - это не дань моде, а полностью экономически обоснованный подход. Соответствующая поддержка со стороны серверов баз данных будет продолжать наращиваться.

    Третий фактор - развивающееся применение аналитиками и руководителями корпораций систем оперативной аналитической обработки (OLAP). Для построения таких систем требуется использование очень объемных, накапливаемых в течение долгого времени, обычно хранимых в нескольких разнородных базах данных и многомерных по своей сути складов данных (datawarehouse). Специфика работы со складами данных (очень большой объем, многомерность, частая потребность в агрегированной информации и т.д.) заставляет производителей серверных продуктов применять особую технику, в частности, методы организации индексов, отличных от B-деревьев.

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

    []
    []

    В первом квартале 1996 г.

    В первом квартале 1996 г. фирма Oracle выпустила новую версию своего сервера - Oracle 7.3. Эта
    версия интересна тем, что по многочисленным заявкам пользователей фирма Oracle включила в
    нее почти все улучшения, планировавшиеся для Oracle 8. Практически Oracle 7.3 - это Oracle 8 без
    поддержки объектно-ориентированной модели данных. Большинство улучшений было направлено
    на повышение быстродействия многопользовательской работы, улучшения работы как OLTP так
    и DSS приложений, повышение надежности реализуемых прикладных систем. Эти улучшения
    позволили серверу Oracle резко поднять производительность ( более 11 тыс. транзакций в минуту
    по тесту ТРС C) и достичь на персональных платформах не только лучших показателей по
    производительности, но и минимальной стоимости транзакций.

    Все улучшения в Oracle 7.3 можно разделить на следующие группы:


  • улучшение работы для Data Warehouse ( работа с большими таблицами);
  • улучшение работы с очень большими БД ( свыше 10 терробайт );
  • улучшение работы для OLTP приложений;
  • расширение возможностей языков сервера ( PL/SQL, OCI );
  • новые средства администрирования;
  • прочее ( сложная репликация, обновляемые View, Multithread приложения).

    О современных информационных технологиях

    Прежде, чем перейти к непосредственному изложению представленных материалов, кратко
    остановимся на основных понятиях и терминах, используемых при описаниях современных
    автоматизированных систем (АС).


    Объектная модель NewEra

    Язык NewEra поддерживает основные возможности объектно-ориентированного
    программирования, в частности, наследование и полиморфизм. В языке явно выделены и имеют
    специальное синтаксическое оформление понятия "событие в объекте", "обработчик
    события".

    Объектная модель NewEra допускает более гибкий по сравнению, например, с С++, подход к
    проектированию и применению классов, поскольку функциональность объектов может частично
    определяться непосредственно в программах, использующих данный класс, причем,
    индивидуально для каждого объекта.

    Класс объектов NewEra характеризуется

  • именем
  • набором констант
  • набором переменных
  • набором функций
  • набором событий
    ЗАМЕЧАНИЕ. Во всех последующих примерах программ знаки -- обозначают комментарий до
    конца строки.

    Пример декларации класса:

    CLASS music -- ИМЯ КЛАССА
    -- КОНСТАНТЫ:
    CONSTANT unknown SMALLINT=0
    CONSTANT folk SMALLINT=1
    CONSTANT classic SMALLINT=2
    CONSTANT pop SMALLINT=4
    CONSTANT hard_rock SMALLINT=8
    -- ПЕРЕМЕННЫЕ:
    PUBLIC VARIABLE music_type SMALLINT
    PRIVATE VARIABLE music_title CHAR (32) -- название
    PRIVATE VARIABLE music_code BYTE -- внутреннее представление мелодии
    -- ФУНКЦИИ:
    -- инициализация нового объекта класса music:
    FUNCTION music (music_type SMALLINT: unknown,
    music_title CHAR(32): NULL)
    -- установка названия:
    FUNCTION set_title (title CHAR(32))
    -- опрос названия:
    FUNCTION get_title () RETURNING CHAR(32)
    -- установка кода (внутреннего представления) мелодии:
    FUNCTION set_code (file_name CHAR(*))
    -- СОБЫТИЯ:
    -- воспроизведение мелодии
    EVENT play ()
    END CLASS
    Объекты класса создаются при помощи операторов NEW и COPY, примеры:

    VARIABLE my_melody MUSIC = NEW music(music::folk, "Калинка")
    VARIABLE your_melody MUSIC = COPY my_melody
    Допускается определение нескольких различных функций-обработчиков для одного и того же
    события данного класса. Обработчики могут присваиваться индивидуальным объектам
    динамически.


    Объектная технология

    Объектная технология PowerBuilder позволяет разработчикам быстро создавать объектно-
    ориентированные приложения масштаба предприятия без применения специфических
    трудноизучаемых языков программирования. PowerBuilder полностью поддерживает многоуровневое
    наследование, инкапсуляцию и полиморфизм.

    Для разработчиков информационных систем самым значительным преимуществом объектной
    технологии является впечатляющий скачок вверх производительности благодаря многократному
    использованию кода. Наследование позволяет усложнить объект-предок и автоматически передавать
    добавленные характеристики всем его потомкам. Наследование упрощает также поддержку
    приложений и обеспечивает непротиворечивость.

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

    PowerBuilder поддерживает полиморфизм, позволяя одним объектам посылать одинаковые
    сообщения другим объектам похожих, но неизвестных типов. PowerBuilder также поддерживает
    перегрузку функций.


    Объектно-ориентированный подход и современные мониторы транзакций

    В. Индриков, АО ВЕСТЬ

    Объектно-ориентированный подход и мониторы транзакций? А где, собственно, связь? Если с ООП все, вроде бы, ясно, то мониторы - вопрос темный, да и, кажется, вообще из другой области. Зачем они вообще? "А затем," - отвечают нам, - "чтобы обеспечить высокую пропускную способность системы и повышает ее устойчивость к сбоям." "Помилуйте," - локтем отодвигает предыдущего оратора создатель сервера баз данных, - "мы это и без них прекрасно умеем - и на кластерах работаем, и транзакции мониторим." Тут вам и диспут, и острота схватки. Говорят и такое: "Многие ..., кто ... выбирает мониторы транзакций, применяет их не по назначению. Не так часто мониторы транзакций используются ради того, для чего они и предназначены, конкретно - поддержки сотен или тысяч одновременно работающих пользователей - такие внедрения составляют не более 1% рынка. Все остальные примеры свидетельствуют о том, что мониторы занимаются асинхронной передачей сообщений или играют роль связующего программного обеспечения в разнородных средах." (DATABASE Journal, N2 1996 стр. 77, перевод мой).

    В этом изречении содержится, как минимум, две мысли. Первая - есть альтернативы мониторам транзакций. Вторая, спорная - мониторы предназначены для обработки тысяч транзакций на одной системе и ничего более. Самое забавное, что и те, кто продает мониторы, чаще всего думают также. И спорю с ними не я, а как раз те, кто применяет эти мониторы, и, если верить тексту, 99% пользователей использует их отнюдь не ради тех возможностей, которые "и так присутствуют в серверах БД." Я даже позволю себе предположить, что они, пользователи, нуждаются в мониторе транзакций, поскольку тот является средой разработки распределенных приложений. Средой, которая, очевидно, имеет какие-то плюсы.

    И я даже готов был бы согласиться с тем, что среда эта не является объектно-ориентированной, если бы не обратившее на себя внимание пугающее сходство CSI (Client/Server Interactions) диаграмм в документации на монитор TopEnd и диаграмм сценариев в объектно-ориентированных методах Буча и Fusion.
    Речь не о принципиальном сходстве, это полбеды, а об изобразительном - повернув CSI на девяносто градусов против часовой стрелки, вы не найдете разницы, обозначения убийственно идентичны.

    Причина в том, что, как только разговор выходит за рамки отношений между классами, а точнее, единственного, пожалуй, рассматриваемого в них вида отношений (наследования), большинство из ныне здравствующих ОО методов (почему-то их постоянно пытаются называть методологиями) предлагают набор изобразительных средств, существенно превосходящий по возрасту ОО подход - сценарии и диаграммы перехода состояний, анализ доменов и т.д. Причем в 3 из 5 случаев оказывается, что наследование существует само по себе, а все остальное - в стороне. Блистательным, с моей точки зрения, примером конгломерата из слабо связанных между собой подходов является метод Гради Буча. Наследование объявляется ключом к объектно-ориентированному подходу, все остальное - "недоразвитым", объектно-базирующимся подходом (вот вам еще одна загадка - что лучше, базироваться на объектах или ориентироваться на них?), и в то же самое время Рамбо (метод OMT) является одним из немногих, кому пришла в голову нестандартная мысль - сценарии и диаграммы перехода суперкласса должны наследоваться в подклассах. Между тем, даже и в этом случае мы далеки от разрешения всех проблем - имеет место эффект расщепления состояния в подклассе (state partitioning - S.Matsuoka, K.Wakita, A.Yonezawa, Inheritance Anomaly in Object-Oriented Concurrent Languages, University of Tokyo, 1991), заставляющий переопределять методы суперкласса. Одной из причин является то, что само понятие "состояние" никак не определяется, поэтому, что означает "унаследовать состояние" или "унаследовать переход", остается за рамками ОО метода. Да и само по себе наследование суть целый букет проблем: self проблема, конфликт с требованием атомарности операций, переписывание (overriding) методов по принципу "все или ничего" вместо декларированного в ООП "уточнения", трудности с интеграцией с СУБД, трудности в реализации множественных представлений (views) и координированного выполнения и т.д. (см, например, M.Askit, M.Bergmans Obstacles in Object-Oriented Development, TRESE Project, University of Twente; H.


    Lieberman, Using Prototypical Objects to implement shared behavior, OOPSLA '86).

    Объектно-ориентированный подход и современные мониторы транзакций

    Илл. 1

    Крайне интересной попыткой разрешить многие из трудностей с реализацией наследования и на деле позволить применять ООП в больших программных проектах (programming in large), является модель CFOM (Composition-Filters Object Model), разрабатываемая в Университете Твенте, Нидерланды. Она доводит до кристальной чистоты старую идею, гласящую, что сообщения, передаваемые объекту, и методы, обрабатывающие эти сообщения - не обязательно одно и то же, а сообщение представляет самостоятельный интерес. CFOM разводит объект-ядро (kernel object) и интерфейс. Объект-ядро полностью инкапсулирован, его структура недоступна извне, открыты только методы, но и те - не для всех, а только для интерфейса, являющегося своего рода оболочкой объекта. Интерфейс может содержать объекты (секция internals) или ссылки на внешние объекты (externals), а также фильтры. Фильтры задают правила обработки входящих (inputfilters) и, мало того - исходящих (outputfilters) сообщений (Ошибка! Источник ссылки не найден.). В простейшем случае сообщение передается ядру на выполнение, и выглядит это так: inner.doSmth. Inner - это и есть ядро. В общем же случае сообщение, попав в сито фильтров, может быть также модифицировано либо переадресовано одному из объектов, определенных в теле интерфейса, или внешним объектам.

    Модель CFOM смело можно отнести к числу "недоразвитых" - вводя понятие объекта и класса, ее создатели отказались от введения отношений наследования. Сделано это по причинам, кратко уже упомянутым выше, и развернутое описание которых займет слишком много места. Каким же образом создатели CFOM ухитряются обойтись без наследования? Очень просто - включение и делегирование. Если вы хотите, чтобы объект objA класса A предоставлял и сервис класса B, вы включаете объект objB класса B в секцию internals интерфейса и помимо возможных прочих фильтров указываете такой: {inner.*, objB.*}. Понять, что делает этот фильтр, легко - все сообщения ('*' и означает "все"), распознаваемые ядром, передавать ядру, все сообщения, распознаваемые объектом objB (т.е.


    все сообщения класса B), передавать objB. С печально известными проблемами множественного наследования здесь сталкиваться не приходится - фильтры выполняются слева направо и сверху вниз. Если набор методы A и B пересекаются, и вы хотите, чтобы сообщение mess1 обрабатывалось в B, а не в A, то фильтр становится таким: {objB.mess1, inner.*, objB.*}. Если objB объявлен в секции externals, то это ссылка на внешний объект, и в этом случае фильтр {..., objB.*, ...} будет реализовывать делегирование в чистом виде.

    На самом деле синтаксис фильтров несколько более сложен, и важную роль играют здесь условия (conditions) - особая группа методов ядра, не имеющих параметров и вырабатывающих значение булевского типа. Тот или иной фильтр может срабатывать или быть проигнорирован в зависимости от условий. Введение условий позволяет в рамках одной модели описать и переходы состояний - изменение состояния объекта и даже история изменения состояний объекта может находить свое отражение в изменении условиях, а те будут задавать тот или иной сценарий обработки сообщений. Введены также псевдопеременные: sender (№1 на Илл. 2) - идентифицирует объект, пославший сообщение; упоминавшаяся уже inner (№4 на Илл. 2) - ядро, т.е. собственно реализация той или иной совокупности сервисов; self - означает то же самое, что и self в Samlltalk или this в C++ - ссылка на сам объект в теле программного кода, принадлежащего этому объекту; message (№5) - метаданные, т.е. имя сообщения и список аргументов; server (№2) - объект, который первым принял сообщение. В приведенном выше примере сервером является объект objA. Если бы objA в свою очередь был бы включен в интерфейсную часть объекта objX (неважно, где бы он был объявлен - в секции internals или externals), то сервером стал бы objX. Сообщение, проходя через множество фильтров, может много раз поменять "направление", однако значение server не изменится. Данная псевдопеременная помогает объекту разобраться, в каком контекcте он получает сообщение.


    Например, public и private, реализованные в C++, легко воспроизводятся с использованием server.

    Объектно-ориентированный подход и современные мониторы транзакций

    Илл. 2

    CFOM позволяет описать как статические свойства объекта, так и динамически изменить их. Во всяком случае self и inner могут быть статически связаны компилятором, а sender и server - в том случае, если они представлены константами. CFOM представлена языком Sina (по имени Ибн Сины), а тот, в свою очередь, реализован в рамках среды Smalltalk. Между тем, ничто не мешает использовать CFOM как метод моделирования. Метамодель CFOM в принципе может быть представлена средствами другой ОО модели, и выбрав CASE пакет, позволяющий писать скрипты для обработки метаданных, например, Rational Rose (методы Booch, OMT, UML) или ParadigmPlus (компания Platinum - Booch, OMT, UML, Fusion, Shlaer/Mellor, Martin/Odell OOIE, Coad/Yourdon), можно искусственно расширить оную, "другую", модель средствами CFOM (вот только готовы ли вы отказаться от наследования?).

    Чем так удивительно хороша CFOM? Тем, что она позволяет изолировать друг от друга вещи несвязанные, и которые, тем не менее, оказываются поневоле перемешаны в одном и том же программном коде. Ядро в CFOM - это суть объекта, то, что он делает, все его прикладное наполнение, если угодно - бизнес-логика. Все остальное вынесено вовне: коммуникации между объектами, делегирование (читай - диалоги) выполнения тех или иных функций внешнему, в том числе и удаленному объекту, синхронизация и обеспечение конкурентного режима, динамическое преобразование сообщений и множественные представления (view). Поясним это на примерах:

    Начнем с последнего - в зависимости от условий (conditions), а также от того, какой именно объект (sender) посылает запросы, принимающая сторона может в простейшем случае открывать или закрывать те или иные слоты, а в случае более сложном - динамически изменять цепочку обработки сообщения. Здесь вам и разграничение прав доступа, и базы данных, и модная ныне тема - деловые процессы (они же документооборот).

    Необходимо заставить объект objB посылать сообщение не локальному внешнему объекту objC (класс C), а такому же, но удаленному, objCRemote. Включив objB в objA и задействуя в последнем фильтрацию исходящих сообщений, вы, не изменяя кода objB, организуете распределенные вычисления.

    Объект objCRemote (напоминаю - класса C) может обслужить одновременно не более одного обращающегося к нему по сети клиента. Рассмотрим объект objM, принимающий все предназначенные objCRemote сообщения, организующего одну или множество очередей запросов и передающего эти запросы одному или нескольким объектам класса C. В результате будет обеспечен либо последовательный доступ к сервису класса C (множество клиентов - один экземпляр класса C), либо параллельный (каждому клиенту - собственный экземпляр), либо смешанный (экземпляров меньше, чем клиентов, запросы буферизуются)

    Все посылаемые сообщения предварительно протоколируются

    Необходимость изменения любого из аспектов - параллелизм, синхронизация, сценарий, замена локального вызова на удаленный - требует изменения лишь локального участка модели или кода, остальные не затрагиваются. Между тем, если вы пишете на Ada, то прикладная логика перемешана с логикой распараллеливания и синхронизации. А если вам захочется переписать программу на предмет возможности использования DCE/RPC, то заранее примите мои соболезнования.

    Ну а мониторы-то тут причем? Или автор пытается подражать О'Генри - ни королей, ни капусты в романе, зато в заголовке - пожалуйста. На самом деле самые внимательные уже смогли найти в капусте (ОО методы) королей (мониторы). Вернемся к примерам 3 и 4. Что такое objM, который принимает от клиентов, протоколирует, буферизует и перенаправляет запросы? Что он, скажите мне, как не монитор транзакций?

    И, коль скоро в теме заявлены современные мониторы, то нельзя не вспомнить о предельно современном, а именно - еще в "Памперсах" разгуливающем Microsoft Transaction Server (MTS). Начнем с того, что MTS целиком базируется на архитектуре COM - до удивления близкой рассмотренной выше CFOM (и там, и там расширение возможностей класса осуществляется посредством включения и делегирования - см.


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

    Application Component (AC) сосредотачивает в себе прикладную логику. Его смело можно уподобить ядру объекта в CFOM. Ничего относящегося к распараллеливанию, опросу ресурсов и т.д. здесь нет. Пользуясь любым инструментом, позволяющим делать ActiveX компоненты, разработчик создает AC такой же, как и для однопользовательского локального приложения - все проблемы, не связанные с собственно бизнес-логикой, берет на себя монитор транзакций. Приложение, управляемое MTS, может работать с разными видами ресурсов, различаются два вида последних: Resource Managers (RM) и Resource Dispensers (RD). Разница в том, что RM устойчив к сбоям (последняя буква в ACID - atomicity, consistency, isolation, durability), а RD - не дает никаких гарантий, т.е. это ресурс "вообще". В качестве интерфейса к ресурсам MTS использует все тот же OLE.

    Похожую концепцию предлагают и другие мониторы, такие как IBM Transaction Server и NCR TopEnd. Начнем с TopEnd. Созданный компанией NCR (изначально - под другим названием) и радикально переработанный где-то в 91-м, компанией, которая трудится с 60-х, и разные мониторы которой стоят на 40000 серверов, TopEnd учитывает сложившиеся реалии: клиент-сервер и графические станции - с одной стороны, а неуничтожимые мейнфреймы, терминалы и DOS - с другой. TopEnd предлагает два вида серверов - managed server (MS) и standard server (SS). SS служит исключительно целям поддержки процесса переноса уже имеющегося сервера приложений, разработанного каким-либо иным способом, на монитор TopEnd. Работать с SS - занятие достаточно утомительное, поскольку распараллеливанием обслуживания запросов в этом случае занимается сам программист.


    Другое дело MS - ведь он же "managed", т.е. его выполнением управляет сам монитор. MS выглядит практически так же, как и любая другая функция, написанная на C. Он подключается к TopEnd, и всей его дальнейшей жизнью управляют двое - TopEnd и администратор системы.

    IBM Transaction Server двуглав, как российский герб. С одной стороны это Encina, монитор, также разработанный в начале 90-х компанией Transarc (являющейся теперь частью IBM) и реализующий архитектуру OSF/DCE. С другой стороны это CICS, известный монитор IBM, установленный на 70000 серверов и мейнфреймов. Если добавить сюда IMS-TP, TPF и Encina, то дух захватывает от числа инсталляций у IBM. Transaction Server базируется на сервисах и ядре Encina, обеспечивая в то же время и совместимость с CICS. В любом случае разработчику доступны и CICS, и Encina в "чистом виде". Encina работает с любым XA ресурсом, но не только. Например, входящая в базовый набор структурированная файловая система (SFS) не является XA ресурсом. SFS представляет из себя некоторую комбинацию DCE файловой системы с ISAM. Немного отклоняясь в сторону, скажу, что перенос наработок с Fox, Clipper, Paradox, Btreive на Encina и SFS существенно проще, чем на реляционный сервер БД. Encina и Microsoft оказываются в некотором смысле даже ближе , чем можно ожидать. В Encina используется язык описания интерфейсов (IDL), принятый в OSF/DCE при работе с удаленным вызовом процедур (RPC). Microsoft реализовал DCE/RPC в самой первой версии Windows NT, и IDL, используемый при описании COM интерфейсов (отчасти и CORBA IDL) более, чем близок к DCE/RPC IDL. Таким образом, некий набор сервисов рассматривается в Encina как целое, как интерфейс, и несложно показать, как увязать технику программирования данного монитора транзакций с ОО подходом CFOM (возможно, и каким-либо еще). В TopEnd нет понятия интерфейса, однако сервисы тоже не рассыпаны сами по себе. Существуют по сути очень близкое понятие product - совокупность сервисов (функций), помимо этого - function (например, "оформить билет") и function qualifier.


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

    Итак, оставим в стороне разговоры о производительности и надежности - мониторы транзакций упрощают жизнь разработчику. Я ненамного перегну палку, если скажу, что человек, приступающий к созданию банковской, складской, бухгалтерской и т.д. задачи думает о ее функциональности, а не о том, как она будет работать в сети. То есть он пишет однопользовательскую по сути программу. В результате она прекрасно работает для, скажем, трех пользователей. А вот потом начинаются проблемы. Серьезным образом переработать приложение не удается, потому что параллельно с решением задачи производительности обычно требуется и доводить логику. Мониторы же (как минимум - рассмотренные выше) позволяют вынести все эти заботы на администратора системы. Мне как-то подсказали интересную аналогию - программирование для Windows. В одном случае вы должны писать WinMain и т.д., самостоятельно обрабатывать входящие сообщения. Используя же Delphi, VB, PowerBuilder или специально разработанную библиотеку C/C++ вы будете создавать обработчики событий (причем только тех, которые вас интересуют), не заботясь о том, откуда они берутся. Очень похоже

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


    А даже сравнивая между собой только мониторы, которые, казалось бы, делают одно и то же, выясняешь, сколь по-разному можно это делать. О сравнении с СУБД и говорить нечего. Есть серверы БД, отводящие на каждое подсоединение 50КБ, есть те, что отводят 250КБ, а есть и такие, что отдают по 2МБ - так с каким сравнивать? Есть и ограничения, которые не слишком о себе заявляют, пока речь идет о централизованной задаче, например, пространство имен. О Microsoft TS говорить до появления Cairo преждевременно, но о других можно. TopEnd предлагает единое (вся сеть - один домен) глобальное пространство имен - вы обращаетесь к сервису, не зная, на каком сервере он "хранится" и будет выполняться. Encina интегрирована со службой каталогов DCE - CDS и позволяет, в случае необходимости разбивать сеть на ячейки, однако и в этом случае речь идет об именах, а не о "месторасположении сервиса". В случае РСУБД мы имеем нечто похожее на "имя_сервера.имя_базы(или схемы).имя_владельца.имя_таблицы(или хранимой процедуры". Репликация процедур смягчает, но не снимает эту проблему, а она о себе непременно заявит в большой и распределенной задаче.

    Еще пример, связанный со временем жизни приложения. В связи с новым постановлением изменяется порядок расчетов (начисления и т.д.) чего-нибудь. Транзакции, начинающиеся с 1 апреля, проходят по новой схеме. В то же время начатые раньше этой даты, завершаются по старой. В этом случае до завершения всех "старых" транзакций, вы имеете дело с разными версиями сервиса, а не с разным сервисом. Имея доступ к метаинформации , конкретно - о дате посылки сообщения, начала транзакции и т.д., вы сможете решить эту проблему достаточно безболезненно. Имеете ли вы такую возможность в РСУБД? Или вам придется, чертыхаясь, срочно переделывать приложение и сопровождать его в этом виде в течение времени завершения всех "старых" транзакций. А потом, холодея, вы будете ждать нового изменения? А можете ли вы управлять на программном уровне общей памятью? А как насчет разграничения доступа - в Encina, например, реализовано 6 уровней плюс седьмой, если в системе установлена среда DCE.


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

    Еще один вопрос - "другие" средства middleware, "делающие ненужными мониторы". Во-первых, это появляющиеся в новых версиях пакетов для разработки front-end программ средства создания серверов приложений. Эта альтернатива действительно интересна, но не выше уровня рабочей группы. В дополнение к перечисленным выше ограничениям здесь мы не видим поддержки безотказной работы и балансировки нагрузки. По поводу серверов приложений в архитектуре CORBA можно сказать одно - сама по себе эта архитектура не является альтернативой, напротив - требует наличия монитора (как минимум, в виде соответствующих сервисов), но только на этот раз - CORBA совместимого. Хорошим примером является Microsoft - владея полностью технологией COM (OLE), компания почему-то создает именно монитор транзакций. Ну а Encina работает с SOM (реализация CORBA от IBM).

    В числе других "убийц" чаще всего называют ПО передачи сообщений. Так вот MOM (message -oriented middleware) не предоставляет технологии создания серверов приложений - речь идет только о гарантированной доставке сообщений, доставке в оговоренный интервал времени, частичной поддержке транзакций. Но кто (что) укладывает сообщения в очереди и кто занимается их выборкой - это вне компетенции MOM. Оно либо должно быть внедрено в СУБД, монитор транзакций и т.п., либо работать совместно с ними или какими-либо другими серверами приложений. Есть примеры и того, и другого - опция Recoverable Queuing System (RQS) для TopEnd, и Recoverable Transaction Queuing (RTQ) - неотъемлемая часть Encina. RTQ и RQS обеспечивают отложенное выполнение запроса. Компания IBM поставляет MQSeries - в чистом виде MOM - наверное, чтобы убить Encina. Ну, а если всерьез, то MQS чаще всего служит для связывания между собой разных мониторов или иных серверов приложений.


    TopEnd никогда не будет работать с RTQ, а Encina - с RQS. А MQSeries, являясь с точки зрения монитора транзакций XA-ресурсом, может их объединить, "приклеив" также Lotus Notes, приложение, разработанное на Distributed PowerBuilder или Distributed Visual Basic. После появления MQS для Windows'95 речь уже заходит о поддержке мобильных клиентов (мониторы этого не могут). MQS поддерживает собственные транзакции, однако распределенные, вовлекающими несколько узлов - нет, и в роли координатора может выступать монитор. Таким образом, MQS может быть существенным подспорьем монитору в плане поддержки отложенного, асинхронного в полном смысле, выполнения (отложенного - не обязательно на послезавтра, речь может идти и о десятой доле секунды) как между сервером и сервером, так и между клиентом и сервером. MQS может использоваться в качестве интегрирующей среды между другими классами серверов приложений. Однако альтернативой мониторам транзакций MOM не является, что подтверждается простым сравнением функционального набора того и другого.

    Таким образом, мониторы транзакций живы и, судя по всему, будут жить, пусть даже и в другом обличье. Мониторы транзакций являются не только средством поддержки, мониторинга и администрирования времени выполнения. Современные мониторы транзакций предоставляют очень надежную (с точки зрения технологии программирования) платформу разработки приложений. Проблема в том, для приложений из 5 экранных форм сказывается непривычность. А вот выигрыш сказывается позже и в по-настоящему сложных системах. Данная платформа разработки не является объектно-ориентированной в общепринятом смысле - нет речи о классах и наследовании. Однако она перекликается с наиболее продуманными ОО методами. Она близка последним не по букве, но по духу. В конечном итоге это и является главным, так как и многочисленные создатели ОО методологии, и создатели мониторов транзакций пытаются решить проблему создания приложений функционально сложных, распределенных, разнородных и сохраняющих свою жизнеспособность в течение долгого времени.

    ВЕСТЬ АО

    115446, Москва, Коломенский проезд,1а

    тел: (095) 115-6001, факс: (095) 112-2333

    []
    []
    []

    Объектно-реляционная система: лучшее из обоих систем.

    Illustra Server - первая в мире объектно-реляционная СУБД. Сервер поддерживает объектно-
    ориентированное управление сложными типами данных, но в то же время предоставляет
    эффективный язык запросов, основанный на расширении индустриального стандарта SQL. Он
    поддерживает быструю разработку приложений, значительно повышая их качество. Значительно
    снижается стоимость поддержки приложений, так как Illustra работает как единый репозиторий
    объектов.

    Объектные возможности Illustra.


  • Определяемые пользователем типы данных.
  • Множества и массивы как конструкторы типов.
  • Функции, определяемые пользователем (методы).
  • Уникальные идентификаторы объектов.
  • Методы доступа, специфичные для доменов.
  • Наследование.
  • Полиморфизм.

    Реляционные возможности Illustra.


  • Оптимизированный язык запросов (SQL).
  • Представления.
  • Обеспечение безопасности с помощью предложений grant/revoke.
  • Возможности одновременной работы пользователей.
  • Транзакции.
  • Восстановление после системных сбоев и сбоев носителей.


    Объектно-реляционные базы данных

    А. Волков, Компания "Корпоративные Системы"

    В последние годы много говорится о системах баз данных следующего поколения. Нужны ли они? Какими они будут? Над решениями этих проблем работают и ученые и исследователи в коммерческих компаниях. Естественно, концепция баз данных следующего поколения должна быть выработана специалистами из научных лабораторий, реализация же - за разработчиками промышленных систем. И если первые занимаются этой проблемой уже давно, вторые только приступили к выпуску продуктов

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

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

    []
    []
    []

    Объекты, элементы управления и события

    Разработка в среде PowerBuilder базируется на создании объектов, элементов управления и событий.
    Приложения PowerBuilder состоят из объектов (таких как окна, Окна данных, меню и объекты
    пользователя) и элементов управления (таких как Командные кнопки(CommandButtons) и
    Радиокнопки (RadioButtons)).

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

    PowerBuilder - система, управляемая событиями. Разработчики определяют атрибуты, а также
    поведение объектов и элементов управления в соответствии с конструкцией приложения.


    Объекты

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

    Типы данных, поддерживаемые SQLBase, приведены на рис. 1. Следует отметить, что тип данных
    CHAR в SQLBase не отличается от VARCHAR (в обоих случаях СУБД не хранит пустые места в
    колонках) и поддерживается, в основном, для совместимости с DB2.

    SQLBase поддерживает стандарт SQL-89 с многочисленными расширениями.

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

    Рис. 1. Типы данных SQLBase

    Тип Данных
    Описание
    Размерность
    Примечание
    CHAR (или VARCHAR)
    		Строковый тип
    		до 254 байт
    		Имеет вид CHAR(3). Пустые места не хранятся
    LONG VARCHAR
    		Строковый тип
    		неограниченный размер
    		Для этого типа не поддерживаются
    предложения WHERE, ORDER BY и многие функции СУБД.
    NUMBER
    		Числовой тип
    		до 15 цифр
    		Суперсет всех числовых типов SQLBase
    DECIMAL
    		Числовой тип с фиксированной точкой
    		до 15 цифр
    		Имеет вид DECIMAL
    (размер, десятичных знаков). SQLBase не поддерживает тип
    CURRENCY. Используйте для этого DECIMAL(15,2)
    INTEGER
    		Числовой целый тип
    		до 10 цифр
    SMALLINT
    		Числовой целый тип
    		до 5 цифр
    DOUBLE PRECISION
    		Числовой тип
    		до 15 цифр
    		Для чисел с плавающей
    точкой
    FLOAT
    		Числовой тип
    		до 15 цифр
    		Отличается от DOUBLE
    PRECISION указанием количества значащих цифр
    DATETIME (или TIMESTAMP)
    		Дата/Время
    		 Точность временной
    компоненты - до 1 мксек
    DATE
    		Дата
    TIME
    		Время
    		 Точность до 1 сек
    ?
    ? SQLBase существуют пользователи трех уровней: CONNECT, RESOURCE и DBA.
    Особенности уровня доступа к данным и другие привилегии каждой категории пользователей
    приведены на рис. 2.

    Рис. 2. Типы пользователей SQLBase

    Тип Пользователя
    Описание
    SYSADM
    		Создает пользователей и устанавливает их
    пароли и права доступа
    DBA
    		Выдает, изменяет и отнимает права доступа к
    объекту БД для любого пользователя
    RESOURCE
    		Создает и удаляет объекты БД. Выдает,
    изменяет и отнимает права доступа к этим объектам для других
    пользователей
    CONNECT
    		Имеет доступ к объектам, но не может их
    создавать

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

    Рис. 3. Таблицы системного каталога SQLBase

    Таблица
    Описание
    SYSCOLAUTH
    		Права обновления колонок
    SYSCOLUMNS
    		Колонки базы данных
    SYSCOMMANDS
    		Хранимые команды и хранимые
    процедуры
    SYSEVENTS
    		Системные события таймера (в текущей
    версии не используются)
    SYSEXECUTEAUTH
    		Права выполнения хранимых
    процедур
    SYSFKCONSTRAINTS
    		Внешние ключи (foreign keys)
    SYSINDEXES
    		Индексы
    SYSKEYS
    		Колонки индексов
    SYSPARTTRANS
    		Незавершенные распределенные транзакции
    SYSPKCONSTRAINTS
    		Первичные ключи (primary keys)
    SYSROWIDLISTS
    		Сохраненные множества результатов
    (result sets)
    SYSSYNONYMS
    		Синонимы объектов базы данных
    SYSTABAUTH
    		Права доступа к таблицам
    SYSTABCONSTRAINTS
    		Ограничения ссылочной
    целостности
    SYSTABLES
    		Таблицы и views
    SYSTRGCOLS
    		Колонки триггеров
    SYSTRIGGERS
    		Триггеры
    SYSUSERAUTH
    		Пользователи БД и их пароли
    SYSVIEWS
    		Описание views в виде SQL
    запросов

    Обработка больших бинарных объектов (BLOB)

    Informix поддерживает две разновидности BLOB-значений - TEXT и BYTE. Значения типа TEXT
    отображаются в суперполях в виде текста, если они содержат только печатные символы. Значения
    типа BYTE автоматически не отображаются. Суперполя для обоих типов имеют атрибут
    blobEditor, в котором указывается имя внешней программы редактора.


    Обратное проектирование (Reverse engineering)

    Обратное проектирование, то есть восстановление информационной модели по существующей базе
    данных, используется при выборе оптимальной платформы (rightsizing) для существующей настольной
    (desktop) базы данных или базы данных на mainframe, а также при расширении (или модификации)
    существующей структуры, которая была построена без необходимой сопроводительной
    документации. После завершения процесса восстановления модели ERwin автоматически
    "раскладывает" таблицы на диаграмме. Теперь можно выполнять модификации уже с использованием
    логической схемы - добавлять сущности, атрибуты, комментарии, связи и т.д. По завершении
    изменений одна команда - синхронизировать модель с базой данных - актуализирует все проведенные
    изменения.

    Построение модели может быть выполнено как на основании данных каталога базы данных, так и на
    основании пакета операторов SQL, с помощью которого была создана база данных.


    выделяются следующие основные этапы процесса

    В соответствии с общей архитектурой CASE-системы DESIGNER/2000, изображенной на рис.3,
    выделяются следующие основные этапы процесса разработки системы: моделирование и анализ
    деловой деятельности, разработка концептуальных моделей предметной области, проектирование
    прикладной системы и реализация.



  • Анализ деловой деятельности
  • Концептуальное моделирование
  • Проектирование системы
  • Генерация приложений

    		• ИнформацияПроцессы
    выделяются следующие основные этапы процесса

    Общая характеристика продуктов Oraсle

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

    Средства Oracle позволяют надежно защитить эти данные, обеспечить их целостность и
    непротиворечивость. Продукты Oracle работают более чем на ста вычислительных платформах
    (компьютер + операционная система), поддерживают все основные промышленные сетевые
    протоколы и графические оконные среды. Это позволяет Вам с минимальными затратами
    переносить готовые приложения с одной платформы на другую. Например, разработав
    приложение на однопроцессорном персональном компьютере с MS Windows, Вы можете далее
    выполнять его на Unix - машинах, больших IBM машинах, SMP и MPP архитектурах, высоко
    надежных и кластерных архитектурах.

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

    С помощью средств Oracle Вы сможете реализовать оперативную обработку (OLTP - системы),
    системы поддержки принятия решений (DSS - системы) и системы накопления и анализа больших
    объемов данных (Data Warehouse и OLAP - системы). Oracle поддерживает все основные
    стандарты:


  • FIPS 127-2, ANSI X3-135.1992 - для БД;
  • NCSC TDI C2, B1, ITSEC F - C2/E3, F - B1/B3 - по защите данных;
  • OSI, DNSIX (MaxSix), SNMP - для сети;
  • ODBC, TSIG, X/Open, DCE, DDE, OLE, OCX, VBX - для взаимодействия
    приложений.


    Общие характеристики

    SQLBase - это реляционная многопользовательская СУБД типа клиент-сервер фирмы Gupta
    Corporation (Menlo Park, USA). Она предназначена для использования в качестве сервера баз
    данных в локальных вычислительных сетях на базе персональных компьютеров. SQLBase
    ориентирована прежде всего на сети масштаба малого и среднего предприятия с количеством
    одновременно обращающихся к СУБД рабочих станций от 20 до 100, а также на подразделения
    (филиалы, отделения) крупных организаций. В целом СУБД такого класса называют серверами
    для рабочих групп (Workgroup Server).

    SQLBase поддерживает базы данных размером до 4 Гбайт в виде консолидированного файла и до
    512 Гбайт в разделенном режиме (partitioned database mode). Сервер SQLBase может работать с
    базами данных, расположенными на одном компьютере, но позволяет располагать и распределять
    их на разных физических и логических дисках и других носителях (оптические накопители и CD-
    ROM).

    СУБД фирмы Gupta отличается простотой установки и настройки, малым потреблением
    системных ресурсов, что позволяет устанавливать и эксплуатировать SQLBase на недорогих
    компьютерах. Так SQLBase for NetWare может работать под управлением NetWare 3.12 на машине
    с 8 Мбайт оперативной памяти и при этом эффективно обслуживать 10-15 пользователей.

    Режим работы SQLBase, параметры размещения его баз данных, а также описание сетевых
    протоколов сервера содержатся в конфигурационном файле SQL.INI, который имеет структуру
    стандартного INI-файла системы Windows. SQL.INI является универсальным файлом
    конфигурации для всех продуктов Gupta и включает в себя секции описывающие поведение
    различных серверов и клиентов Gupta.


    Обзор продукта

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


    История развития SQL Server
    SQL Server 4.21aОбзор продуктаSQL Server 6.0Обзор продуктаSQL Server следующие версии
    NT ServerNT ServerCairo

  • Симметричная архитектура сервера (SMP)
  • Графические средства администратора
  • Унифицированная регистрация в сети
  • Расширенные хранимые процедуры
  • Интеграция с эл. почтой
  • SQL Object Manager
  • Service Manager
  • RPC для доступа к БД
  • Performance monitor
  • ANSI89 Level 1

    		•
  • Тиражирование данных
  • Параллельная обработка БД
    Сканирование, индексирование, создание и восстановление страховых копий, загрузка
  • Поддержка очень больших БД
    Оптимизатор, опережающее чтение, управление блокировками
  • Распределенное управление
  • OLE automation
  • ODBC курсоры
  • Расширения языка
  • ANSI92 (95.1)
  • X/A (95.1)

    		•
  • Унифицированное хранение данных
  • Параллельные запросы
  • Distributed joins
  • Доступ к данным OLE
  • Проверка версий, блокировка на уровне записи
  • Защита средствами Cairo, каталоги
  • Пользовательские функции
  • Интеграция с репозитарием объектов



    • Обзор средств проектирования информационных систем

    А.М.Вендров, Центральный банк РФ

    Цель данного доклада - попытаться описать и обосновать один из возможных подходов к анализу и выбору средств проектирования информационных систем достаточно крупного масштаба (здесь намеренно не используется термин "CASE-средство", поскольку большинство известных CASE-средств в лучшем случае позволяют описать будущие приложения лишь в самом общем виде).
    Конечный результат выбора ни в коем случае не следует рассматривать как нечто абсолютное, он отражает лишь мнение конкретного коллектива разработчиков, утвердившееся на заданном
    временном интервале.

    Под средствами проектирования информационных систем (СП ИС) будем понимать комплекс
    инструментальных средств, обеспечивающих в рамках выбранной методологии проектирования
    поддержку полного жизненного цикла (ЖЦ) ИС, который включает в себя, как правило,
    стратегическое планирование, анализ, проектирование, реализацию, внедрение и эксплуатацию.
    Каждый этап характеризуется определенными задачами и методами их решения, исходными
    данными, полученными на предыдущем этапе, и результатами. При анализе СП их следует
    рассматривать не локально, а в комплексе, что позволяет реально охарактеризовать их
    достоинства, недостатки и место в общем технологическом цикле создания ИС.

    В общем случае стратегия выбора СП для конкретного применения зависит от следующих
    факторов:


  • характеристик моделируемой предметной области;
  • целей, потребностей и ограничений будущего проекта ИС, включая
    квалификацию участвующих в процессе проектирования специалистов;
  • используемой методологии проектирования.

    Тенденции развития современных информационных технологий приводят к постоянному
    возрастанию сложности ИС, создаваемых в различных областях экономики. Современные
    сложные ИС и проекты, обеспечивающие их создание, характеризуются, как правило, следующими особенностями:


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

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

    Методология проектирования определяется как совокупность трех составляющих:


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

    На выбор СП могут существенно повлиять следующие особенности методологии
    проектирования:


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

    ODBC-интерфейс

    Спецификация ODBC фирмы Microsoft определяет универсальный промежуточный интерфейс
    между приложениями-клиентами в среде Windows и Windows NT и различными реляционными
    базами данных.

    ODBC API представляет собой набор вызовов функций. Доступ к базе данных в нем задается
    операторами SQL, которые передаются соответствующим функциям в виде строковых параметров.
    Спецификация ODBC, как и Embedded SQL, поддерживает курсоры. Имеется возможность
    вызывать хранимые процедуры. Из программы могут выдаваться любые операторы SQL, в том
    числе DDL-операторы.

    ODBC-драйверы для Sybase выпускают несколько фирм, в том числе фирма INTERSOLV. Такой
    драйвер входит в состав Sybase Open Client.

    Большинство приложений, связанных с обработкой данных в среде MS-Windows, поддерживают
    ODBC-интерфейс или DB-Library, и, соответственно, имеют доступ к СУБД Sybase. Среди таких
    приложений Microsoft Excel, Word, Access, Visual Basic.


    OLE Automation: написание сценариев на Visual Basic/Visual FoxPro

    Мощь административного OLE интерфейса SQL Server становится очевидной, если учитывать
    возможность использования языка программирования средств разработчика Microsoft (таких как
    Visual Basic или Visual FoxPro) для написания сценариев выполнения административных задач.
    Ниже приведен пример кода, используемого для получения служебной информации с SQL
    Server.


    On-Line Справочник (On-Line Help)

    Утилита-справочник PROGRESS On-Line Help предоставляет Вам все возможности для включения
    в приложения контекстно-ориентированной справочной информации в режиме On-Line. On-Line
    Справочник разработан таким образом, что Вы можете использовать либо справочные
    возможности собственно операционной системы (например, справочник Windows), либо можете
    воспользоваться справочной системой PROGRESS. Но в любом случае требуется лишь однажды
    создать справочный текст, чтобы включать его в дальнейшем в любые приложения для работы на
    любых платформах.

    Для создания справочной информации по приложению можно использовать любой текстовой
    процессор или настольную издательскую систему. Как только справочный текст написан, On-Line
    Справочник может быть использован для включения его либо в приложение, либо в собственный
    справочник операционной системы, если такой имеется. Дополнительно к тексту в справочник
    можно включать картинки, графики и другую визуальную информацию.

    Усовершенствованные справочные возможности

    Кроме функции простого справочного текста, On-Line Справочник обеспечивает поддержку
    следующих возможностей:

  • Гипертекстовые связи. Пользователи могут выделять слова
    или фразы, по которым затем они могут перейти к соответствующим разделам
    в справочнике. Подобный способ значительно облегчает конечным
    пользователям процесс изучения Вашего приложения.
  • "Вырезать-И-Вставить". Пользователи могут "вырезать" из
    справочника примеры и вставлять их в разрабатываемые приложения,
    значительно ускоряя таким образом изучение PROGRESS-приложений. Данная
    возможность также уменьшает стоимость поддержки приложений.
  • Аннотирование. Конечные пользователи могут расширять
    использование справочника, добавляя в него собственные примечания. При
    этом собственная справочная информация остается без изменений, а у
    конечных пользователей появляется возможность сохранять информацию о
    предыдущем сеансе работы с приложением.
    В соответствии с соглашением PROGRESS о переносимости On-Line Справочник работает без
    изменений на всех программно-аппаратных платформах, поддерживаемых PROGRESS. Подобная
    переносимость снижает количество сил и средств, требуемых для документирования и поддержки
    приложений при использовании их на самых разнообразных платформах.


    Оптимизация и выбор плана выполнения запроса

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

    Результатом работы оптимизатора SQLBase является план выполнения запроса (execution plan).
    Говоря упрощенно, execution plan - это последовательность шагов, которая указывает программе
    серверу SQLBase, как выполнить запрос. В плане каждый шаг может быть однотабличным (single
    table) или двухтабличным (two table). Все шаги производят результирующие таблицы (result tables).
    Результирующая таблица не обязательно должна иметь материальное воплощение в виде
    физического объекта. Для любого шага плана результирующая таблица может быть
    пользовательской (user-defined), временной (temporary) или концептуальной (conceptual).

    Однотабличный шаг плана


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


  • Последовательное сканирование (Sequential Scan) - Это наиболее простой
    из всех методов доступа. В этом считывается методе каждая страница данных,
    принадлежащая исходной таблице. (Следует отметить, что все страницы базы
    данных для данной таблицы связаны между собой, поэтому не требуется
    сканирование всего файла базы данных).
  • Доступ по индексу (Index Access) - Существуют два способа использования
    индекса. При первом, значение индекса известно, и индекс может быть
    использован для позиционирования на индексной странице БД и последующего

    извлечения данных непосредственно из индексной страницы. При втором
    способе индексные страницы сканируются в возрастающем или убывающем
    порядке для поиска положения индекса. Если запрос включает колонки
    таблицы, не входящие в индекс, потребуются дополнительные операции для
    считывания информации из страниц данных таблицы.
  • Хэшированный доступ (Hash Access) - В этом методе ключевое значение
    используется для прямого извлечения информации из страницы данных,
    которая содержит строки, удовлетворяющие значению ключа. Метод
    преобразования ключа в адрес страницы, на которой он находится, носит
    название "хэширование". Хэшированный доступ может быть использован
    только в том случае, если для ключа создан хэшированный индекс и
    предикатом является равенство "=".

    Двухтабличный шаг плана

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


  • Вложенный цикл (Nested loop) и его вариации
  • Слияние индексов (Index merge)
  • Гибридное хэшированное объединение (Hybrid hashed join)

    Пример схемы выполнения

    В качестве примера рассмотрим базу данных типа поставщик-товар-поставка. База содержит 3
    таблицы: S для поставщика, P для товара и SP - для поставок. Таблица S имеет уникальный
    первичный ключ S#. Таблица P имеет уникальный первичный ключ P#. Таблица SP имеет
    уникальный первичный ключ на колонках S#P#. Дополнительно, эта таблица содержит индексы
    для колонок City, Color и Weight. Схема базы приведена на рис.5.

    Рис. 5. Схема демонстрационной базы данных

    Таблицы
    Колонки
    Индексы
    S
    		S#, SName, Status, City
    		SXS#(S#), SXCITY(City)
    P
    		P#,
    PName, Color, Weight, City
    		PXP#(P#),
    PXCOLOR(Color),
    PXWEIGHT(Weight)
    SP
    		S#, P#, QTY
    		SPXS#P#(S#,
    P#)

    Запрос 1: Select * from P where color = 'Red' and weight =19;

    План выполнения

    Номер шага
    Внешняя таблица
    Внешний индекс
    Внутренняя таблица
    Внутренний индекс
    Результирующая таблица
    Метод объединения
    1 PPXWEIGHT
    		RESULT

    Для выполнения данного запроса у оптимизатора есть три варианта: 1) последовательное
    сканирование, 2) индексный доступ с помощью индекса PXCOLOR и 3) индексный доступ с
    помощью индекса PXWEIGHT. В данном случае, оптимизатор выбрал индекс PXWEIGHT.
    Поэтому программа сервера будет использовать ключ weight (значение 19) для извлечения всех
    строк, которые удовлетворяют условию "weight =19" и отфильтровывать те из них которые не
    удовлетворяют второму условию (color = 'Red'). Оптимизатор предпочел индекс PXWEIGHT
    индексу PXCOLOR, поскольку он посчитал, что в таблице существует меньше строк,
    удовлетворяющих критерию выбора по ключу weight. Иными словами, индекс PXCOLOR является
    более "плохим" и потребует больше операций ввода/вывода и команд процессора для выполнения
    запроса. Результат запроса представляется в виде концептуальной таблицы RESULT.

    Стоимостная модель оптимизации

    Оптимизатор SQLBase использует так называемый стоимостной метод (cost-based technique) для
    определения наилучшего плана выполнения запроса, в отличие от методов, основанных на анализе
    синтаксиса (syntax-based) запроса или жестко установленных правилах выбора (rule-based).
    Оптимизатор оценивает стоимость или затраты на работу процессора и операции ввода/вывода для
    различных методов доступа к данным и операций над ними. Стоимость процессора оценивается в
    миллисекундах. Стоимость ввода/вывода, которая представляет собой количество операций
    ввода/вывода в секунду, также преобразуется в миллисекунды. Такой подход позволяет проводить
    сравнение нагрузки на процессор и подсистему ввода/вывода. Производительность методов
    доступа к данным и операций объединения зависит от размера и распределения данных.
    Информация о данных представлена в виде статистики таблиц и индексов. Запрос разбивается на
    ряд небольших индивидуальных шагов.


    Наименьший шаг - это доступ к данным одной таблицы,
    который выбирается из всех возможным методов доступа. При этом исследуются все возможности
    выбора данных из таблицы, а также методы объединения между любыми двумя таблицами или
    таблицей и промежуточным результатом. Оптимизатор выбирает наиболее простой и
    эффективный план выполнения.

    В реальной обстановке оптимизатор SQLBase выбирает план выполнения запроса на основе
    вычисления затрат на выполнение целого ряда операций, которые помимо простого
    использования процессора и подсистемы ввода/вывода включают следующие факторы:

    Операции сравнения


  • Перемещение данных
  • Повторный доступ к той же таблице
  • Методы объединения данных
  • Использование буферов ввода/вывода
  • Распределение предикатов

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

    Опыт применения методологий RAD и DATARUN в конкретных проектах

    С. Лапин, Е. Фоминский, Г. Козлов, Е. Фоминская, Б. Позин,
    Компания Аргуссофт (Москва)

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

    Развитие информационных технологий, появление средств автоматизации практически всех этапов жизненного цикла привели к возникновению разнообразных моделей жизненных циклов современных информационных систем. Современные методологии разработки программных продуктов позволяют создавать в сжатые сроки системы высокого качества, удовлетворяющие требованиям пользователей. Многие из современных методологий поддерживаются современными инструментальными средствами.

    Наиболее широкое распространение получила методология быстрой разработки приложений RAD (rapid application development), которая охватывает все этапы жизненного цикла современных информационных систем. В рамках методологии быстрой разработки приложений нашла воплощение методология проектирования DATARUN - методология проектирования от данных.

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

    Использование современных технологий разработки и сопровождения программного обеспечения дало новые возможности:
  • Гибкость ориентации на "ролевые" функции
  • Переносимость ПО на другие платформы без перепрограммирования
  • Более высокая производительность в разработке и сопровождении
  • Упрощение реализации новых функциональных задач без перепрограммирования

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

    Опыт применения методологий RAD и DATARUN в конкретных проектах

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

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

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

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

    Результатами второго прототипа явились протокол рассмотрения итогов создания 2-го прототипа, список замечаний по функциональности экранов и логикам формирования отчетов, приложение к протоколу в виде бумажных копий экранов с замечаниями на них.

    Результаты третьего прототипа были аналогичны.

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


    Объекты проектаОбщее количество
    Файлы экранов217
    Файлы отчетов74
    Файлы меню33
    Файлы моделей архитектуры41
    Файлы моделей данных18

    Oracle7 Server

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

    Сегодня Oracle - это реляционная СУБД, поддерживающая язык SQL и его расширения для работы
    с различными типами данных, а так же механизм транзакций. Особенности архитектуры Oracle
    Server обеспечивают очень высокое быстродействие системы в многопользовательском режиме. По
    результатам независимых тестов TPC Oracle всегда показывает лучшие результаты по
    производительности. Оригинальный механизм многоверсионной записи позволяет получать
    согласованные результаты при выполнении запросов без блокировки данных. Автоматически
    выполняется блокировка данных на уровне записи при модификации данных. Это позволяет
    увеличивать число пользователей системы без снижения ее производительности.

    Встроенные оптимизаторы запросов, использование алгоритмов хеширования, битовых индексов
    и B-деревьев, возможность тонкой настройки СУБД на возможности среды эксплуатации также
    позволяют обеспечить очень высокое быстродействие. Дополнительная компонента ядра Parallel
    Query Option позволяет ускорить работу существующих приложений за счет использования
    возможностей многопроцессорных машин. Эта компонента резко снижает время выполнения
    отдельного запроса, загрузки данных, построения индекса и т. д. за счет разбиения операций
    (например оператора Select) на части и выполнения этих частей параллельно на разных
    процессорах. Увеличение числа процессоров с 1 до 10 позволяет ускорить выполнение запроса в 8
    раз, что очень важно для работы с очень большими БД.

    Компоненты Oracle Parallel Server позволяет СУБД Oracle и Вашим приложениям работать на МРР

    и кластерных архитектурах. Наиболее часто кластер реализуется на базе компьютеров фирм DЕC,
    Sequent, HP, Sun, IBM (RS 6000). При этом все машины кластера могут работать с одной и той же
    БД (что ускоряет и распараллеливает работу), а при выходе из строя одного из узлов кластера,
    другие узлы аккуратно отработают отказ и возьмут на себя дальнейшую обработку данных.
    Использование Oracle на кластере компьютеров позволяет относительно недорого обеспечить
    высоконадежное и быстрое решение Ваших задач.

    Oracle Server позволяет реализовать как односерверную, так и многосерверную архитектуру БД. В
    случае многосерверной архитектуры узлы могут отстоять на большое расстояние, размещаться на
    разных ОС и компьютерах, связываться по разным сетевым протоколам. На основе
    многосерверной архитектуры Oracle позволяет реализовать как распределенную базу данных, так
    и репликацию.

    Компонента Distributed Option позволяет приложению работать с распределенной БД так же, как
    с локальной. Автоматически реализуемый протокол 2х-фазной фиксации позволяет одновременно
    модифицировать данные в разных узлах БД. Узлы всегда находятся в согласованном состоянии,
    однако для этого требуется постоянное наличие связи между узлами. Механизм репликации не
    требует постоянного наличия связи между узлами. Через заданные промежутки времени или при
    восстановлении связи, изменения, сделанные в данном узле, будут отрабатываться в копиях таблиц
    в других узлах. Можно реализовать не только простую репликацию (изменения распространяются
    от таблицы - мастер к копиям), но и сложную репликацию (когда в узлах хранятся копии одной и
    той же таблицы и их можно одновременно обновлять).

    Сложную репликацию реализует компонента Advance Replcation Option, она же помогает задать
    механизм разрешения возникающих коллизий. Oracle Server имеет средства для реализации Backup
    копии Вашей базы, готовой быстро вступить в действие при уничтожении основной базы.

    Вообще же Oracle обеспечивает надежную защиту Ваших данных как от несанкционированного


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

    Oracle позволяет реализовать системы, работающие непрерывно (24 часа, 7 дней в неделю). При
    этом операции копирования и восстановления БД не снижают производительность работы
    пользователей.

    При создании приложений Вы можете часть обработки и контроля данных вынести на сервер.
    Oracle реализует мощный механизм декларативных и процедурных ограничений целостности
    (вплоть до каскадных операций), позволяет создавать хранимые процедуры, триггеры БД,
    функции, алерты, пакеты процедур и функций, задавать расписание для автоматического
    выполнения работ. Причем для создания процедурных объектов ненужно изучать новый язык. В
    качестве процедурного языка 4GL используется расширение языка SQL, называемое PL/SQL.

    Oracle Server - открытая система. Он поддерживает стандарт ODBC и может работать в среде
    мониторов транзакций. В качестве узла распределенной БД Oracle можно использовать чужие
    СУБД, например, DB2. Это реализуется за счет использования шлюзов Oracle к "чужой" СУБД.
    Сегодня существуют шлюзы Oracle к десяткам промышленных СУБД.

    Oracle позволяет создавать и поддерживать очень большие БД. Имеются средства для быстрого
    копирования, восстановления, обработки таких баз. Летом 1995г. Oracle демонстрировал базу
    размером 4 террабайта. На основе СУБД Oracle реализованы огромные хранилища разнородных
    данных Data Warehouse, используемые для выполнения сложных задач анализа. В составе Oracle
    Server появляются инструменты, позволяющие выполнять администрирование и настройку как
    отдельных серверных узлов, так и распределенной БД. Имеется и NLS поддержка, так что Вы
    можете, например, получать сообщения сервера БД на русском языке, использовать правила языка
    при сортировке, работе с датой, строками символов и т. д.

    Организация тиражирования данных в SQL Server 6.0:


  • Система тиражирования данных построена на метафоре подписки. В
    процессе тиражирования участвуют следующие серверы сервер публикаций;
  • сервер репликаций;
  • сервер подписки.

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

    Статья - наименьший возможный элемент публикации. Статья может представлять собой таблицу
    или любую ее часть. Публикация может включать одну или более статей.

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

    Microsoft создавала SQL Server 6.0 с учетом всех перечисленных требований. Подсистема
    тиражирования данных, являющаяся составной частью SQL Server, позволяет осуществлять
    автоматическое тиражирование транзакций и объектов базы данных с единого сервера на один
    или более серверов, расположенных в географически разделенных подразделениях компании. SQL
    Server 6.0 обладает следующими основными характеристиками:


  • Высокая производительность. Архитектура системы тиражирования
    данных SQL Server обеспечивает высокую производительность с
    минимальными задержками на сервере публикаций;
  • Надежная, защищенная передача информации. SQL Server 6.0
    гарантирует целостность транзакций тиражируемых данных средствами

    автоматической ресинхронизации и восстановления после сбоев. SQL Server
    поддерживает новые расширения ANSI SQL Server, позволяющие описывать
    принципы отбора/приема информации на уровне языка определения данных.
    Кроме того, дополнительное шифрование данных при передаче по сети
    гарантирует высокую защищенность тиражируемых данных от
    несанкционированного доступа;
  • Гибкая реализация. SQL Server поддерживает несколько различных
    моделей асинхронной репликации как с диспетчированием процесса, так и
    непрерывных: тиражирование по журналу, тиражирование статических данных
    (snapshot) и перемещение объектов. Богатство моделей тиражирования
    позволяет организациям реализовывать различные подходы, стратегии
    тиражирования и конфигурации сети. Помимо тиражирования транзакций и
    пользовательских данных, SQL Server позволяет автоматизировать
    тиражирование объектов баз данных (таких как хранимые процедуры), что
    облегчает сопровождение систем, функционирующих в распределенных
    средах;
  • Простота сопровождения и установки. Так, Microsoft реализовала в
    SQL Server встроенные средства тиражирования данных, что снижает
    сложность управления и позволяет использовать технологию Drag and Drop
    для удаленного конфигурирования, управления и мониторинга. Система
    тиражирования реализована на интуитивно понятной метафоре "издатель -
    подписчик";
  • Расширяемость. Пользователи создают базы данных самого
    разного типа, и Microsoft построила тиражирование данных вокруг стандартных
    интерфейсов взаимодействия (таких как ODBC), что в будущем позволит
    поддерживать тиражирование в неоднородных базах данных, включая и базы
    данных, созданные средствами приложений для ПК.

    Открытая архитектура Delphi

    С.Орлик, Borland International
    Компания Borland в развитии своих объектно-ориентированных средств разработки явно пришла
    к тому выводу, что повторное использование кода и объектная ориентация не являются
    единственными средствами повышения производительности программистов. С появлением Delphi
    разработчик может не только создавать и предоставлять своим коллегам готовые к использованию
    компоненты, но и расширять функциональные возможности среды, в которой он работает, с
    помощью так называемых "открытых интерфейсов". Такой подход позволяет использовать Delphi
    уже в роли общего ядра набора инструментальных средств на всех этапах создания прикладных
    систем - начиная с CASE-систем и заканчивая генерацией документации по создаваемым проектам,
    с полной их интеграцией в "святая святых" любой среды программирования - IDE. Рассмотрим
    основные возможности расширения функциональности среды Delphi для того, чтобы оценить
    степень "открытости" архитектуры этого инструмента.


    Открытая среда разработок клиент/сервер (CODE - Clent/Server Open Development Environment)

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

    Фирма Powersoft считает, что разработчики должны иметь свободу выбора лучших инструментов для
    создания своих приложений. Начиная с 1992 года проводится программа CODE по интеграции
    PowerBuilder и самых различных компонент среды клиент/сервер. PowerBuilder имеет открытые
    опубликованные интерфейсы, используя которые можно интегрировать в его среду практически
    любые необходимые инструменты.

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

    Открытая среда разработок клиент/сервер (CODE - Clent/Server Open Development Environment)
    Тестирование приложений особенно важно при быстром переходе к разработкам в среде
    клиент/сервер. Тестирование представляет собой один из ключевых этапов в жизненном цикле
    приложения. Среда Windows, основанная на графическом интерфейсе пользователя и управлении с
    помощью сообщений, одна из наиболее сложных для отладки. Для эффективного тестирования
    приложений используются специализированные инструменты для планирования, разработки, и
    исполнения тестов приложений.


    Фирма
    		Название продукта
    Software Quality Automation
    		TeamTest
    Mercury Interactive
    		QA Partner
    Seguie Software
    		PowerRunner
    Softbridge
    		Automated Test Facility
    В сегодняшнем динамичном мире программного обеспечения профессиональные
    разработчики нуждаются в инструментах управления всеми техническими и организационными

    аспектами поддержки проектов по разработке информационных систем. Критически важным для
    успеха проекта является применение CASE - методологий для начальных фаз анализа и
    проектирования. Со средой разработки PowerBuilder тесно интегрированы многие ведущие CASE
    системы.

    Фирма
    		Название продукта
    Chen & Assotiates
    		ER-Modeller
    Intersolv
    		Excelerator
    LBMS
    		System Engineer
    Logic Works
    		ERwin/ERX
    Visible Systems
    		Visible Analyst Workbench
    Как только разработчики получают опыт в построении приложений, они замечают,
    что существует множество общих компонент, которые часто повторно используются. Используя
    мощные объектно-ориентированные средства PowerBuilder, многие компании предлагают такие
    компоненты в виде библиотек классов и элементов управления.
    Фирма
    		Название продукта
    Greenberg & Russel
    		Object Start
    PowerServ
    		PowerTOOL
    ServerLogic
    		PowerClass
    Visual Tools
    		Formula One, ImageStream, First Impression
    Интерфейс к базам данных был составной частью PowerBuilder с его самой первой
    версии. Каждый интерфейс использует все преимущества (например хранимые процедуры, расширения
    языка SQL, декларативная ссылочная целостность и т.д.) и учитывает особенности (такие, как
    различные типы данных, различные реализации работы с курсорами и т.д.) каждого конкретного
    сервера баз данных. PowerBuilder также поддерживает стандарт ODBC для доступа к разнообразным
    базам данных и файлам на персональных компьютерах.
    Фирма
    		Название продукта
    Hewlett Packard
    		Allbase/SQL, Image/SQL
    IBM
    		DB2/2, DB2/6000
    Informix
    		Online
    Microsoft
    		SQL Server
    Oracle
    		Oracle Server
    Sybase
    		SQL Server, SQL Anywhere
    Information Builders
    		EDA/SQL
    Наиболее современный способ разработки сложных приложений в среде
    клиент/сервер опирается на разбиение приложения на компоненты, реализующие различные функции,
    такие как хранение данных, деловая логика и интерфейс пользователя, и исполнение их на различных
    машинах в сети с целью минимизировать нагрузку на сеть и оптимально использовать


    вычислительные ресурсы. Такая организация называется трехуровневой (в более общем случае,
    многоуровневой) архитектурой.
    Фирма
    		Название продукта
    Gradient Technologies
    		Visual DCE
    Tangent International
    		Distributed Computing Intergator for TopEnd
    Tangent International
    		Distributed Computing Intergator for Tuxedo
    Transarc
    		EncinaBuilder
    Программное обеспечение коллективной работы пользователей позволяет им
    обращаться к значительным объемам неструктурированных данных по сети, управлять данными и
    потоками информации в распределенной среде масштаба предприятия.
    Фирма
    		Название продукта
    Lotus Development
    		Notes
    У многих организаций сохранились информационные системы, разработанные для
    больших ЭВМ. Различные продукты для доступа к данным позволяют интегрировать их в
    PowerBuilder, не прибегая к низкоуровневому программированию.
    Фирма
    		Название продукта
    Attachmate Corp
    		Extra!
    Wall Data
    		Rumba
    Лидирующие производители систем управления документами и изображениями
    участвуют в программе CODE, позволяя разработчикам интегрировать эти технологии с
    приложениями на PowerBuilder.
    Фирма
    		Название продукта
    FileNet Corp
    		WorkFLO
    Wang Laboratories
    		Wang OpenImage
    Watermark Software
    		Watermark Discovery Edition
    Централизованная система управления библиотеками объектов PowerBuilder
    представляет собой открытую среду для групповой разработки приложений и управления проектом.
    Предоставляются прямые связи из среды PowerBuilder к лидирующим системам управления объектами
    и контроля версий для управления разработкой объемных приложений.
    Фирма
    		Название продукта
    Intersolv
    		PVCS
    Legent Corp
    		Endevor
    Mortice Kern Systems
    		RCS

    Открывается доступ в международные информационные сети

    А для пользователей это означает:
  • У вас появляются новые способы ведения бизнеса: в сеть можно поместить свои прейскуранты
    и другую информацию для всеобщего ознакомления, можно по электронной почте получать и
    посылать заказы, выставлять клиентам счета, обсуждать и согласовывать тексты контрактов и
    коммерческих предложений, посылать напоминания должникам и т.д.
  • Вы можете обращаться к огромным объемам информации по любым областям знаний,
    гораздо большим, чем в любой самой крупной библиотеке. Это могут быть книги, справочники,
    программы, материалы периодических изданий, различные базы данных, коммерческая реклама
    и многое другое.
  • Вы можете вести деловую переписку по электронной почте с абонентами в любых уголках
    мира
  • Вы приобретаете одну из самых удобных возможностей получения консультаций, советов,
    помощи. Все серьезные фирмы, производящие компьютеры или программы, осуществляют сейчас
    техническую поддержку своих пользователей через глобальные сети.
    Наиболее известной фирмой, обеспечивающей коммуникационные возможности (или услуги
    глобальной сети), является Internet. Каждое серьезное предприятие сегодня обязательно должно
    иметь выход в Internet. Такую возможность начинают предоставлять многие корпоративные
    системы.

    Отладчик Приложений (Application Debugger)

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

    Отслеживание передачи управления в приложении.

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

    Просмотр объектных сообщений и информации о состоянии.

    Применение Отладчика Приложений упрощает тестирование объектно-ориентированных
    приложений, так как позволяет просмотреть состояние инкапсулированных объектов и методов
    для данных и пользовательского интерфейса. Также, во время исполнения приложения возможно
    производить отслеживание сообщений, посылаемых объектами.

    Трассировка событий.

    Для того, чтобы Вам было легче понять смысл событийно-управляемой модели программирования
    PROGRESS, Отладчик Приложений позволяет просмотреть список событий, инициированных
    действием пользователя, и легко проследить, какие триггеры срабатывают при этом.

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


    Отладчик

    Символьный отладчик позволяет отлаживать в исходных кодах программы на языке NewEra.
    Основные возможности:

  • просмотр исходных модулей, входящих в программу, показ текущей
    позиции выполнения;
  • пошаговое выполнение программ;
  • установка и снятие точек останова непосредственно в тексте модулей;
  • просмотр значений переменных, элементов массивов, компонентов
    структур и объектов;
  • поиск фрагмента текста по всем модулям.

    Отладка (Debug)

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


    Отображение логического и физического уровня модели данных в ERwin

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

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

    ERwin предоставляет возможности создавать и управлять этими двумя различными уровнями
    представления одной диаграммы (модели), равно как и иметь много вариантов отображения на
    каждом уровне.


    Отслеживание действий пользователей

    Серверный продукт Sybase Audit Server записывает информацию о действиях пользователей в
    специальную базу данных, доступную для анализа.


    Параллельная загрузка

    При работе с новой версией SQL Server можно запускать несколько параллельно работающих
    копий BCP или SQL Enterprise Manager и выполнять параллельные перекрывающиеся операции
    загрузки данных в SQL Server. Подобные возможности оказываются особенно полезными при
    необходимости массивного копирования данных в ограниченные сроки.


    Параллельное сканирование и асинхронное опережающее чтение

    Параллельное сканирование и асинхронное опережающее чтение повышает на 40 - 400% скорость
    выполнения некоторых типов запросов и других операций над базой данных в многопроцессорных
    системах. Повышение производительности достигается за счет использования SQL Server 6.0
    множественных потоков операционной системы и алгоритмов определения следующего блока
    данных, необходимых для вывода в кэш. На приводимом графике показано, как растет время,
    необходимое для считывания с диска более 10000 страниц из базы данных (меньшие числа
    показывают более высокую производительность). Эта операция типична для длительного запроса
    с вычислениями или операции создания отчета. Как видно из графика, по мере роста числа
    клиентов, SQL Server 6.0 выполняет операцию не менее чем в 4 раза быстрее за счет использования
    параллельного сканирования таблиц и асинхронного опережающего чтения.

    Подобная технология обеспечивает резкое повышение производительности для любой операции,
    требующей просмотра таблиц, например, SELECT, UPDATE и DELETE с необходимостью
    поиска, CREATE INDEX, DBCC, DUMP/LOAD и т.п.


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

    Б.Вольфман, ЭЛКО Технологии
    Pазработкa корпоративных систем с использованием современных инструментальных средствОсновное направление деятельности "ЭЛКО
    Технологии" - выполнение крупных проектов на базе современных информационных
    технологий.

    Переносимость и интероперабельность информационных систем и международные стандарты

    Сергей Кузнецов
    Программные продукты, которые сегодня принято называть информационными системами,
    появились много лет назад. Первые информационные системы основывались на мейнфреймах
    компании IBM, файловой системе ОС/360, а впоследствии на ранних СУБД типа IMS и IDMS. Эти
    системы прожили долгую и полезную жизнь, многие из них до сих пор эксплуатируются. Но с
    другой стороны, полная ориентация на аппаратные средства и программное обеспечение IBM
    породила серьезную проблему "унаследованных систем" (legacy systems). Проблема состоит в том,
    что производственный процесс не позволяет прекратить или даже приостановить использование
    морально устаревших систем, чтобы перевести их на новую технологию. Многие серьезные
    исследователи сегодня заняты попытками решить эту проблему. Это отдельная большая тема, но в
    этом докладе мы серьезно рассматривать ее не будем.

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

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

    функционально завершенных программных систем.

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

    Рассмотрим немного подробнее, какие стандарты следует иметь в виду при разработке
    информационной системы сегодня. При использовании текущей технологии информационная
    система пишется на некотором языке программирования, в нее встраиваются операторы языка
    SQL и, наконец, включает какие-либо вызовы библиотечных функций операционной системы.

    Соответственно, прежде всего следует обращать внимание на степень стандартизированности
    используемого языка программирования. На сегодняшний день приняты международные
    стандарты языков Фортран, Паскаль, Ада, Си и, совсем недавно, Си++. Понятно, что Фортран,
    даже в своем наиболее развитом виде стандарта Фортран-95, не является языком, подходящим для
    программирования информационных систем. Паскаль - очень приятный язык, но чтобы не
    испортить впечатление от его приятности, в стандарт не включены средства раздельной
    компиляции. Конечно, в принципе можно оформить полный исходный текст в виде одного
    текстового файла, но вряд ли это разумно и практично. Язык Ада, вообще говоря, пригоден для
    любых целей. На нем можно писать и информационные системы (что, кстати и делают
    американские и некоторые отечественные военные). Но что-то не видно счастливых прикладных
    программистов, использующих язык Ада. Уж больно он громоздкий...

    По мнению многих программистов, наиболее хороший стандарт на сегодняшний день существует
    для языка Си. Опыт нескольких лет, прошедших после принятия стандарта, показывает, что при
    грамотном использовании стандарта Си ANSI/ISO проблемы переноса программ, связанные с
    особенностями аппаратуры или компиляторов, практически не возникают (если учитывать


    имеющиеся в самом стандарте рекомендации по созданию переносимых программ). Этих
    нескольких лет оказалось достаточно, чтобы обеспечить полное соответствие стандарту
    практически всех индустриальных компиляторов языка Си. Даже если в реализации допускаются
    расширения стандарта (как, например, в компиляторе Ричарда Столлмана из проекта GNU GCC),
    то имеются опции компилятора, позволяющие контролировать выход за границы стандарта.

    Очень важно, что в стандарте ANSI Си специфицирован не только язык, но и базовые библиотеки
    стандартной системы программирования (в частности, основные компоненты библиотеки
    ввода/вывода). Наличие стандарта на библиотечные функции и его строгое соблюдение в
    реализациях в ряде случаев позволяет создавать не очень сложные приложения, переносимые не
    только между разными аппаратными платформами, но и между различными операционными
    средами.

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

    Почему, имея в виду взаимодействия с базами данных, мы говорим про язык SQL, и что с ним
    происходит? Здесь все не очень просто. SQL с самого своего зарождения являлся сложным языком
    со смешанной декларативно-процедурной семантикой, не идеальным синтаксисом, а кроме того,
    всегда содержал ряд темных мест (объем доклада не позволяет даже привести примеры). Тем не
    менее, судьба распорядилась так, что именно SQL стал единственным практически используемым
    языком реляционных баз данных, хотя имелись и другие кандидаты, в частности, язык системы
    Ingres Quel.

    В результате длительного процесса стандартизации языка к настоящему времени имеется два
    принятых международных стандарта SQL - SQL/89 и SQL/92.


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

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

    Ситуация не из приятных. Но тем не менее, внимательный анализ языка показывает, что имеется
    практическая возможность создания достаточно переносимых программ с использованием SQL/89.
    Для это нужно максимально локализовать те части программы, которые содержат
    нестандартизованные конструкции, и стараться не использовать расширения языка, предлагаемые
    в конкретной реализации. Понятно, что для этого требуется хорошее знание как SQL/89, так и
    особенностей диалекта, реализованного в используемом продукте. К сожалению, в отличие от
    ситуации со стандартом языка Си, стандарт SQL/89 не слишком помогает в решении этой
    проблемы. В этом стандарте полностью отсутствуют какие-либо рекомендации для мобильного
    программирования информационных систем.

    Между прочим, аналогичная ситуация существует и в области операционных систем.
    Существующий сегодня набор стандартов происходит от интерфейсов операционной системы
    UNIX (SVID, POSIX, XPG и т.д.). В большинстве современных операционных систем эти
    стандарты поддерживаются, но, как правило, любая ОС содержит множество дополнительных
    средств. При этом, естественно, наименее стандартизованы наиболее современные и продвинутые
    решения (их просто не успевают стандартизовать).


    Наверное, сегодня самым ярким примером
    печального положения дел является полная нестандартизованность средств "легковесных
    процессов" (threads). Нельзя сказать, что процессы, работающие на общей виртуальной памяти,
    действительно обеспечивают возможность параллельного программирования в среде
    симметричных мультипроцессорных систем. Это затруднительный в отладке и чреватый скрытыми
    (редко проявляющимися) ошибками способ программирования. Однако на сегодняшний день
    наука программирования все еще не может предложить более надежный и простой при
    использовании подход. Конечно, очень жаль, что отсутствует стандартизация threads.

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

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

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


    должна быть интегрирована и по мере возможности обладать достаточной эффективностью.

    Проследим наиболее важные вехи в процессе обеспечения интероперабельности распределенных
    программных компонентов. Возможно, это частная точка зрения, но кажется, что первым шагом
    был механизм "программных гнезд" (sockets), разработанный в университете Беркли. Основным
    достижением этой разработки было то, что с использованием единого механизма межпроцессных
    взаимодействий можно было интегрировать программные компоненты, произвольным образом
    распределенные в локальных или территориально распределенных сетях. (Конечно, мы должны
    заметить, что в каждом узле сети должен был поддерживаться механизм программных гнезд.)
    Основным недостатком программных гнезд является то, что это чисто транспортный механизм. В
    частности, представление передаваемых по сети данных является машинно-зависимым.
    Следовательно, в каждом узле сети (если она гетерогенна, а это общий случай) нужно уметь
    правильно преобразовывать представление данных, получаемых из любого другого узла. Понятно,
    что это образует серьезную техническую проблему.

    Следующим шагом (очень важным шагом) явилось появление протокола вызова удаленных
    процедур (Remote Procedure Calls - RPC) и его реализация. Идея этого механизма очень проста. В
    большинстве случаев взаимодействие программных компонентов является асимметричным.
    Практически всегда можно выделить клиента, которому требуется некоторая услуга, и сервер,
    который такую услугу способен оказать. Более того, как правило, клиент не может продолжать
    свое выполнение, пока сервер не произведет требуемые от него действия. Другими словами,
    типичным взаимодействием клиента и сервера является процедурное взаимодействие. С точки
    зрения клиентской программы обращение к серверу ничем не отличается от вызова локальной
    процедуры. При реализации механизма вызова удаленных процедур на основании спецификации
    интерфейса процедуры на стороне клиента генерируется локальный представитель удаленной


    процедуры - stub, а на стороне сервера - специализированный переходник - proxy.

    Очень полезной составляющей ( относительно независимой от других составляющих) семейства
    протоколов RPC является протокол внешнего представления данных (External Data Representation
    - XDR). В этом протоколе специфицировано машинно-независимое представление данных,
    понимаемых механизмом RPC. Идея состоит в том, что при передаче параметров вызова
    удаленной процедуры и при получении ее ответных параметров происходит двойное
    преобразование данных сначала из исходного машинно-зависимого формата в формат XDR, а
    затем из этого формата в машинно-зависимый целевой формат. В результате взаимодействующие
    программы избавлены от потребности знания специфики машинно-зависимых представлений
    данных. Возможно, именно протокол XDR обладает определяющим значением в связке
    протоколов вызова удаленных процедур (хотя, конечно, возможности XDR довольно
    ограничены).

    Наконец, видимо наиболее перспективным на сегодняшний день является подход, предложенный и
    специфицированный международным консорциумом Object Management Group (OMG). Опять-
    таки, основная идея проста. Как бы мы не стремились выработать единые языковые средства для
    разработки распределенных информационных систем, похоже, что это стремление останется среди
    других благородных, но недостижимых задач человечества. Унификация невозможна. Имеется
    много разных подходов, каждый из которых в чем-то превосходит другие. Нельзя сказать, что
    какой-то подход является определяющим. Пожалуй, единственное, на чем сходится подавляющее
    большинство исследователей и разработчиков распределенных программных систем, это
    склонность к использованию парадигмы объектной ориентации.

    Не будем подробно останавливаться на преимуществах этой парадигмы (об этом давно написаны
    целые книги). Однако все-таки заметим, что объектно-ориентированный стиль проектирования и
    разработки программных систем (и в особенности информационных систем) стимулирует
    повторное использование программных компонентов (за счет наличия механизма наследования


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

    Все это прекрасно. Но проблема состоит в том, что отсутствует общая объектная модель. В разных
    объектно-ориентированных системах программирования и системах баз данных гораздо больше
    общего, чем различного, но их различия часто принципиальны настолько, что объекты,
    разработанные и созданные в разных системах, не способны взаимодействовать. Они не понимают
    друг друга, они не интероперабельны. А это, конечно, очень плохо. Особенно плохо по той
    причине, что постоянное наращивание возможностей Internet делает принципиально возможным
    использование информационных ресурсов вне зависимости от их реального расположения.

    Активность OMG предлагает ограниченное, но практически достижимое решение этой проблемы.
    Это общая архитектура Object Management Architecture (OMA) и ее конкретное воплощение
    Common Object Request Broker Architecture (CORBA). Мы остановимся только на наиболее
    ключевых аспектах. Прежде всего, поскольку на сегодня отсутствует (и вряд ли появится в
    ближайшем будущем) объектная модель, которая могла бы служить "общей крышей" для
    существующих объектно-ориентированных языков и систем программирования, то единственным
    практически возможным выходом была выработка минимальной объектной модели, обладающей
    ограниченными возможностями, но имеющая явные аналоги в наиболее распространенных
    объектных системах. В архитектуре CORBA такая минимальная модель называется Core Object
    Model, и ей соответствует язык спецификации (не программирования!) интерфейсов объектов
    Interface Definition Language (IDL).

    Чтобы обеспечить возможность взаимодействия объекта, существующего в одной системе


    программирования, с некоторым объектом из другой системы программирования, в исходный
    текст первого объекта (правильнее сказать, его класса) должна быть помещена спецификация на
    языке IDL интерфейса того объекта, метод которого должен быть вызван. Аналогичная
    спецификация должна быть помещена на стороне вызываемого объекта. Далее исходные тексты
    должны быть обработаны соответствующим прекомпилятором IDL (таких прекомпиляторов
    должно иметься ровно столько, сколько поддерживается интероперабельных объектных сред;
    сегодня специфицированы правила встраивания IDL в программы на языках Си, Си++ и
    Smalltalk). Спецификация интерфейса объекта на языке IDL представляет собой главным образом
    набор сигнатур методов объекта. В каждой сигнатуре определяется имя метода, список имен и
    типов данных входных параметров, а также список имен и типов данных результатов выполнения
    метода. Кроме того, IDL позволяет определять структурные типы данных (конечно,
    прекомпилятор IDL на основе определений таких типов производит спецификации типов целевой
    системы программирования)

    Что же является результатом работы прекомпилятора? Все очень похоже на RPC... На стороне
    клиента генерируется текст объекта-stub, который играет роль локального представителя
    удаленного объекта (с ограничениями, свойственными IDL). Работа с этим объектом-посредником
    происходит по правилам соответствующей системы программирования: в среде Си++ stub - это
    объект Си++, в среде Smalltalk - это объект Smalltalk и т.д. С другой стороны, в коде,
    генерируемом в stub, заложены знания о том, что требуется сделать для обращения к методу
    удаленного объекта.

    На стороне сервера генерируется текст объекта-sceleton, своего рода посредника при доступе к
    удаленному объекту. С одной стороны, sceleton "знает", что обращение является удаленным. С
    другой стороны такой посредник умеет обращаться к удаленному объекту по правилам его
    системы программирования.

    Конечно, для доставки сообщения от клиента к серверу и получения ответных результатов должен


    существовать системный (вернее, полусистемный - middle-ware) компонент, отвечающий именно за
    выполнение таких функций. В архитектуре CORBA такой компонент называется брокером
    объектных заявок (Object Request Broker - ORB). В функции ORB главным образом входит
    передача данных в машинно-независимом формате от клиента серверу и от сервера клиенту. Кроме
    того, ORB отвечает за правильное указание сетевого адреса объекта-сервера.

    Интерфейс между stub, sceleton и ORB основан на специфицированном в описании архитектуры
    CORBA интерфейсе прикладного уровня (Application Programmer Interface - API). Этот интерфейс
    на самом деле открыт для программистов. На нем основан метод динамического вызова объектов
    без потребности спецификации их интерфейсов на языке IDL. Естественно, программирование на
    уровне API ORB является гораздо более обременяющим делом, чем если бы использовался IDL.
    Однако иногда интерфейсы вызываемых удаленных объектов просто неизвестны в статике; их
    можно получить только на стадии выполнения программы, и тогда без использования API
    обойтись не удается.

    OMG не обладает правами международной организации по стандартизации. Тем не менее,
    принимаемые в этой организации документы обладают исключительно высоким международным
    авторитетом и становятся фактическими стандартами. Проблемой стандарта OMG CORBA было
    то, что отсутствовала стандартизация взаимодействий уровня ORB-ORB. В результате ORB'ы,
    производимые разными компаниями, не могли совместно работать. Теперь уже ORB'ы не
    понимали друг друга. В прошлом году OMG приняла новый стандарт CORBA-2, в котором
    специфицирован протокол взаимодействий между ORB'ами. Реализации этого протокола уже
    появились, и имеется надежда на реальное использование информационных ресурсов Internet. Дай-
    то Бог!

    Конечно, CORBA - это далеко не все, что требуется. Это всем понятно, но далеко не понятно, а что
    же нужно. Это ужасно сложная и непонятная тема - семантическая интероперабельность объектных
    систем.

    []
    []
    []

    Переносимость приложений, разработанных с помощью JAM

    JAM, как среда разработки, доступен на нескольких десятках программно-аппаратных платформ,
    включая Windows, Windows 95, Windows NT, OS/2, Mac, VMS и практически все распространенные
    UNIX платформы. На этих же платформах, соответственно, доступны и приложения, построенные
    с использованием JAM. Переносимость JAM-приложений между платформами практически
    абсолютная.

    Реализация переносимости между типами интерфейсов - алфавитно-цифpовой и графический
    интерфейсы. JAM-приложения могут исполняться как в алфавитно-цифровом, так и в GUI-режиме
    практически на всех поддерживаемых платформах, где реализованы оба режима. Из GUI
    поддерживаются MS-Windows, Presentation Manager, X-Windows, Macintosh. Переносимость между
    типами интерфейса также практически абсолютная за исключением недоступности векторных
    шрифтов и графических образов в алфавитно-цифровых режимах.

    Переносимость локализованных приложений между различными программно-аппаратными
    платформами с различными кодировками национального алфавита (например, перенос
    русскоязычных приложений между Windows и UNIX) может иметь минимально возможную
    трудоемкость. При максимально активном использовании Репозитория JAM достаточно изменить
    написание только базовых объектов. В ряде случаев JAM дает возможность избежать и этой
    работы. Это достигается соответствующим переопределением устройств ввода/вывода (клавиатура
    и терминал).


    Платформы

    SQLBase разрабатывалась специально для применения на персональных компьютерах с
    процессорами фирмы Intel. В настоящее время эта СУБД выпускается для следующих сетевых
    операционных систем: Novell NetWare 3.x и 4.x, Windows 95 и NT, OS/2 2.x. Существует также
    локальная версия для платформы Windows 3.x. При работе в Windows 95, Windows NT и OS/2
    SQLBase поддерживает как традиционную технологию клиент-сервер, так и новую технологию
    клиент-клиент, позволяющую создавать сложные системы серверов баз данных с распределением
    данных и задач между компьютерами даже в одноранговой сети. В ОС NetWare SQLBase является
    классическим сервером баз данных, таким же как Oracle или Sybase.


    Поддержка локализации

    JAM поддерживает 8-битные кодировки символов алфавита. Форматы ввода/вывода
    даты/времени, валюты, чисел являются настраиваемыми. Системные сообщения вынесены в
    отдельные файлы и доступны для перевода.


    Поддержка многопользовательского режима


  • "Оптимистическая" и "Пессимистическая" модели блокировок
  • Блокировки
  • Уровни изоляции
  • Особенности сервера


    Поддержка очень больших баз данных и съемных носителей

    Для версии 4.21а очень большой считалась база данных размером 10-15 Гб (хотя некоторые
    организации, например, Sprint, работали с базами данных размером 60 Гб и более).
    Высокоскоростная параллельная обработка делает возможной поддержку работы с базами данных
    размером 100 Гб и более на соответствующим образом конфигурированных системах. Не только
    процесс создания страховочных копий выполняется быстрее, но и такие операции, как проверка
    целостности базы данных (выполняется командой DBCC), сильно выигрывают от использования
    параллельного сканирования и увеличенных блоков ввода/вывода. Возможность сохранения в
    страховочной копии (восстановления из копии) индивидуальных таблиц позволяет сократить
    время, необходимое на сохранение (восстановление) отдельных таблиц базы данных. Поддержка
    распространения баз данных на съемных носителях (таких как CD-ROM) позволяет выпускать
    различного рода справочники или информационные материалы. Интересно отметить, что
    гибкость SQL Server проявляется и при работе с очень маленькими объемами информации. Так,
    для того чтобы базу данных можно было сохранить на дискете, ее минимальный размер снижен до
    1 Мб.


    SQL Anywhere поддерживает ODBC API

    SQL Anywhere поддерживает ODBC API не только на платформах Windows и Windows NT, но и в
    DOS, OS/2 и QNX. SQL Anywhere 5.0 поддерживает спецификацию ODBC 2.1 уровня 2.

    Поддержка средств 4GL

    ERwin выпускается в нескольких различных редакциях, ориентированных на наиболее
    распространенные средства разработки 4GL. В числе поддерживаемых средств - PowerBuidler фирмы
    Powersoft, SQL Windows фирмы Gupta, Visual Basic фирмы Microsoft, Oracle*CASE фирмы
    Oracle.

    Средства двунаправленного взаимодействия ERwin с базой данных обеспечивают управление
    информацией, ориентированной как на серверную, так и на клиентскую часть. Например, для
    PowerBuilder можно просматривать/редактировать расширенные атрибуты в редакторах ERwin.

    Ориентация ERwin на средства 4GL позволяет задать для будущих приложений большинство
    параметров, непосредственно связанных с базой данных, уже на стадии проектирования
    информационной модели.

    Покажем принципы организации такого взаимодействия на примере PowerBuilder.

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

    Для расширенных атрибутов допустимы те же операции синхронизации, что и для всей модели, то есть
    описания могут быть загружены в базу данных и, наоборот, созданные из среды PowerBuilder
    описания расширенных атрибутов могут быть загружены из базы данных в ERwin для
    модификации.

    Пример определения расширенных атрибутов показан на рис.9.

    Поддержка средств 4GL

    Поддержка Transact-SQL

    SQL Anywhere 5.0 включает набор расширений языка Watcom SQL в сторону диалекта Transact-
    SQL Sybase, используемого в Sybase SQL Server на различных платформах.

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


    Подход к представлению проектной информации

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

    Один и тот же элемент данных может в разных представлениях иметь разные названия и форматы. В
    SILVERRUN обеспечена возможность связывать элементы данных различных представлений с общим
    элементом (common item), выражающим смысл представленной этими элементами данных информации.
    Этот общий элемент может стать столбцом таблицы базы данных в новой системе или просто
    использоваться как универсальный термин для связи разных представлений.


    Последовательность проектирования модели данных в S- Designor

    Процесс построения информационной модели данных состоит из следующих шагов:

  • определение сущностей;
  • определение зависимостей между сущностями;
  • задание первичных и альтернативных ключей;
  • определение атрибутов сущностей;
  • переход к физическому описанию модели (выполняется автоматически);
  • редактирование имен таблиц и их атрибутов на физическом уровне (если в
    модели имеются, например, связи "многие ко многим" или иерархические
    рекурсивные связи и их надо уточнить);
  • проектирование триггеров, процедур и ограничений;
  • генерация базы данных.
    Четкое разделение между концептуальной и физической моделями в S-Designor выражается в
    том, что на каждом уровне действуют соответствующие четко выраженные правила. На
    концептуальном уровне не выполняется миграция атрибутов
    первичного ключа в дочернюю сущность, так как это было бы уже не отображение реального мира (в
    данном случае перечня атрибутов конкретного объекта).
    Миграция выполняется на физическом
    уровне

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

    При генерации физической модели S-Designor, если это необходимо, детализирует связи.
    Связь "многие ко многим" порождает новую таблицу. Таким образом обеспечивается автоматическая
    нормализация модели. Идентификаторы сущностей, участвующих в связи, мигрируют в новую
    таблицу. Первичный ключ в зависимой таблице составляет теперь сумму атрибутов первичных
    ключей родительских таблиц. При уточнении иерархической рекурсивной связи S-Designor
    автоматически добавляет новую колонку, являющуюся внешним ключом, которую при
    необходимости можно переименовать.

    Для управления уникальностью строк и ускорения доступа к данным могут назначаться индексы. Для
    первичных и внешних ключей индексы формируются автоматически.

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


    Построение архитектуры информационной системы

    Принимается решение, из каких приложений (подсистем) будет состоять система. Анализируются
    существующие системы. Архитектура системы документируется в виде DFD, где функции представляют
    компоненты приложений с указанием используемой информации (путем ссылки на сущности и связи ER-
    модели). ER-модель также делится на группы сущностей, обрабатываемых приложениями. Результат:
    Архитектура информационной системы.


    Построение бизнес-модели предметной области

    Строится функциональная (DFD) и информационная (ER) модели предметной области. При построениии
    функциональной модели выявляются первичные структуры данных, которые преобразуются в сущности
    ER-модели. Результат: Модель бизнес-процессов, содержащая Первичные структуры данных, и
    Концептуальная модель данных.


    Построение корпоративных информационных систем: технологии и решения

    Старыгин, МетаТехнология

    Тел.: 253-38-22, ф. 255-12-90,

    ()

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

    За последние десятилетия радикально изменились принципы, методы построения и архитектура такой системы. Так, если в 60-х годах считалось, что никакой процесс не должен автоматизироваться до тех пор, пока он функционирует эффективно, то сегодня господствующим является прямо противоположный подход. Считается, что любой процесс должен автоматизироваться только после того, как он эффективно организован.

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

    Главными особенностями современного подхода к построению корпоративной информационной системы предприятия являются:

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

    Такой подход обеспечивает разработку интегрированных решений, построенных на объективных данных о работе предприятия, своевременное согласование всех принципиальных вопросов между Заказчиком, Генеральным Подрядчиком и другими участниками работ и направлен на сохранение сделанных в систему инвестиций.

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

    Основными компонентами этого множества являются (список упорядочен по алфавиту):

    ABB ABC ABM ARP BPR CPI CPN DFD ERD IDEF0 IDEF!X SADT STD TQM
    Activity Based Budgeting - планирование бюджета на основе выполняемых функций или операционное планирование бюджета - планирование бюджета компании или инвестиционного проекта с использованием принципов, средств и методов ABC. Фактически представляет собой обратное проектирование ABC-системы
    Activity Based Costing - функционально-стоимостной анализ - метод определения стоимости и других характеристик изделий и услуг на основе функций и ресурсов, задействованных в бизнес-процессах
    Activity Based Management - управление на основе ABC-информации или операционное управление - методология, описывающая средства и способы управления организацией для совершенствования бизнес-процессов и повышения прибыльности на основе информации, предоставляемой в результате ABC-анализа
    Activity Resource Planning - функциональное планирование ресурсов - метод планирования ресурсов компании на основе анализа функций, задействованных в бизнес-процессах и данных ABC-анализа
    Business Process Reengenering- реорганизация бизнес-процессов - направление деятельности, включающее "фундаментальное переосмысление и радикальное перепланирование критических бизнес-процессов с целью улучшения их эффективности в отношении затрат, качества выполнения и скорости"
    Continuous Process Improvement - непрерывное совершенствование процессов - один из подходов к совершенствованию качества бизнес-процессов в рамках TQM
    Color Petri Nets - раскрашенные сети Петри - методология создания динамической модели бизнес-процесса, позволяющая проанализировать зависящие от времени характеристики выполнения процесса и распределение ресурсов, для входящих потоков различной структуры
    Data Flow Diagrams - диаграммы потоков данных - методология структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных к которым осуществляется доступ
    Entity-Relationship Diagrams - диаграммы "сущность-связь" - способ определения данных и отношений между ними, обеспечивающий детализацию хранилищ данных проектируемой системы включая идентификацию объектов (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей)
    Методология функционального моделирования, являющаяся составной частью SADT и позволяющая описать бизнес-процесс в виде иерархической системы взаимосвязанных функций
    Методология информационного моделирования, являющаяся составной частью SADT и основанная на концепции "сущность-связь" (entity-relationship)
    Structured Analysis and Disign Tecchnique технология структурного анализа и проектирования
    State Transition Diagrams - диаграммы переходов состояний - методология моделирования последующего функционирования системы на основе ее предыдущего и текущего функционирования
    Total Quality Management - глобальное управление качеством - направление деятельности, изучающее бизнес-процесс с целью такой их организации, которая гарантирует идеальное качество продукции
    <


    На рассмотренные понятия и методологии сгруппированы по основным направлениям использования в работах по моделированию и анализу бизнес-процессов.

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

    Пакет Design/IDEF компании Meta Software - для функционального и информационного моделирования, анализа и проектирования бизнес-процессов;

    Основными особенностями Design/IDEF являются:

  • полная поддержка методологий IDEF0 и IDEF1X;
  • интеграцию функционального и информационного представления системы в рамках единой модели;
  • контроль непротиворечивости модели на протяжении всего цикла ее создания;
  • встроенный словарь данных, позволяющий создавать неограниченное количество параметров описания любого объекта,
  • генератор отчетов, позволяющий создавать отчеты о функциях и потоках данных модели;
  • интерфейсы к внешним программам, экспорт и импорт данных;
  • поддержка коллективной работы группы разработчиков.

    Построение корпоративных информационных систем: технологии и решения
    в работах по моделированию, анализу бизнес-процессов и построению
    корпоративных информационных систем поддержки бизнеса">

    Рис. 1. Области использования различных методологий
    в работах по моделированию, анализу бизнес-процессов и построению
    корпоративных информационных систем поддержки бизнеса

    Пакет EasyABC Plus компании ABC Technologies - для функционально-стоимостного анализа бизнес-процессов;

    Основными особенностями EasyABC Plus являются:

  • поддержка ABC-метода анализа бизнес-процессов, выявление затратных центров, подготовка данных для планирования и управления предприятием;
  • возможность определить любое количество уровней назначения стоимости между ресурсами, функциями, стоимостными объектами;
  • поддержку работы с реальными и бюджетными данными, что дает возможность оценить реальную производительность по сравнению с запланированными показателями;
  • возможность моделирования результатов принимаемых решений в режиме "что-если";
  • возможность анализа групп функций или стоимостных объектов, помеченных одинаковыми метками (атрибутами);


  • генерация разнообразных отчетов;
  • экспорт и импорт данных.

    Пакет ServiceModel компании PROMODEL - для имитационного моделирования выполнения бизнес-процессов, анализа зависящих от времени характеристик, распределения ресурсов.

    Основными особенностями ServiceModel являются:

  • возможность использования функциональных моделей бизнес-процессов, подготовленных в Design/IDEF;
  • учет множества дополнительных элементов, описывающих поведение модели: продолжительность выполнения функций, время передачи выходных данных, объем данных, схема приоритетов исходных данных, весовые коэффициенты выходных данных, параллельные процессы, категории ресурсов, комплексные ограничения и др.
  • контроль корректности разработанной модели, выявление ошибок и неоднозначностей;
  • изменение характеристик входящих потоков и распределения ресурсов по принципу "что-если";
  • возможность использования в модели пользовательских программ;
  • сбор статистических данных и генерация разнообразных отчетов;
  • использование анимационных эффектов для демонстрации работы модели.

    Пакет S-Designor компании Powersoft - для создания концептуальных и физических моделей структуры базы данных.

    Основными особенностями S-Designor являются:

  • поддержка широкого класса объектов моделирования: сущности, элементы данных, связи, наследования, атрибуты, домены, таблицы, ссылки, столбцы, индексы, представления, триггеры, хранимые процедуры;
  • возможность использования правил обработки данных, построенных на основе анализа бизнес-процессов;
  • автоматическая генерация физической модели данных;
  • разделение больших моделей на подмодели с сохранением уникальности определений объекта;
  • средства порождения моделей (обратное проектирование): физической модели из существующей базы данных, концептуальной модели из физической;
  • поддержка свыше 30 баз данных: Sybase, Oracle, Informix, Ingres, SQL Server, SQL Base, Progress, Access, Paradox, FoxPro и др.;
  • генерация стандартных и заказных отчетов;
  • экспорт и импорт данных.

    Все перечисленные пакеты широко использовались для создания проектов крупных информационных и бизнес-систем, связанных с анализом, реорганизацией и автоматизацией деятельности предприятий в различных странах, секторах рынка, с многообразием направлений деятельности, видов продукции, способов организации бизнеса и т.д.

    Необходимо отметить, что в результате описанного выше подхода к построению корпоративной информационной системы сформировалась качественно иная чем прежде трехслойная архитектура информационной системы, основными компонентами которой являются:

  • слой правил бизнеса, определяющий внутренние правила выполнения бизнес-процессов и организации работ;
  • слой корпоративных электронных архивов и баз данных;
  • слой прикладных систем, обеспечивающих ввод, обработку и анализ данных в соответствии с правилами организации бизнеса предприятия.

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

    []
    []
    []

    Построитель Интерфейса Пользователя (User Interface Builder)

    Построитель Интерфейса Пользователя (User Interface Builder) является объектно-
    ориентированной средой визуального программирования, которая позволяет Вам быстро строить
    самые сложные приложения, просто задавая связи между поставляемыми фирмой или созданными
    Вами многократно-используемыми (reusable) объектами. В дополнение к технологии визуальной
    разработки экрана и использованию уже созданных объектов, Построитель Интерфейса имеет
    логику доступа к данным и средства автоматической генерация кодов пользовательского
    интерфейса, что позволяет значительно увеличить производительность труда разработчиков и
    качество самого приложения. При этом использование Построителя Интерфейса PROGRESS
    уменьшает стоимость разработки приложения за счет уменьшения количества непосредственного
    кодирования, которое приходится выполнять разработчикам.

    Визуальное программирование.

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

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

    соответствии с конкретными требованиями приложения.

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

    Использование ранее созданных объектов (reusable objects)

    Построитель Интерфейса делает процедуру создания, поиска, управления и использования ранее
    созданных объектов весьма простым делом. Определение пользователем объектов Построителя
    Интерфейса увеличивает Вашу производительность, позволяя воспользоваться результатами той
    работы, которая уже была проделана Вами или членами Вашей группы разработчиков. Повторно
    используемые объекты могут быть созданы либо при помощи Построителя Интерфейса либо
    Редактора Процедур, и могут содержать в себе программный код, определение объектов
    Интерфейса, или то и другое вместе взятое. Если Вы собираетесь переходить к объектно
    ориентированному принципу разработки приложений, то использование определяемых
    пользователем объектов интерфейса будет вашим первым шагом в этом направлении.

    Поддержка интерфейсов для символьных и графических терминалов

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


    Интерфейса Пользователя.

    Различные платформы, под которые разрабатывается Интерфейс Пользователя, такие как
    Windows, Motif и символьные терминалы, рассматривают процедуру позиционирования и
    определения размеров объектов пользовательского интерфейса с совершенно различных точек
    зрения. Возможность Альтернативной Планировки экрана (Alternate Layout) в Построителе
    Интерфейса использует свойство наследования для того, чтобы позволить Вам быстро создавать и
    модифицировать различные версии одного и того же окна для самых различных терминалов.
    Альтернативная Планировка позволяет сохранять и компилировать различные варианты
    графических окон в одном исходном файле, что упрощает распространение приложений,
    предназначенных для работы на терминалах в различных графических средах. Подобные
    возможности позволят Вам быстро и эффективно проектировать по-настоящему переносимые
    приложения.

    Генерация 4GL кода

    Построитель Интерфейса включает в себя мощные средства для генерации кода, нацеленные на
    снижение стоимости разработки сложных форм, меню и экранов, предназначенных для управления
    списками файлов. В отличие от аналогичных средств, Построитель Интерфейса PROGRESS
    "заранее" знает о типе используемых данных и автоматически генерирует необходимую логику для
    взаимодействия с конкретными данными. Это означает, что Вам не нужно знать язык SQL для
    использования Построителя Интерфейса. В подавляющем большинстве случаев вся логика
    взаимодействия с данными Вашего окна генерируется автоматически - Вам не требуется даже
    визуально определять ее. Эти возможности по генерации кода позволяют создавать и встраивать в
    Построитель Интерфейса повторно используемые формы и шаблоны, содержащие логику
    приложения, тем самым увеличивая производительность разработки, надежность самого
    приложения и уменьшая стоимость его последующей поддержки.

    Построитель Интерфейса является открытым средством разработки, поддерживающим стандарт
    Программного Интерфейса Приложений (API), что позволяет включать в процесс разработки


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

    Событийно-управляемое (Event-Driven) Программирование и Триггеры (Triggers) Интерфейса
    Пользователя. Возлагая на приложения заботу о пользователе, событийно-управляемые
    приложения, написанные на PROGRESS, делают труд пользователей более продуктивным и
    приятным. Наряду с управлением визуальными атрибутами интерфейса пользователя,
    Построитель Интерфейса позволяет Вам определять, - каким образом приложения должны
    реагировать на происходящие внешние события. Конечные Пользователи взаимодействуют с
    событийно-управляемыми приложениями посредством набора операций, называемых событиями
    интерфейса пользователя. В качестве примера одного из таких событий можно привести выбор
    опции меню, ввод данных в поле, изменение размера окна, нажатие клавиши на экране.
    Построитель Интерфейса позволяет создавать процедуры на языке 4GL, связанные с этими
    событиями. Эти процедуры называются Триггерами Интерфейса Пользователя. Редактор
    Триггеров, встроенный в Построитель Интерфейса позволяет быстро понять и отредактировать
    логические взаимосвязи между тем, как будет выглядеть и, как будет реагировать на внешние
    события Ваше приложение.

    Определение Триггеров Интерфейса Пользователя для любого элемента или события, дает Вам
    возможность более гибкого контроля за поведением приложения.

    Организация исходного кода и логики приложений.

    В дополнение к определению объектов интерфейса пользователя и триггерам, оконные объекты
    PROGRESS также инкапсулируют определения переменных и внутренних процедур или "методов".
    Наличие этих элементов поможет Вам легко создавать и поддерживать сложные многооконные и
    многомодульные приложения, характерные для современного мира. Редактор Разделов (Section
    Editor) в Построителе Интерфейса позволяет создавать и размещать разделы этих определений для
    эффективной координации взаимодействия модулей в приложениях со сложной логикой работы.
    Редактор Разделов обеспечивает быстрый доступ и возможность редактирования следующих
    разделов для оконных объектов:


  • Раздел Определений. Здесь Вы определяете переменные,
    константы и параметры, которые управляются или используются оконными
    объектами PROGRESS. Может возникнуть ситуация, когда на экране
    одновременно должно появиться несколько одних и тех же оконных объектов,
    одновременно активных, и каждый такой объект будет управлять или
    "инкапсулировать" свои собственные данные, что позволяет легко создавать
    сложные многооконные приложения.
  • Раздел Процедур инициализации и закрытия окон. Вы управляете
    логикой приложения, инициализирующей инкапсулированные данные окна и
    активируете оконные объекты интерфейса пользователя. После
    инициализации окно остается в состоянии готовности и ожидания отклика на
    события и команды Пользователя "или сообщения", полученные от других
    оконных объектов или объектов приложения. Здесь также указывается, какие
    должны быть выполнены действия при закрытии окон, чтобы обеспечить
    правильное состояние объектов
  • Раздел Внутренних процедур. Внутренние процедуры или "методы"
    - это функции, которые могут быть вызваны или повторно использованы в
    одном или нескольких триггерах оконного объекта. Использование внутренних
    процедур уменьшает количество времени и усилий, необходимых для описания
    поведения оконного объекта.


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

    Завершенность и гибкость

    Построитель Интерфейса сочетает в себе мощь, завершенность и переносимость языка 4-го
    поколения PROGRESS (4GL). Экраны и окна, спроектированные на одной машине под одним
    пользовательским интерфейсом (MS Windows, Motif или символьный) легко могут быть
    перенесены и запущены на другой машине с другим пользовательским интерфейсом. Такая,
    присущая языку переносимость, максимизирует продуктивность разработки и позволяет Вам
    использовать однажды разработанное приложение на огромном множестве платформ, не прибегая
    к дополнительному перепрограммированию.

    Повышение производительности и мониторинг производительности

    Использование журнала транзакций в SQL Anywhere уменьшает время фиксации каждой
    транзакции. Сервер SQL Anywhere является 32-разрядным (кроме платформы Windows 3.X).

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

    Окно статистики в интерактивном средстве для формирования запросов (ISQL) позволяет
    просмотреть выбранный план выполнения любого оператора SQL.

    В SQL Anywhere предусмотрен набор статистической информации, предназначенной для оценки
    производительности. Эта информация доступна из инструмента администратора SQL Central и
    приложений-клиентов. В дополнение, подобная информация предоставляется из SQL Anywhere в
    монитор производительности Windows NT.


    PowerBuilder - среда разработки приложений масштаба предприятия

    А.Чибисов, фирма Метатехнология

    PowerBuilder™ - это объектно-ориентированный инструмент для профессиональной разработки
    приложений в среде клиент/сервер, позволяющий коллективам разработчиков легко и быстро создавать
    графические приложения, которые имеют доступ к базам данных и другой корпоративной информации,
    хранящейся локально или на сетевых серверах.

    Правила и начальные значения

    В ERwin поддерживаются два типа правил (проверок допустимости значений) и начальных (по
    умолчанию) значений. Правило и умолчание может быть указано для проверки со стороны клиента
    (например, в PowerBuilder) и со стороны сервера.

    При задании правила или умолчания для клиентской части эти атрибуты переносятся в репозитарий
    средства 4GL.

    На рис.10 показан диалог для задания значений по умолчанию,
    устанавливаемых в PowerBuilder. Заметьте, что в одном и том же диалоге задаются умолчания,
    подставляемые как на стороне клиента, так и на стороне сервера (в данном случае - Sybase).

    Правила и начальные значения

    Преимущества и недостатки архитектуры клиент- сервер

    Под лозунгом "Upsizing application" компания Borland выпустила серию инструментов
    разработчика, которые с успехом применялись и применяются при разработке клиент-серверных
    проектов. Это прежде всего 16-разрядный Delphi 1.0, доступный на рынке уже в течение года,
    вышедший с 1 марта 1996 года Delphi 2.0 для Win 95/NT, Paradox 5.0, выходящий с декабря 1995 года
    Paradox 7, Visual dBase 5.5, C++ 4.5 c BDE 2.5 и выходящий с конца марта C++ 5.0 с BDE 3.0 для
    Windows 95/NT. При помощи этих инструментов можно разрабатывать локальные приложения для
    баз данных, а затем легко мигрировать в архитектуру клиент-сервер.


    Если в локальных приложениях эти инструменты напрямую работают с данными, то в архитектуре
    клиент-сервер данные с сервера доступны посредством запросов к серверу, а SQL-сервер
    занимается поиском и поддержанием целостности данных. По сравнению с файл-серверной
    архитектурой мы имеем реальные преимущества - более низкий сетевой трафик и большая
    надежность хранения данных. Кроме того, при разработке информационной системы в
    архитектуре клиент-сервер немаловажное значение имеет доступность CASE-средств, облегчающих
    проектирование сложной системы.

    Однако, как только мы задумываемся о создании клиент-серверной системы на более чем 100-200
    клиентских мест, сразу возникают дополнительные сложности. Во-первых, стоимость коннекта -
    стоимость клиентской лицензии для SQL-сервера в среднем достаточно высока и при умножении
    ее на соответствующее количество возникает пугающая цифра. Во-вторых, даже если отбросить в
    сторону финансовые соображения, существуют и дополнительные сложности. На каждый
    клиентский коннект сервер должен выделять значительное количество памяти на аппаратуре
    серверной машины, в зависимости от типа SQL-сервера это количество разное, однако общая
    тенденция очевидна. Вероятность того, что в действующей системе потребуется доступ к данным с
    клиентских станций разных типов и моделей, достаточно высока - в большой корпоративной или
    мешкорпоративной системе мы имеем зоопарк различной техники - от терминалов и 286 моделей
    до серьезных UNIX-станций. В большой информационной системе, как правило, наблюдается и
    разнобой физической реализации коммуникаций - от модемных соединений 2400 бод до
    оптоволокна c FDDI. Как быть, и реально ли в таких условиях говорить о приемлемом клиент-
    серверном решении задачи построения информационной системы?


    Симметричная архитектура Microsoft SQL Server

    Симметричная архитектура Microsoft SQL Server предоставляет следующие преимущества:


  • снижает сложность системы

    SQL Server не дублирует службы операционной системы (такие как диспетчирование,
    распределение памяти, управление очередями), что делает архитектуру системы более эффективной
    и стабильной;


  • повышает производительность

    SQL Server способен обеспечить высокую скорость выполнения транзакций и обладает высокой
    пропускной способностью на микропроцессорных системах, даже при одновременной работе сотен
    пользователей;


  • адаптируется к росту нагрузки

    Нагрузка на SQL Server динамически распределяется по нескольким ЦП, что повышает
    масштабируемость на симметричных многопроцессорных системах.


  • повышает надежность

    Задачи пользователя исполняются в самостоятельных потоках, и при необходимости одна задача
    принудительно завершается, не оказывая влияния на выполнение остальных. Например, SQL
    Server способен прервать "спящий" процесс без того, чтобы это оказало влияние на работу всей
    системы. Ни одна задача не может "выйти из-под контроля".

    Преимущества SQL-DMF


  • упрощает процесс управления распределенными серверами за счет
    предоставления современного пользовательского интерфейса
    административной консоли для всех задач управления и интеграции
    компонентов управления и инструментов администратора, а также сервисов
    внутри основного продукта;
  • предоставляет масштабируемую среду управления, которая может быть
    адаптирована к конкретным потребностям малых и крупных заказчиков.
    Разработчики могут расширить набор стандартных инструментов за счет
    встроенных OLE объектов управления и поддержки средств визуальной
    разработки;
  • делает удаленные серверы более самостоятельными с точки зрения
    управления средствами сервисов, взаимодействующих с процессором данных
    сервера (диспетчирование, события/предупреждения, тиражирование). Они
    могут быть запрограммированы для выполнения административных задач без
    участия человека;
  • предоставляет администраторам баз данных инструментарий,
    позволяющий перейти от защитной к активной модели администрирования с
    использованием развитой модели обработки событий/предупреждений для
    назначения корректирующих действий при возникновении определенного рода
    проблем или условий (например, переполнение журнала), вызываемых через
    триггеры или предупреждения.


    Преодоление ограничений реляционного подхода

    Среди наиболее существенных ограничений реляционного подхода можно отметить:


  • невозможность использования одинакового объектно-ориентированного
    подхода при разработке баз данных и приложений, их использующих;
  • невозможность определения новых типов данных с использованием
    предоставляемых системой или ранее определенных типов;
  • отсутствие механизмов наследования и инкапсуляции;
  • невозможность связывать с данными операции их обработки.

    Первое из перечисленных выше ограничений является препятствием для использования объектного
    подхода к разработке приложений РСУБД.

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

    Для решения этой проблемы IBM предлагает специальные библиотеки классов для доступа к DB2 с
    использованием средств разработки приложений семейства VisualAge. Эта библиотека позволяет
    использовать для работы с отношениями DB2 объекты специальных классов С++ или
    Smalltalk.

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

    В настоящий момент IBM предлагает средства, частично снимающие и остальные ограничения href="#lit">[7]    , большинство из которых впервые реализованы в вышедшем в 1995 году
    продукте DB2 Common Server.


    Пример разработки модели в ERwin

    Рассмотрим цикл разработки на примере, приведенном в статье Кодда .

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

    Сначала создадим логический уровень модели. Для этого зададим режим отображения сущностей
    (Display/Entity Level). Создадим при помощи линейки инструментов сущности "служащий", "дети",
    "история работы", "история зарплаты". Будем именовать сущности на русском языке.

    Выбрав каждую сущность, зададим для нее подробное описание на русском языке в редакторе "Entity
    Definition". Это описание появится в отчетах ERwin и может быть отображено на диаграмме.

    Укажем связи между сущностями. Например, "служащий" связан идентифицирующей связью "является
    родителем" с сущностью "дети". Описание связи вводится в редакторе "Editor/Relationship".

    Результат работы отображен на диаграмме ERwin (рис. 2).

    Пример разработки модели в ERwin

    Прочие возможности

    До сих пор объекты типа VIEW (представление) могли быть модифицированы только в том
    случае, если они строились на основе одной таблицы и не содержали вычисляемых столбцов. В
    версии 7.3 можно модифицировать VIEW, полученные в результате соединения нескольких
    таблиц.

    Некоторые улучшения внесены в механизм сложной репликации (advanced replication option).
    Теперь она позволяет выполнять не только асинхронную (через определенные интервалы времени),
    но и синхронную репликацию данных. Возможно объединение таблиц БД в группы (подсхемы) и
    задание репликации для всей подсхемы.


    Проектирование баз данных: новые требования, новые подходы

    Е.З.Зиндер, Корпорация ЛВС

    "Попытка навязывать некоторую технологию
    или
    инструмент для удовлетворения специфической потребности,
    для которой другой
    инструмент более действенен
    и эффективен, подобна попытке "ввернуть" шуруп
    в
    стену молотком, когда отвертка - под рукой:
    шуруп может, в конечном счете,
    войти в стену,
    но во что это встанет?"

    E.F.Codd, S.B.Codd, and C.T.Salley.

    Providing OLAP to User-Analyst: An IT Mandate.

    E.F.Codd & Associates, 1993.

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


    Проектирование прикладной системы

    На этапе проектирования формируются все спецификации, описывающие структуру и основные
    компоненты будущей системы. Как и на предыдущем уровне эти спецификации разделяются на
    информационные и функциональные - на описание базы данных и описание состава программных
    модулей системы.

    При описании базы данных указывается, какие таблицы в нее входят, специфицируются основные
    характеристики этих таблиц, состав столбцов каждой из них, уточняются параметры столбцов (тип
    значений, ограничения на допустимые значения, значения, принятые по умолчанию,
    статистические характеристики использования и многие другие), задаются ограничения
    целостности - логические условия, которые должны выполняться при любом содержании таблиц.
    Кроме того, описываются дополнительные объекты базы данных ORACLE, такие как индексы,
    кластеры, последовательности, основное назначение которых связано с повышением
    эффективности работы с базой данных, ускорением доступа к часто используемой
    информации.

    Функциональные возможности системы определяются спецификацией модулей различных типов,
    основными из которых являются экранные формы, обеспечивающие доступ пользователей к
    информации базы данных, отчеты, используемые для вывода данных в специализированном виде,
    удобном для дальнейшего анализа, меню, описывающие логику работы системы, процедурные
    модули. Предполагается, что эти типы модулей позволяют описать функционирование системы
    практически в полном объеме, как можно меньше прибегая к использованию дополнительных
    средств таких, как, например, процедуры, написанные на внешних языках программирования. Это
    поддерживается, в частности, достаточно развитыми возможностями выполнения вычислений
    непосредственно в формах и отчетах: например, наличие в формах аппарата триггеров позволяет
    включать в модуль типа формы алгоритмы обработки практически любой степени
    сложности.

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

    Первоначальный вариант спецификаций можно сформировать автоматически с помощью
    специальных утилит, к которым относятся:


  • утилита автоматической генерации спецификаций базы данных по ER-
    модели;
  • процедура генерации спецификаций модулей по иерархии функций и
    потокам данных.

    С помощью утилиты автоматической генерации проекта базы данных по ER-диаграмме будут
    построены спецификации будущей базы данных - ее состав таблиц, перечень столбцов каждой из
    них, уточнение характеристик столбцов, описание ограничений целостности и т.д.

    При генерации схемы базы данных по ER-модели каждой сущности ставится в соответствие
    таблица, атрибутам - столбцы таблиц, а для каждой связи создаются дополнительные столбцы и
    определяются ограничения целостности типа внешних ключей (foreign key constraint). Подтипы
    сущностей в ER-модели реализуются в схеме базы данных в виде одной общей таблицы или в виде
    совокупности нескольких - по одной на каждый подтип.

    По иерархии функций и диаграммам потоков данных могут быть автоматически сгенерированы
    спецификации программных модулей прикладной системы, описывающие общие характеристики
    модулей, с какими таблицами работает каждый из них, возможные действия с этими таблицами и
    т.д. При этом анализируется диаграмма иерархии функций и для каждой элементарной функции
    (нижней в иерархии) создается спецификация модуля. Тип модуля устанавливается по
    определенным правилам в соответствии с указанным для функции способом работы с сущностями.
    Например, если известно, что функция использует сущности только для чтения информации, то
    считается, что ей должен соответствовать модуль типа отчет. Предусмотрена также возможность
    "объединять" некоторые однотипные функции, т.е. создавать один модуль сразу для нескольких
    различных элементарных функций. Основой для такого "объединения" служит также характер
    использования функциями сущностей - если две функции работают с одними и теми же сущностями
    и одинаково их используют, то это может считаться основанием для создания для них одного


    общего модуля. Разработчику предоставляется возможность регулировать уровень "объединения"
    функций путем выбора одного из имеющегося набора критериев.

    Для работы со всевозможными спецификациями уровня проектирования в DESIGNER/2000
    предусмотрен целый набор графических редакторов, каждый из которых ориентирован на
    спецификации определенного типа.

    Использование на этом уровне графических моделей - диаграмм, является важной новой
    особенностью CASE-средств фирмы ORACLE. В предыдущих версиях, как и во многих CASE-
    системах других фирм, графические диаграммы используются обычно только на концептуальном
    уровне для ER-моделей, функциональных иерархий и т.д. В то же время, опыт практической
    деятельности в области CASE-технологий показывает, что использование графических
    изображений полезно и для представления структуры базы данных, схем взаимодействия
    программных модулей и т.д.

    В DESIGNER/2000 для этой цели предусмотрены:


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

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

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

    Проектирование прикладной системы

    Проектирование приложений (подсистем)

    На основе концептуальной ER модели строится реляционная модель данных. Части ER-модели,
    соответствующие различным приложениям, оформляются как подсхемы базы данных. Для каждого
    приложения создается (возможно, разными группами разработчиков) детальный проект. Строится модель
    системных процессов (программных функций) и подсхемы базы данных для каждой функции
    (спецификация интерфейса). Поскольку все приложения работают с подсхемами одной базы данных,
    обеспечивается их совместная работа. Результат: Реляционная модель данных. Для каждого приложения -
    Модель данных приложения, Модель системных процессов. Для каждого интерфейса в приложении -
    Спецификация интерфейса.


    Программирование событий окна и органов управления

    Как само окно, так и его органы управления являются объектами, образованными от стандартных
    оконных и визуальных классов NewEra. Для них предопределены множества стандартных событий
    (табл. 1).

    Таблица 1

    Примеры событий в объектах визуальных классов


    Класс
    Событие
    Когда наступает
    окно
    		 start
    		при открытии окна
    многие органы
    		 activate
    		при активации, например, управления
    окна щелчком мыши
    супертаблица
    		 beforeRetrieve
    		перед началом выполнения
    выборки
    супертаблица
    		 rowRetrieve
    		после выборки очередной
    строки

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


    Программирование триггеров и процедур

    ERwin реализует собственный макроязык для подготовки прототипов триггеров и процедур. Схема
    использования прототипов заключается в подготовке шаблона для различных типов триггеров
    (например, триггер, реализующий логику каскадного удаления - ON DELETE CASCADE). Базовые
    шаблоны встроены в ERwin, но пользователь может определить свои собственные шаблоны и
    использовать их вместо стандартных.

    Макроязык шаблонов реализует большое количество макросимволов, ссылающихся на различные
    объекты базы данных, например:

    %Action - расширяется в UPDATE/INSERT/DELETE;
    %ForEachAtt(<таблица>,<разделитель>) { <код макрокоманды> } -
    циклическое выполнение группы операторов над каждым атрибутом таблицы;
    %ForEachEntity() { } - циклическое выполнение функций над всеми таблицами;
    %If, %else - операторы условного управления.
    Например, шаблон триггера для реализации поддержки on delete cascade:
    %Action /* ERwin Builtin %Datetime */
    /* %Parent %VerbPhrase %Child ON PARENT DELETE CASCADE */
    delete %Child
    from %Child,deleted
    where
    /* %%JoinFKPK(%Child,deleted," = "," and") */
    %JoinFKPK(%Child,deleted," = "," and")
    В модели, приведенной выше для связи positions - salary_track будет сгенерирован следующий
    прототип триггера:

    DELETE /* ERwin Builtin Fri Jun 02 17:12:09 1995 */
    /* positions приносила доход salary_track ON PARENT DELETE CASCADE */
    delete salary_track
    from salary_track, deleted
    where
    /* %%JoinFKPK(%Child,deleted," = "," and") */
    salary_track.empl_id = deleted.empl_id
    Все макрофункции, которые могут использоваться в триггерах, могут использоваться также и в
    процедурах. Существенно, что процедуры, как и триггеры, связываются с таблицей.

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


    Программирование взаимодействия с серверами СУБД

    NewEra поддерживает два способа программирования доступа к базам данных:

  • операторы встроенного SQL;
  • интерфейс библиотеки классов CCL (Connectivity Class Library).
    Преимущества первого способа - простота и наглядность, совместимость с языком Informix-4gl;
    однако, приложение, включающее операторы встроенного SQL, не может работать с СУБД,
    отличными от Informix.

    Интерфейс CCL - объектный интерфейс к базам данных, который обеспечивает открытость
    приложений по отношению к используемым СУБД. Модули приложения, основанного на
    интерфейсе CCL, обращаются при выполнении к одной из двух динамических библиотек,
    поставляемых с Informix-NewEra (рис. 2):

    CCL/Informix - реализует взаимодействие с базами данных Informix;

    CCL/ODBC - реализует взаимодействие с произвольной СУБД через интерфейс ODBC.

    Программирование взаимодействия с серверами СУБД

    Программный интерфейс

    Основным программным интерфейсом SQLBase является SQL API - библиотека функций на языке
    C, реализующая все возможности управления СУБД. Помимо базового интерфейса SQL API
    существует большое количество программ и библиотек, реализующих собственные интерфейсы к
    SQLBase. Среди них нужно прежде всего отметить SQLBase++ (библиотеку классов в стандарте
    MFC), Borland Delphi и целый ряд языков и систем 4 поколения, включающих SQLWindows
    (Gupta), PowerBuilder (Powersoft), Crystal Reports и Crystal Info.


    Progress V.8: распределенные приложения на основе компонентного 4GL

    Ю.Гусев, CSBI EE
    Представляем инструментальные средства профессионального класса - PROGRESS (Copyright -
    Progress Software Co., USA). Основные характеристики PR сравнимы (что-то чуть лучше, что-то
    чуть хуже) с конкурентами (Oracle, Informix, Ingres, etc.), но по такому показателю как
    удовлетворенность пользователя, по оценкам организации DATAPRO (USA), PR на первом месте
    в течение 4 последних лет.

    PROGRESS - полностью интегрированная среда разработки и применения приложений со своими
    полностью реляционной СУБД, языком 4GL и встроенным SQL, средствами ускоренной
    разработки, шлюзами (DataServers) к базам других популярных СУБД (Oracle, Rdb, RMS, DBF, Q-
    ISAM, etc.), библиотеками для C, Pascal, COBOL. PROGRESS работает на огромном числе
    программно-аппаратных платформ - от PC до mainframe с операционными системами MS-DOS,
    OS/2, Novell, UNIX (SCO, Interactive, SunOS, A/UX, AIX, HP-UX, ULTRIX, etc.), VMS, C,
    OS/BTOS, OS/400. PROGRESS поддерживает сетевые протоколы SPX/IPX, DECnet, TCP/IP,
    NetBIOS, интерфейсы MS-Windows, X-Window (MOTIF, OpenLook), архитектуру клиент-сервер и
    распределенные базы данных в сложных гетерогенных сетях.


    PROGRESS version 8 - интернационализация и поддержка национальных алфавитов

    Б.Меленевский, CSBI EE
    Одним из основных требований к СУБД с точки зрения Открытых Систем является требование
    адаптации к национальной информационной среде. При рассмотрении вопросов
    интернационализации обычно выделяют три основные момента


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

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


    Производительность и масштабируемость

    Microsoft SQL Server 6.0 имеет параллельную архитектуру, интенсивно использующую
    многопоточность операционной системы для обеспечения высокой производительности и
    масштабируемости на многопроцессорных системах. Все управление задачами SQL Server
    организовано вытесняющим для повышения надежности и изолирования возможных сбоев. За счет
    динамического распределения нагрузки на процессоры SQL Server достигает автоматической
    балансировки загрузки всех ЦП компьютера. Microsoft называет это "симметричной архитектурой
    сервера".


    Производительность СУБД : измерение и оптимизация


    (тезисы доклада)

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

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

    Первая часть доклада содержит краткое описание проблем, возникающих при измерении
    производительности и описание подходов к построению квалифицированных методик
    измерения.

    Далее подробно рассматриваются тесты TPC (Transaction processing Performance Council - Совет по
    производительности систем обработки транзакций), а также некоторые другие распространенные
    методики измерения производительности.

    При рассмотрении тестов TPC особое внимание уделено как наиболее распространенному в
    настоящее время тесту TPC-C, предназначенному для измерения производительности систем
    оперативной обработки транзакций, так и новым разработкам TPC - тестам TPC-D, TPC-E и TPC-
    S, предназначенных для систем поддержки принятия решений и серверных компонентов системы.
    В докладе не рассматриваются два наиболее широко известные теста, TPC-A и TPC-B, так как эти
    методики считаются устаревшими и не поддерживаются TPC в настоящий момент.
    Наиболее известные среди других рассматриваемых тестов, не относящихся к семейству TPC, -
    тесты Wisconsin Benchmark и AS3AP.

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

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


    []
    []
    []

    Протокольные службы

    Библиотеки Sybase обеспечивают работу серверных и клиентских компонент со множеством
    сетевых протоколов от разных производителей, в том числе TCP/IP, SPX/IPX, Named Pipes,
    DECNet и другие.

    Архитектура Sybase позволяет как приложению-клиенту, так и серверу одновременно работать с
    несколькими интерфейсами. Например, SQL Server для Novell NetWare или Windows NT может
    одновременно допускать соединения через SPX и TCP/IP.

    Сводные особенности SQL Server 11 приведены на рис. 7.


    SQL Server 11.0 - основные особенности
    Быстрый ввод/вывод

  • Разделение областей данных
  • Параллельная загрузка (BCP)
  • Опережающее считывание
  • Много буферов кэша
  • Обновления на месте

    Удобство пользования

  • Новый интерфейс конфигурирования
  • Простой Upgrade от 1.0
  • Атрибуты объектов
  • Анализатор кэшей

    		• Баланс загрузки

  • Локализация кэшей
  • Симметричная работа с сетью
  • Симметричное управление блокировками
  • Улучшенный менеджер транзакций
  • Оптимизатор запросов

    Эффективное ведение журнала

  • Раздельные кэши для журналов
  • Задача - House Keeper

    Большое адресное пространство

  • Более 2 Гигабайт адресуемой памяти (на DEC UNIX и др.)



    • Протоколы

    SQLBase осуществляет поддержку практически всех распространенных сетевых протоколов,
    включая IPX/SPX для NetWare, NetBIOS, NetBEUI, Named Pipes и TCP/IP (Windows Sockets) для
    Windows NT и OS/2. Для Windows 95 и Windows NT фирма Gupta разработала новый 32-
    разрядный протокол обмена данными Anonimous Pipes для эффективной работы с локальным
    сервером SQLBase в этих средах. Кроме этого, SQLBase поддерживает технологию SNMP, что
    позволяет эффективно управлять сервером баз данных в сложных распределенных сетях под
    управлением Novell NetWare. Новая версия SQLBase, которая находится сейчас в стадии Бета-
    тестирования и будет выпущена в продажу в конце января, будет включать поддержку протокола
    TCP/IP для NetWare.

    SQLBase поддерживает стандартный интерфейс связи с базами данных в среде Windows ODBC.
    Драйвер ODBC входит в комплект каждого сервера SQLBase.


    Проверка правильности спроектированной модели

    Данная возможность связана с тем, что проектирование в S-Designor можно выполнять в
    свободном порядке. Например, проектировать сначала сущности и связи, потом атрибуты сущностей.
    Такой подход в ряде случаев удобен и возможен потому, что S-Designor ведет общий словарь
    данных, используемых в модели. При проверке правильности структуры объектов (в основном
    сущностей и взаимосвязей между ними), S-Designor формирует протокол об ошибках, в
    котором содержится полная идентификация ошибок в модели данных.


    Проверка взаимных блокировок

    SQL Server использует алгоритм выявления взаимных блокировок транзакций. Имеется
    возможность сконфигурировать то время, через которое выполняется такая проверка. Время
    задается в миллисекундах, от 500 мс. Цель конфигурирования этого параметра - повышение
    производительности. Проверка взаимоблокировок - это достаточно длительная операция для
    сервера. Так как проверка запускается не сразу, выше вероятность освобождения ресурса к
    моменту запуска проверки. С другой стороны, излишнее увеличение времени задержки может
    привести к увеличенному времени реакции для приложения, выдавшего взаимоблокирующий
    запрос.


    Работа c источником данных в виде пакета SQL- предложений (DDL)

    Данная возможность позволяет проектировать структуру данных и выполнять генерацию SQL-
    предложений не подключаясь к SQL-серверу. Генерация пакета SQL-предложений выполняется в
    обычный текстовый файл. На основании содержимого файла можно выполнить обратное
    проектирование - создать модель данных. Практическая польза - своеобразная "отладка" модели
    данных. Это дает возможность лишний раз убедиться в правильности действий, предполагаемых
    выполнить с реальной структурой БД. Поскольку, в данном случае нет необходимости подключаться
    к серверу БД - проектирование можно выполнять автономно. Например, в домашних условиях, если у
    Вас дома нет SQL-сервера.


    Работа SQL Server с кэшами в памяти

    Запись в журнал из кэша теперь происходит пакетами. Это снижает уровень конкуренции за доступ
    к ресурсу журнала и, соответственно, повышает производительность (рис.5).


    Производительность: Именованные кэши
    Работа SQL Server с кэшами в памятиBEGIN
    UPDATE
    UPDATE
    UPDATE
    INSE
    RT
    COMMIT    		Работа SQL Server с кэшами в памяти

  • Записи передаются в журнал пакетами
  • Уменьшается уровень конкуренции за доступ к ресурсу журнала



    • Расчет необходимой внешней памяти под БД

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


    Распределенная обработка и доступ к данным средствами Sybase OmniConnect

    В различных узлах предприятия используются базы данных от разных производителей. Например,
    в системе принятия решений это может быть Sybase, а в геоинформационной системе - Oracle.

    OmniConnect осуществляет унифицированный доступ приложений к разнородным источникам
    данных. Специальные шлюзовые компоненты организуют работу в системе с любой
    промышленной СУБД, включая Oracle, Informix, Ingres, DB/2, RMS, ISAM. Приложения-клиенты
    при этом работают только с сервером OmniConnect на диалекте SQL фирмы Sybase (TransactSQL),
    а необходимая трансляция языка SQL и преобразование типов данных автоматически
    осуществляется шлюзовыми модулями.

    Для работы с хранилищами данных на "больших" ЭВМ (mainframe) Sybase поставляет также
    продукцию фирмы Micro Decisionware - лидера на рынке промежуточного ПО (Sybase купила
    фирму MDI в начале 1994 года). MDI предоставляет шлюзы в DB/2, SQL/DS, SQL/400, в том числе
    через IBM DRDA-интерфейс.

    OmniConnect хранит информацию о размещении таблиц на том или ином сервере БД.
    Централизованно хранятся и исполняются глобальные хранимые процедуры. Приложение-клиент
    может осуществлять транзакции, в которых участвуют таблицы из различных БД, а также
    выполнять процедуры, которые OmniConnect при работе с СУБД, отличными от Sybase,
    прозрачно преобразует к соответствующему диалекту SQL.


    Распределенное приложение (серверы приложений)

    Характерной чертой таких приложений является логическое разделение приложения на две или
    более частей, каждая из которых может выполняться на разных компьютерах. Выделенные части
    приложения взаимодействуют друг с другом, обмениваясь сообщениями в заранее
    согласованном формате. Следует подчеркнуть, что в данном случае клиентом может быть не
    только Windows-приложение, но и приложение (или его часть), выполняемое на одной из платформ
    СЭВМ.

    Для создания среды выполнения распределенных приложений SOFTWARE AG предлагает
    использовать продукт ENTIRE BROKER, который может быть установлен на платформе любой
    СЭВМ (IBM, UNIX и т.д.) изолированно (рис. 4) или на одной или
    нескольких СЭВМ совместно с серверами приложений.


    ЭВМ 1ЭВМ NПлатформы клиентов
    Распределенное приложение (серверы приложений)
    Windows PCUNIXIBMOS/2, NT


    Расширение возможностей языка и программного доступа

    Существующая версия SQL Server снабжена мощным языком программирования -Transact-SQL,
    позволяющим создавать сложную логику триггеров и хранимых процедур. В новой версии язык
    значительно расширен, теперь он соответствует стандарту ANSI-92, и программисты получили
    новые возможности (такие как новые, соответствующие ANSI-стандарту, типы данных и
    соответствующая стандарту ANSI поддержка декларативной целостности данных). Помимо
    перечисленных возможностей, программист может воспользоваться генератором, автоматически
    создающим уникальные значения для ключевых полей таблицы, возможностью передавать
    идентификаторы и данные типа TEXT и IMAGE как параметры хранимым процедурам и многое
    другое. Использование хранимых процедур, которые запускаются автоматически при каждом
    старте SQL Server, позволяет создавать системы, способные выполнять различного рода задания
    без участия администратора. Наиболее же интересным нововведением являются скроллируемые,
    двунаправленные курсоры. Курсоры SQL Server поддерживают все режимы, определенные
    расширенными требованиями ANSI, а также и ODBC семантику; они совместимы с
    существующими курсорами, поддерживаемыми API в DB-Library.


    Расширение возможностей языка сервера

    В языке PL/SQL появились объекты типа таблица (группа однотипных полей или структур
    (таблица записей)). Программист может использовать функции FIRST, LAST, NEXT, PRIOR,
    COUNT, EXISTS, DELETE при работе с таблицей PL/SQL. Новый пакет ULT_FILE
    расширяет язык PL/SQL функциями для работы с файлами операционной системы сервера. Файлы
    можно создавать, читать, писать. Появилась возможность работать с частями полей типа LONG.
    Теперь можно формировать это поле по частям с помощью нескольких операторов SQL.
    Например, ограничения операционной системы на размер буфера не более 64К не будет теперь
    ограничивать размер информации в LONG поле. Возможно и чтение этого поля по частям.

    В версии 7.3 появилась еще одна модель деактуализации зависимых удаленных процедур (RPC).
    В старой модели (она тоже поддерживается) любое изменение хода хранимой процедуры
    или функции вызывало деактуализацию и дальнейшую перекомпиляцию всех зависимых от нее
    хранимых процедур. Это вело к большому числу ненужных компиляций и снижало
    производительность. Дополнительная модель позволяет деактуализировать зависимые процедуры
    только в том случае, если у изменяемой процедуры изменилось имя или число и тип параметров.



    Расширенные возможности масштабирования и высокая производительность

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


    Разработка и внедрение системы автоматизации большого авиагрузового терминала

    В. Ляшков, ФОРС












    Немного о заказчике

    AО "Шереметьево-Карго" - одно из крупнейших авиатранспортных предприятий в Российской Федерации, предоставляющее услуги по организации перевозки, обработке и экспедированию грузов по транспортным маршрутам России и за ее пределами.

    Предприятие является официальным грузовым агентом IATA, имеет лицензию Общероссийского таможенного перевозчика, является членом Ассоциации Международных автоперевозчиков (АСМАП), декларантом на договорной основе (таможенным брокером).

    АО "Шереметьево-Карго" имеет собственную сеть агентств во Франции, Германии, Италии, взаимодействует со многими аналогичными иностранными фирмами. Оно развивает и эксплуатирует крупнейший в России грузовой таможенный терминал с пропускной способностью 550 тысяч тонн груза в год, грузовой автопарк, обеспечивает продажу грузовых авиаперевозок ведущих авиакомпаний мира, организует смешанные перевозки по РФ.

    Шереметьево-Карго является крупным предприятием, на котором работает более 1500 человек, обрабатывающих до 3000 накладных и грузов по ним в сутки. Режим работы предприятия - круглосуточный.

    В настоящее время АО функционирует в условиях бурного развития транспортного бизнеса, происходящего на фоне изменения законодательства в стране и быстрого развития транспортных технологий. Являясь лидером среди организаций подобного рода, АО непрерывно развивает и совершенствует свои технологии.

    Область применения автоматизированных систем на терминале

    Первоочередной задачей системы автоматизации терминала является обслуживание основного технологического цикла обработки грузов. Цикл состоит из следующих технологических процессов: ИМПОРТ, ЭКСПОРТ и ТРАНЗИТ.

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

    ЭКСПОРТ начинается с продажи перевозки отправителю груза, бронирования перевозки, выпуска договора перевозки - авианакладной, получения оплаты, приема груза на склад при участии таможни. Далее, за некоторое время до вылета рейса начинается селекция и комплектация груза на рейс, доставку его со склада к борту самолета и его загрузка.

    ТРАНЗИТ является совокупностью первых двух процессов, зачастую с добавлением ряда промежуточных операций.

    Основные технологические процессы сопровождаются рядом поддерживающих процессов:
  • Ведением расписания и отслеживанием графика выполнения техпроцессов;
  • Отслеживанием состояния и подготовкой авиационной тары;
  • Оказанием разнообразных услуг клиентам, начислением оплаты и отслеживанием платежей;
  • Поддержкой функционирования разветвленного складского хозяйства (это называется модным термином складская логистика);
  • Выяснением неисправностей при перевозках, в том числе розыск груза и идентификация груза без маркировки.

    Все процессы обработки груза и взаимодействия со всеми заинтересованными сторонами сопровождаются интенсивным потоком документов. Основные взаимодействующие с грузовым терминалом стороны таковы:
  • Отправители и получатели груза;
  • Авиакомпании - перевозчики;
  • Таможня.

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

    Что предшествовало началу разработки

    Опыт применения информационных систем в Шереметьево-Карго довольно давний. С 1985 г в АО работает информационная система SIGMA, французского производства на ЭВМ MITRA с сетевой СУБД типа CODASYL и программным обеспечением, написанным на COBOL.

    Эта система эксплуатируется до последнего времени и обслуживает 100 одновременных on-line пользователей, 20 типов рабочих мест.

    С 1985 года прошло уже более 10 лет и к настоящему моменту система SIGMA по ряду параметров перестала удовлетворять АО.

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

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

    В-третьих, развитие транспортных технологий потребовало расширения функциональности программного обеспечения, а используемая технология не позволяет гибко и быстро модифицировать устаревшие программные единицы или добавлять новые.

    В-четвертых, система SIGMA морально устарела.
    Было принято решение о необходимости перехода на новую систему.

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

    Основные требования к процессу разработки новой информационной системы и ее свойствам формулировались следующим образом:

    Для построения информационно-функциональной модели предприятия обязательно использовать CASE-инструментарий. Эту модель предполагалось использовать далее при реорганизации предприятия и разработке требований к другим информационным системам, а также использовать ее для поддержки жизненного цикла и дальнейшего развития разрабатываемой системы.

    Применять CASE-методологию при разработке системы на всех этапах.

    Использовать мощную современную СУБД, обеспечивающую управление большими объемами данных и современный уровень защиты данных от сбоев.

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

    Число одновременно работающих пользователей в системе - 150.

    В начале 1994 года АО "Шереметьево-Карго" провело тендер, который совместно выиграли фирмы Интегпрог и ФОРС. Предполагалось, что вопросами поставки аппаратных средств и системной интеграцией занимается Интегпрог, а программное обеспечение разрабатывает ФОРС.

    В качестве аппаратного решения был предложен сервер AViiON фирмы Data General с архитектурой SMP и операционной системой DG-UX. Сетевая среда - Ethernet.

    Основными оконечными устройствами пользователя являются символьные терминалы, подключенные к терминальным серверам.

    В качестве СУБД предложен ORACLE7, как полностью отвечавший требованиям заказчика.

    Средством проектирования избран Oracle CASE 5.0 в силу его высокой интегрированности со средствами разработки, поддержкой многопользовательской работы и всего цикла разработки системы.

    Основными средствами разработки были предложены SQL*Forms 3.0 и SQL*Menu 5.0, хорошо зарекомендовавшие себя при работе в символьном режиме.

    Длительность проекта по разработке прикладного программного обеспечения была установлена в 22 месяца, из которых 6 месяцев выделялось на анализ требований и проектирование, следующие 10 месяцев - генерацию и кодирование, и еще 6 месяцев - тестирование и внедрение.

    Как проходила разработка

    Работы начались и проводились в полном соответствии с идеологией CASE*METHOD.

    Для анализа требований и проектирования в ФОРСе была образована группа под руководством опытного аналитика, ранее работавшего с Oracle CASE. После завершения анализа, на этапе проектирования, планировалось передать дела группе разработчиков.

    Заказчиком, АО "Шереметьево-Карго" и системным интегратором были организованы группы по надзору за исполнением проекта.

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

    Анализ требований проводился в тесном сотрудничестве с бизнес-аналитиками и системными программистами заказчика.


    Были сданы и подписаны результаты стадий стратегии и анализа.

    Началась стадия проектирования, которая неожиданно затянулась, поскольку результаты работ не утверждались заказчиком. Нормальные рабочие отношения между сотрудничавшими ранее группами заказчика и исполнителя стали напряженными. Отставание работ от плана становилось значительным, уже должен был давно начаться этап программирования.

    В это время, на десятом месяце проекта, как и планировалось, к работам по данному проекту была подключена наша группа разработчиков.

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

    Изучение ситуации показало, что обследование и анализ предметной области были проведены с достаточной полнотой, собрано и структурировано много материала. В репозитарии Oracle CASE существовала достаточно подробная ER-модель, пригодная для разработки базы данных. Имелось пригодное для кодирования описание автоматизируемых функций, которое однако содержалось в файлах MS Word!

    При этом между группами исполнителя и заказчика существовали расхождения по числу и объему функций, подлежащих автоматизации. Представители заказчика выражали тревогу по поводу отсутствия работающих программ.

    Часть проблем возникла из-за отличия западной и российской культур разработки информационных систем. Развивавшаяся десятки лет советская школа разработки информационных систем выработала отличные от западной подходы, терминологию, этапность, документацию. Это все регламентируется государственными стандартами.

    В CASE*Method названия этапов и их продолжительность, а также состав работ не совпадают с требованиями российских стандартов

    По российским стандартам существенно короче этап анализа требований, а проектирование и кодирование как правило резко не разделяются.

    Естественно, не получив после этапов Strategy и Analysis ни одного знакомого документа, заказчики заволновались.

    К тому же CASE 5.0 не был русифицирован.

    Можно представить себе состояние руководителя, ожидающего получить проектные документы, а ему в третий раз приносят документ, относящийся к анализу требований, имеющий непонятное название и на 90% содержащий английский текст!

    Вот откуда и появились описания функций в MS Word... Соответственно, информационная модель оказалась отрезанной от описания функций и ни о какой генерации системы речи идти не могло.

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

    Остальные проблемы возникли из-за совмещения должностей начальника проекта и главного аналитика в группе исполнителя. Такое совмещение в данном проекте не позволило уделять достаточно времени контактам с руководством заказчика и разъяснению применяемых подхода и методов.

    Положение следовало исправлять.

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

    В то же время началась активная работа в области обучения заказчика технологиям Oracle, которая продолжается по сей день.

    Поскольку огромное количество подготовленного материала не воспринималось заказчиком как нечто документальное, то сразу началась подготовка Технического Задания - привычного заказчику документа, фиксирующего границы системы.

    Одновременно началась разработка базы данных на основе существующей информационной модели. В этой связи был осуществлен переход на Designer 2000, обладающий мощными возможностями моделирования данных. Такой переход полностью себя оправдал. Богатая функциональность Data Diagrammer'а и поддержка групповой работы позволили быстро получить приемлемую схему базы данных, а его хорошие презентационные возможности - успешно представить ее заказчику.

    По прошествии четырех недель было подписано Техническое Задание и заказчик был ознакомлен со схемой базы данных. Напряжение заметно спало, стало налаживаться конструктивное сотрудничество.

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

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

    Одновременно началась подготовка Технического Проекта, составной частью которого должна была стать функциональная модель, разработанная средствами Designer 2000. Улучшенные презентационные возможности и поддержка русского языка позволили успешно сотрудничать в создании функциональной модели предприятия.

    Принятые решения привели к желаемым результатам. Программное ядро системы было досрочно установлено у заказчика и позволило начать комплексные испытания по всему технологическому циклу на ограниченных наборах входных данных, хотя объем закодированных функций составлял не более 35-40% от конечного.

    Официальные комплексные испытания ядра программного обеспечения были проведены через шесть месяцев после подписания Технического задания. После этого последние сомнения у заказчика отпали.

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


    Испытания проводились на опытном стенде заказчика силами специально подготовленных пользователей.

    Испытания были закончены в тот срок, который намечался для завершения проекта. Предстояла опытная эксплуатация.

    Как проходит внедрение

    На этом этапе предстояло решить ряд достаточно сложных задач:
  • Установить промышленный сервер и сконфигурировать его;
  • Развернуть сеть рабочих мест по всему предприятию;
  • Провести полное обучение и аттестацию всех пользователей системы;
  • Наладить функционирование новой системы в режиме параллельной работы со старой;
  • Провести приемку программного обеспечения, исходных текстов и документации.

    Для этого были разработаны два документа под названием "Программа опытной эксплуатации" и "Концепция плавного перехода", определяющие этапы развертывания новой системы и постепенного перехода со старой системы на новую.

    Программой опытной эксплуатации предусматривались три последовательных режима работы относительно старой системы:
  • Асинхронный режим, когда работа по конкретным документам в новой системе происходила независимо от старой системы;
  • Синхронный режим с неполными данными, когда данные вводятся в старую и новую систему одновременно, но в новую систему вводятся не все данные по документу;
  • Полный синхронный режим с параллельным вводом данных.

    Обмен данных между системами не предусматривался.

    Предполагалось, что при синхронных режимах объем данных, вводимых параллельно в обе системы составит 10-15% общего объема данных, вводимых в старую систему.

    Указанные выше режимы работы новой системы вводились последовательно для каждого типа рабочих мест, согласно плана-графика развертывания рабочих мест. Первыми вводились рабочие места, обслуживающие процесс ЭКСПОРТ, затем - ИМПОРТ.

    На первом этапе опытной эксплуатации рабочие места процесса ЭКСПОРТ подключались к опытному стенду и находились в асинхронном режиме работы.

    Через два месяца был установлен промышленный сервер, к нему были подключены уже развернутые рабочие места процесса ЭКСПОРТ и началось развертывание и подключение рабочих мест процесса ИМПОРТ.


    Для процесса ЭКСПОРТ был введен неполный синхронный режим, а для процесса ИМПОРТ - асинхронный.

    В настоящее время, после семи месяцев опытной эксплуатации:
  • Установлены и подключены к промышленному серверу все рабочие места системы;
  • Рабочие места процесса ЭКСПОРТ функционируют в полном синхронном режиме, причем объем вводимых в новую систему данных составляет 50% всех данных по процессу ЭКСПОРТ;
  • Рабочие места процесса ИМПОРТ находятся в неполном синхронном режиме и функционируют с запланированной нагрузкой;
  • Идет аттестация пользователей системы;
  • Идет приемка программного обеспечения и документации системы.

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

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

    В данном разделе мы ограничимся обсуждением методологии CASE*METHOD (Classic и Fast Track) и инструментария Designer/2000.

    Как известно, классические CASE-методологии разрабатывались с целью уменьшения риска в процессе выполнения проекта. Считалось, что если готовое программное обеспечение не удовлетворяет пользователя, то это результат упущений при постановке задачи. Следствием этого подхода стало увеличение времени, отведенного на стадии анализа и чистого проектирования, а программирование стало считаться чисто техническим этапом работ. На протяжении всего проекта генерируется мощный поток документов о ходе работ, в основном Progress Reports, призванных убедить заказчика, что работы идут нормально. Работы ведутся линейно, итеративность не приветствуется. Пользователь привлекается к работам в основном на этапах анализа и внедрения. Примером реализации такой методологии является ORACLE CASE*METHOD Classic.

    Однако жизнь показала, что линейная неитеративная схема с большими сроками постановки задач в некоторых ситуациях неработоспособна. Это следующие ситуации:
  • За время выполнения проекта изменяются требования заказчика к функционированию системы;
  • Невозможно получить постановку задачи от пользователя, предварительно не показав ему, как программа может работать;
  • Заказчик не может понять, почему столько времени и денег уходит на написание бумаг, которые не приносят ему непосредственной пользы (чисто русская ситуация).

    Поэтому в последнее время получили распространение методы Rapid Application Development (RAD), предполагающие:
  • Относительное уменьшение времени на чистую (бумажную) постановку;
  • Принципиальное допущение итеративности разработки, с коррекцией требований;
  • Непосредственное интенсивное взаимодействие разработчиков с пользователями на протяжении всего проекта;
  • Жесткое соблюдение временных рамок работ при регулярно проводимой приоритезации требований, позволяющей добавлять более приоритетные новые требования в обмен на менее приоритетные старые.

    Примером такой идеологии является ORACLE CASE*METHOD Fast Track.

    Если рассмотреть требования российских ГОСТов в сравнении с классическим CASE*METHOD, то получится следующее:
    CASE*METHODГОСТ
    Strategy Техническое задание
    Analysis Технический проект
    Design
    Build Рабочая документация
    Transition,Documentation
    Production Ввод в действие


    Как видно, по российским стандартам существенно короче этап анализа требований, а проектирование и кодирование как правило резко не разделяются. Этим российская традиция близка к RAD-методам.

    Однако наши ГОСТы также не приветствуют итеративность и к тому же требуют в Техническом проекте описания всех форм и отчетов системы, а также подробного описания алгоритмов, что близко к классическому CASE.

    ORACLE Designer/2000 поддерживает как Classic, так и Fast Track, однако при его применении необходимо учитывать следующее:
  • Генерируемая с его помощью документация как правило не русифицирована;


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

    Реально работающая методология является разумным компромиссом между этими подходами и при использовании Designer/2000 может выглядеть примерно так:
  • На этапе постановки задачи составляются "Описание технологического процесса", снабженное всеми видами диаграмм от Designer/2000 (используются диаграммеры верхнего уровня) и Техническое задание, задающее, в том числе, границы системы. Эта работа выполняется аналитиками. В ней обязательно участвует главный программист проекта.
  • Далее идет этап интерактивной разработки, выполняемой программистами-разработчиками. На этом этапе происходит уточнение требований и, при необходимости, их изменение. Работа ведется в непосредственном контакте с пользователями. На этом этапе используются диаграммеры нижнего уровня Designer/2000 и выбранные средства разработки. Технический проект не разрабатывается, однако принципиальные вопросы регулируются отдельными документами (например требования к интерфейсу пользователя, взаимодействие с внешними системами и т.д.). Этот этап заканчивается испытаниями системы и подготовленной к испытаниям предварительной документацией.
  • Далее идет этап опытной эксплуатации, на котором также готовится эксплуатационная документация и описание системы.
  • Крайне желательно суметь разделить систему на части, запускаемые в опытную эксплуатацию в разное время, поскольку работающая часть системы весьма стимулирует активность и решимость заказчика, направленные на введение в действие всей системы. Если не удается выделить сравнительно независимые части системы, то следует воспользоваться методом вертикального слоения, выделив некоторое ядро.

    Влияние существующей системы на разработку и внедрение новой

    Это влияние имеет как положительные, так и отрицательные стороны.

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

    Отрицательное влияние старой системы особенно ярко проявляется в следующих моментах (особенно, если система является важной частью технологического процесса):
  • При определении границ системы заказчик будет настаивать на том, чтобы новая система как минимум исполняла ВСЕ функции старой, даже если в новой системе нет в них необходимости;
  • Пользователи, привыкшие к старому (даже неудобному) интерфейсу, воспримут новый интерфейс, как правило, в штыки. Например, в начале автономного тестирования модулей ядра обнаружилось сильное неприятие пользователями интерфейса, обеспечиваемого SQL*Forms 3.0. Тому виной были большое количество используемых функциональных клавиш, сложность навигации по экрану и некоторые другие особенности.

    В связи с этим был разработан документ, регламентирующий вид пользовательского интерфейса для разрабатываемой системы. Согласование данного документа с заказчиком длилось более трех месяцев! В результате разработчикам в ряде случаев пришлось систематически применять нестандартные для SQL*Forms приемы программирования.

    Выводы можно сделать такие:
  • Еще на этапе разработки Технического задания, до его подписания, необходимо тщательно изучить старую систему на предмет ее функциональности и интерфейса;
  • В это же время необходимо начать разъяснительную работу среди руководителей и обучение персонала новым технологиям. Упущенное здесь время все равно потом добавится (причем в гораздо большем количестве) к общей длительности проекта.
  • При составлении Технического задания необходимо представить сравнение функций старой и разрабатываемой систем, с тем, чтобы не возвращаться к этому позже (скажем, на этапе приемки).

    Обеспечение безболезненного перехода со старой системы на новую

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

    Основные положения:
  • Процесс замены оборудования должен быть разнесен по времени с переходом на новую прикладную информационную систему;
  • Переход на новую систему должен быть поэтапным и однонаправленным, возврат к старой системе недопустим;
  • Автоматизированного обмена данными между системами не предусматривается;
  • В целях минимизации риска и уменьшения накладных организационных расходов необходимо обеспечить:

    - минимальное пересечение по данным в старой и новой системах;

    - минимальное число работников, переходящих на новую систему на каждом конкретном этапе;

    - минимальное число участков и подразделений, переходящих одновременно на новую систему;

    - минимальное число одновременно вводимых новых функций.

    Такой подход оказывается возможным потому, что среднее время жизни 80% актуальных данных в системе (за исключением справочников) составляет две недели, поэтому время одновременной промышленной работы двух систем сравнительно невелико. Следовательно нет необходимости в автоматизированном обмене данными между системами.

    План-график плавного перехода предусматривает сначала переход всего процесса ЭКСПОРТ на новую систему в течение недели.

    Процесс ИМПОРТ переводится на новую систему поэтапно, по подразделениям, обслуживающим рейсы на те или иные направления

    Реальный уровень затрат заказчика при разработке большой системы

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

    - Сбор и предоставление всей необходимой информации для разработки;

    - Подготовка целевого вычислительного комплекса (опытного участка) для проведения работ на своей территории;

    - Выбор технических средств промышленного вычислительного комплекса;

    - Разработка программ испытаний, проведение автономных и комплексных испытаний;

    - Разработка программы опытной эксплуатации, слежение за процессом опытной эксплуатации, отслеживание сбойных ситуаций, информирование разработчика, установка обновленных версий программного обеспечения;

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

    - Разработка основных положений концепции перехода предприятия на новую систему автоматизации, включая планы-графики развертывания технических и программных средств;

    - Осуществление собственно перехода на новую систему

    Нагрузка на руководство и персонал заказчика резко увеличивается с момента подготовки к испытаниям и начинает уменьшаться только после ввода системы в промышленную эксплуатацию, причем этот процесс захватывает большинство персонала. Поэтому, чем длительный процесс внедрения, тем больше скрытых затрат несет заказчик, следовательно необходимо добиваться минимальной длительности этапов опытной эксплуатации и перехода на новую систему. Это известный факт, но его нелишне напомнить.

    []
    []
    []

    Развитие системы

    SILVERRUN постоянно развивается. Регулярно выпускаются новые версии системы и постоянно
    обновляются мосты, что позволяет работать с самыми последними версиями поддерживаемых продуктов.
    Динамичность развития системы показывает, что SILVERRUN находится на передовом рубеже среди
    высокотехнологичных систем.

    Дистрибутором методологии DATARUN и CASE-системы SILVERRUN в СНГ является фирма
    АРГУССОФТ. Она обеспечивает техническую поддержку и обучение пользователей.


    []
    []
    []

    Реализация ссылочной целостности с помощью ERwin

    Ссылочная целостность - это обеспечение требования, чтобы значения внешнего ключа экземпляра
    дочерней сущности соответствовали значениям первичного ключа в родительской сущности.
    Ссылочная целостность может контролироваться при всех операциях, изменяющих данные
    (INSERT/UPDATE/DELETE). Средства контроля ссылочной целостности в ERwin включают
    автоматическую генерацию триггеров и использование механизмов декларативной ссылочной
    целостности (для тех СУБД, которые поддерживают данные механизмы).

    Для каждой связи на логическом уровне могут быть заданы требования по обработке операций
    INSERT/UPDATE/DELETE для родительской и дочерней сущности. ERwin представляет следующие
    варианты обработки этих событий:

  • отсутствие проверки;
  • проверка допустимости;
  • запрет операции;
  • каскадное выполнение операции (DELETE/UPDATE);
  • установка пустого (NULL-значения) или заданного значения по
    умолчанию.
    В соответствии с выбранным вариантом ERwin автоматически создает необходимые триггеры на
    диалекте SQL целевой СУБД. При этом ERwin пользуется библиотекой шаблонов триггеров, которые
    можно модифицировать.

    При генерации структуры базы данных триггеры, обеспечивающие ссылочную целостность могут
    быть переопределены на трех уровнях:


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

    Тип переопределения указывается разработчиком при генерации схемы базы данных


    Редактор Процедур (Procedure Editor)

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

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

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

    Редактор интегрирован с остальными средствами Среды Разработки Приложений PROGRESS. Не
    выходя из Редактора Процедур, Вы можете:

  • Улучшать и создавать новые компоненты приложений, генерируемые
    Построителем Интерфейса Пользователя или утилитой Results для более
    тщательной разработки интерфейсов и отчетов.
  • Вызывать Отладчик Приложений PROGRESS для эффективного решения
    проблем, возникающих в логике работы Вашего приложения.
  • Осуществлять доступ к Словарю Данных PROGRESS для создания и
    поддержки атрибутов центрально-хранимых данных, таких как представление
    данных, правила проверки правильности ввода и целостности данных.
  • Запрашивать в режиме on-line обширный справочник, который включает в
    себя полную информацию о системе и набор примеров для изучения языка
    4GL.
  • Вызывать встроенный Компилятор Приложений PROGRESS для быстрой
    компиляции всего приложения или отдельных его частей.
    Подобная высокая степень интеграции Редактора Процедур с остальными средствами среды
    разработки PROGRESS, гарантирует Вам получение высокой производительности при работе с
    любыми компонентами приложений.


    Редакторы свойств и редакторы компонент - поведение IDE

    Логично, что при визуальном подходе к определению характеристик компонент (работа в design-
    time), необходимы средства определения редакторов специфических свойств в Инспекторе
    Объектов (Object Inspector).

    Редакторы свойств и редакторы компонент - поведение IDE

    Рекомендуемая литература


  • Тандоев А.Ю. Архитектура продуктов клиент-сервер фирмы Sybase. СУБД № 1, 1995, с. 62-69.
  • Горин С.В., Тандоев А.Ю. Среда разработки приложений PowerBuilder. DBMS/Russian Edition,
    № 1, 1995, с.38-41.
  • Горин С.В., Тандоев А.Ю. Линия продуктов Sybase для создания сложных информационных
    систем. Компьютерра, № 37-38 (117-118), с.44-48; № 39 (119), с.26-30.
  • Монахова Е.Н. System 11 в проекции на Лондон и Москву. PC Week/Russian Edition, № 19,
    1995, с.1.

    []
    []
    []

    Реляционные расширители

    Хорошим примером применения перечисленных новых возможностей являются реляционные
    расширители DB2 (DB2 Relational Extenders). Они предоставляют широкие возможности для
    работы с нетрадиционными данными, используя возможность определения пользовательских
    типов данных и функций. Для хранения мультимедиа данных расширители используют
    поддерживаемые DB2 большие объекты, а для поддержания целостности по ссылкам -
    триггеры.

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


    Репликационный сервер Sybase Replication Server

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

    Репликационный сервер представляет собой отдельную задачу, запускаемую одновременно с
    СУБД. Он имеет свой входной язык и стандартный для продуктов Sybase сетевой интерфейс
    Open Server. Такое разделение снижает нагрузку на СУБД и делает систему в целом более
    открытой.

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

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

    Возможность тиражирования группы записей таблицы означает, в частности, что часть записей
    таблицы может быть первичными данными в одном узле, а часть - в других.


    Схема репликации данных
    Репликационный сервер Sybase Replication Server


    Репозитарий - централизованная база данных проекта

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

    Средства доступа к репозитарию обеспечивают удобный многооконный объектно-
    ориентированный интерфейс ко всем элементам репозитария в рамках выбранного приложения.
    Все данные приложения представляются в виде иерархии типов, двигаясь по которой можно
    работать с различными объектами, определяя и уточняя их характеристики с помощью
    универсального окна свойств (рис.5).

    Репозитарий - централизованная база данных проекта

    Репозиторий дизайна приложений (Application Design Repository)

    PowerBuilder тесно интегрирован с базой данных, в которой хранится репозиторий дизайна
    приложений. Разработчики могут использовать интерфейс в режиме "укажи и щелкни кнопкой мыши"
    для определения центрального репозитория, содержащего широкий спектр атрибутов отображения
    данных, таких как шрифты, заголовки, метки, форматы изображения, правила проверки и
    графические стили редактирования, включая радиокнопки, альтернативы, открывающиеся списки,
    открывающиеся Окна данных (DataWindows), одно- и многострочные стили редактирования,
    а также шаблоны редактирования ввода данных.

    Репозиторий дизайна приложений PowerBuilder повышает производительность разработчика,
    облегчает создание стандартов приложений и заставляет следовать этим стандартам во всей
    организации. Как только репозиторий определен, значительно ускоряется создание сложных Окон
    данных (DataWindows) и отчетов.

    Централизованное определение репозитория дизайна приложений ускоряет и упрощает поддержку и
    обновление существующих приложений. Разработчики могут определить в репозитории стандарт
    создания целостного интерфейса пользователя. Для полноты контроля и гибкости представления
    данных в Художнике Окна данных и Художнике отчетов разработчику
    предоставлена возможность переопределять для отдельных объектов расширенные атрибуты,
    установленные в репозитории.


    Одна из черт нашего времени

    Одна из черт нашего времени - качественный скачок в автоматизации финансово-хозяйственной
    и производственной деятельности предприятий. Программы нового поколения - корпоративные
    системы, выполненные в технологии клиент/сервер, - предоставляют такие возможности для
    учета и управления, о которых руководители еще недавно могли только мечтать. Ряд ведущих
    фирм разрабатывает и предлагает такие проекты для предприятий различных отраслей и видов
    деятельности. Сообщения об этом регулярно появляются в компьютерной прессе и компьютерных
    рубриках экономических изданий, корпоративные системы демонстрируются на тематических
    выставках, семинарах, конференциях.

    Результат работы генератора - новый класс объектов

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

    Генератор окон сохраняет описание сгенерированного оконного класса в виде нескольких файлов
    (рис. 1):

    < имя >.wif - файл с описанием структуры окна в формате WIF (Window Intermediate
    Format). Этот файл может быть прочитан генератором окон для последующего
    редактирования.

    < имя >.4gh - заголовочный файл, содержит декларацию нового оконного класса.

    < имя >.4gl - программный файл, содержит функции обработки событий в окне и его
    органах, заданные программистом. В этом файле содержатся также определения дополнительных
    или переопределенных функций оконного класса. Файлы 4gh и 4gl обрабатываются компилятором
    и генератором приложений.

    Если при формировании окна был задан атрибут "главное окно", то в 4gl-файл будет добавлена
    головная функция MAIN. Она будет содержать оператор подключения к БД и вызов главного
    окна. Таким образом, простое приложение, не требующее сложной обработки данных, может быть
    целиком создано средствами визуального программирования.

    < имярис.rs > - для каждого импортированного графического файла, использованного как
    элемент оформления окна, создается файл ресурсов.

    Результат работы генератора - новый класс объектов

    Цикл разработки в S-Designor


    Особенность реализации цикла разработки в S-Designor заключается в том, что он позволяет
    выполнять "сквозное проектирование". Это значит, что разработав концептуальная модель можно
    автоматически сгенерировать физическую и после этого выполнить генерацию структуры БД. При
    обратном проектировании последовательность действий прямо противоположная. Можно получить
    физическую модель на основе структуры БД и после этого автоматически сгенерировать
    концептуальную модель. Разумеется на каждом этапе можно вносить изменения в модели
    концептуального и физического уровней.

    Часто возникает вопрос: "Если генерация физической модели из концептуальной и концептуальной
    модели из физической выполняется автоматически, надо ли каждый раз корректировать модель
    соответствующего уровня"? Ответ - нет. S-Designor четко отслеживает соответствие между
    концептуальным и физическим уровнем и "помнит" не только изменения в структуре объектов модели
    (уточнения связей, выполненные при переходе на физический уровень), но и их расположение на ER-
    диаграмме. При генерации этим "учетом изменений" можно управлять. Таким образом,
    автоматическая генерация - процесс, выполняемый в S-Designor очень эффективно и
    качественно.


    Экран определения нотации модуля BPM


    К специфическим особенностям системы относится возможность использования символьных
    иерархических идентификаторов процессов вместо числовых, а также удобные функции автоматической
    перенумерации объектов диаграмм в порядке расположения на схеме или в указанной пользователем
    последовательности. Система может строить дерево процессов и дает возможность переопределять их
    иерархическую вложенность перемещением процессов из одних узлов дерева в другие.

    Для анализа и реинжениринга бизнес-процессов (BPR) имеется возможность определить используемые
    ресурсы и задать их удельную стоимость. При построении моделей можно указывать, какие ресурсы в
    каком объеме используются процессами. Система автоматически подсчитывает стоимость каждого
    процесса с учетом стоимости его подпроцессов, а также общую стоимость каждого ресурса по всей
    модели.


    Обозначения мощности связи в нотации IE


    Имя связи на логическом уровне представляет собой "глагол", связывающий сущности. Физическое
    имя связи (которое может отличаться от логического) для ERwin означает имя ограничения (constraint)
    или индекса.


    Сокращение времени обработки за счет применения вертикального и горизонтального параллелизма.


    Методы фрагментации выполнения применяется в обеих моделях серверов, с той разницей, что
    Informix-ODS для выполнения подзапросов и подзадач создает потоки, выполняемые параллельно
    на нескольких процессорах, а в Informix-OXPS выполнение подзапросов и подзадач распределяется
    между ко-серверами. Фрагментация выполнения дает многократный выигрыш в
    производительности на следующих типах задач:


  • обработка характерных для приложений DSS сложных запросов, которые
    включают сканирование, сортировку, соединения огромных объемов данных,
    распределенных по множеству дисков и/или ко-серверов, группирование,
    вычисление агрегатных функций;
  • массовые вставки;
  • построение индексов;
  • резервирование журналов транзакций, сохранение и восстановление
    данных;
  • загрузка, выгрузка данных, реорганизация баз данных;

    Informix - единственная на сегодня СУБД, которая обладает средствами распараллеливания для
    столь обширного набора операций.

    3.3.1. Вертикальный параллелизм. Итераторы
    Элементарные операции, из которых состоит реализация любого запроса, называются
    итераторами. Итератор - это программный объект, который воспринимает потоки строк от одного
    или двух источников, выполняет над ними некоторый вид обработки и выдает результирующий
    поток строк. Источниками данных могут служить дисковые файлы, сетевые соединения,
    результирующие потоки других итераторов. Основное свойство итераторов - единообразие их
    внешнего интерфейса, благодаря которому они могут произвольным образом объединяться.

    Рассмотрим пример выполнения запроса:

    SELECT state, SUM(order_item)

    FROM customer, order

    WHERE order.customer_id = customer.id

    GROUP BY state

    ORDER BY SUM(order_item)

    Дерево его реализации (рис. 2) включает следующие типы итераторов:

    SCAN - Сканирует таблицы и индексы.

    HASH JOIN - Реализует алгоритм соединения методом хеширования.

    GROUP - Группирует данные (GROUP BY) и вычисляет агрегатные функции.

    SORT - Сортирует данные.

    Дерево итераторов на рис. 2 реализует одновременное выполнение на разных процессорах или ко-

    серверах множества циклов обработки данных за счет конвейеризации промежуточных
    результатов. Так, результаты сканирования таблиц могут передаваться другому ко-серверу (в
    OXPS) или другому потоку (в ODS), который сможет начать соединение по мере поступления
    строк исходных таблиц. Результат соединения передается еще одному ко-серверу или потоку,
    который начнет выполнять суммирование, и т. д.

    3.3.2. Горизонтальный параллелизм. Рефрагментация промежуточных
    результатов
    Для того чтобы ускорить выполнение запроса, для каждой элементарной операции создается
    несколько итераторов, которые распределяются между ко-серверами (OXPS) или выполняются как
    отдельные потоки (ODS). Координацией совместной деятельности множества однотипных
    итераторов занимается итератор типа EXCHANGE. EXCAHGE рефрагментирует результаты,
    полученные от нижележащих итераторов и передает их итераторам верхнего уровня (рис. 3).

    3.3.3. Баланс между приложениями OLTP и DSS
    Задачи, выполняемые на сервере СУБД, можно разделить на три категории: OLTP, DSS и пакетной
    обработки.

    Пример OLTP-запроса: Есть ли свободный номер в какой-либо берлинской гостинице на 8-е
    декабря?

    Пример DSS-запроса: Каковы будут затраты на реализацию стратегии X охраны здоровья
    сотрудников по сравнению со стратегией Y с учетом демографического профиля компании?

    Сокращение времени обработки за счет применения вертикального и горизонтального параллелизма.

    Традиционная модель данных ADABAS


  • Традиционная реляционная модель данных


    Эта модель соответствует ANSI/ISO стандарту SQL и реализована в виде либо надстройки над
    ADABAS-C, либо как неотъемлемая часть ADABAS D.


  • Модель данных сущность-связь (E/R модель)


    В ADABAS предусмотрено расширение до модели Entity-Relationship (или E/R модели) для
    управления сложными структурами данных с высокой степенью связности. Оно поддерживает
    также рекурсивные структуры данных.

    Объединяя эту модель с другими моделями ADABAS можно строить мощные
    интегрированные базы данных и, соответственно, прикладные системы. Предпочтительные
    области для применения этих моделей - системы представления знаний, моделирование поведения
    сложных технических и биологических систем, расчеты потребностей, планирование материальных
    ресурсов различного вида и назначения (Bills of Materials).


  • Обработка и управление произвольными текстами


    Этот тип данных (и соответствующие средства манипулирования ими) обеспечивает доступ к
    документам, обрабатываемым ADABAS, как к произвольным текстам. Возможно сочетать разного
    рода обработку текстовых данных со стандартными процедурами ADABAS для работы с
    форматированными данными. Например, библиотеки, юридические конторы, службы новостей,
    телекомпании, газеты и журналы, правительственные организации - все, кто имеет и будет иметь
    данные в виде т.н. "свободных" или неструктурированных текстов.


  • Обработка и управление географическими данными


    В отличие от традиционных географических (картографических) систем, которые используют
    структуры хранения данных (реляционные и др.) независимо от собственно географической
    информации, обеспечивая их совместное использование, как правило, только на уровне SQL-
    интерфейса, подход SOFTWARE AG характеризуется глубокой интеграцией на всех уровнях
    хранения и обработки.

    Картографическая информация, координатные привязки объектов, форматированные данные и
    текстовая информация неограниченного объема хранятся в рамках единой БД. Точно также в
    рамках одной программы и даже одного оператора (среда NATURAL) интегрирована и обработка
    этой комплексной информации. Важно, что при этом обеспечивается не только высокая
    производительность геоинформсистем, но за счет поддержания логики транзакций гарантируется
    целостность и безопасность хранения базы данных и другие ее неотъемлемые характеристики.


    Взаимодействие компонент ядра JAM


    Редактор Экранов

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

    В распоряжении разработчика имеются следующие интерфейсные элементы:

  • Статические метки (static label)- произвольный фиксированный текст
    или фиксированный графический образ;
  • Динамические метки (dynamic label)- произвольный текст или графический
    образ; может быть изменен в процессе исполнения приложения. Источником
    информации может быть БД;
  • Однострочные текстовые поля ввода/вывода (single line text);
  • Многострочные текстовые поля ввода/вывода (multi-line text);
  • Экранные кнопки (pushbutton);
  • Переключаемые экранные кнопки (toggle button)- фиксируется состояние
    нажата/отпущена;
  • Элементы единственного выбора (radio button);
  • Элементы множественного выбора (check box);
  • Прокручиваемые списки (list box);
  • Опциональные меню (option menu) - осуществляет выбор одного значения
    из раскрывающегося меню;
  • Комбинированные меню (combo box) - комбинация опционального меню и
    однострочного текстового поля;
  • Шкалы (scale) - элемент ввода/вывода числовых данных;
  • Табличные фреймы (grid) - объединяет элементы типов "однострочный
    текст" и "динамическая метка" в табличное представление;
  • Графические диаграммы (graph);
  • Линии (line);
  • Рамки (box).
    Данный набор элементов вполне соответствует стандарту CUA и является функционально полным
    для разработки приложений информационных систем.

    Некоторые однотипные объекты можно объединять в группы следующих видов:

  • Синхронизированные группы - обеспечивается синхронизированная
    прокрутка содержимого нескольких объектов
  • Группы выбора - обеспечивается пометка нескольких строк содержимого
    объекта;
  • Разнотипные объекты можно объединять в специальные группы "Образ
    таблицы БД" (table view).
    В графическом Редакторе JAM реализован режим перемещения элементов с помощью мыши (drag
    and drop) и возможность работы в одном сеансе с несколькими проектируемыми экранами. С
    помощью нескольких служебных окон Редактора возможно уточнение характеристик элементов
    (размеры, цвет, позиция и др.).

    JAM является событийно-ориентированной системой, т.е. для каждого типа интерфейсных
    элементов приложения определен набор событий (открытие и закрытие для экранов, работа с
    фокусом для управляющих элементов и элементов ввода/вывода, событие "проверка" (validation),
    нажатие клавиш клавиатуры и т.д.). Определение обработчиков этих событий осуществляется в
    Редакторе и задает логику работы приложения. Обработчиками событий могут быть:

  • Функции ядра JAM - более 300 функций самого различного назначения,
    включая функции динамического (т.е. в процессе исполнения приложения)
    изменения свойств объектов;
  • Функции, написанные на JPL (внутренний процедурный интерпретируемый
    язык JAM); Из JPL-функций доступны функции ядра;
  • Функции, написанные на любом внешнем языке программирования 3-го
    поколения (C, Pascal, Fortran и т.п.), совместимом по вызовам с C; Из этих
    функций доступны функции ядра JAM и JPL-функции.
    Редактор экранов JAM может работать в одном из трех режимов:

  • Режим редактирования (Edit Mode) - разработка экранов;
  • Режим тестирования (Test Mode) - тестирование разрабатываемых
    экранов;
  • Режим приложения (Application Mode) - интерпретация всего приложения в
    целом.
    На рис. 2 представлена диаграмма переходов между режимами Редактора Экранов.


    Режим приложения Взаимодействие компонент ядра JAM
    Режим редактированияВзаимодействие компонент ядра JAM

    специально разработана для удовлетворения

    Microsoft SQL Server 6.0 - специально разработана для удовлетворения требований, предъявляемых
    системами распределенной обработки данных (таких как тиражирование данных, параллельная
    обработка, поддержка больших баз данных (БД) на относительно недорогих аппаратных
    платформах, сохраняющая простоту управления и использования). Сервер имеет средства
    удаленного администрирования и управления операциями, организованные на базе объектно-
    ориентированной распределенной среды управления. Новые возможности, такие как OLE
    Automation и средства программирования административных задач на языке Visual Basic for
    Applications, обеспечивают интеграцию с приложениями, работающими на ПК. По-прежнему
    Microsoft уделяет очень большое внимание соответствию своих продуктов существующим
    промышленным стандартам, что отразилось в расширенной поддержке ANSI SQL и ODBC.

    Microsoft SQL Server 6.0 входит в состав семейства Microsoft BackOffice, объединяющего пять
    серверных приложений, разработанных для совместного функционирования в качестве
    интегрированной системы. Она позволяет пользователям повысить производительность процесса
    принятия решений средствами систем, базирующихся на архитектуре клиент-сервер. Кроме того,
    Microsoft SQL Server 6.0 завершает линию средств разработки, включающих Microsoft Access,
    Visual FoxPro®, Visual Basic и Visual C++™.


    Для каждой из этих областей имеются СУБД, промежуточное ПО для работы в разнородной среде
    и инструменты для разработки приложений. Главные требования к этому ПО показаны на
    рис.2.

    Sybase System 11, наряду со средствами разработки и другим программным обеспечением Sybase,
    образует функционально-полный и вместе с тем открытый набор программных средств для каждой
    области работы (рис.3).


    Современные требования к продуктам клиент/сервер
    OLTP различные виды операцийDSS
    хранилища данных    		Массовое использование
    Базы данныхУправление данными и
    транзакциями
    Промежуточное ПОУдобство работы в
    разнородной среде
    Преобразование и перемещение данных
    ИнструментыБыстрая разработка
    приложений
    Поддержка многих методик и баз данных


    Особенно остро встает для разработчиков компонент вопрос создания и использования
    редакторов свойств, когда свойства имеют сложный тип. Например, свойство может предоставлять
    ссылку на достаточно сложную структуру - запись или на строго определенных наследников
    одного из стандартных или пользовательских классов (возможные ситуации: 1) класс "множество
    данных" TDataSet - является предком и таблиц, и запросов, и хранимых процедур; можно
    сформулировать такую задачу, когда в качестве значения свойства в design-time должны выступать
    только запросы и таблицы, но, ни в коем случае - хранимые процедуры; 2) шрифт описывается
    рядом характеристик, представляемых вложенными записями).

    Delphi предоставляет разработчику ряд базовых классов, входящих в иерархию VCL, которые
    предназначены для создания редакторов свойств.

    специально разработана для удовлетворения


    Designer/2000 Анализ деятельностиМоделированиеГенерация приложенийРепозитарийОтчетыГрафикаЭкранные формыDeveloper/2000

    Кроме самой диаграммы для

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

    Функциональные аспекты предметной области описываются с помощью диаграмм иерархии
    функций и потоков данных. Эти диаграммы отражают деятельность существующих
    организационных структур, технологические особенности процессов переработки информации и
    строятся по методологии проектирования "сверху вниз". Начиная с самой общей функции,
    описывающей деятельность всей организации в целом, аналитик последовательно разбивает это
    описание на более детальные функции, в совокупности составляющие исходную; в дальнейшем
    этот процесс продолжается применительно к новым, полученным на предыдущем уровне
    функциям. Такая декомпозиция функций завершается, когда функции, полученные на самом
    нижнем уровне иерархии, не поддаются дальнейшему разложению, т.е. являются элементарными.
    Для них специфицируется, с какими объектами они работают, какие типы действий при этом
    производятся (создание, удаление, модификация) как на уровне объектов, так и на уровне
    отдельных их параметров. Кроме этого, могут быть описаны события, вызывающие выполнение
    той или иной функции.

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

    Входящие в состав DESIGNER/2000 средства концептуального моделирования представляют
    собой совокупность графических редакторов, обеспечивающих поддержку информационных и
    функциональных моделей концептуального уровня. В состав этих средств входят (рис. 4):


  • графический редактор ER-диаграмм
  • графический редактор иерархии функций
  • графический редактор диаграмм потоков данных

    Каждый из этих редакторов (диаграммеров) обеспечивает удобные средства работы с
    диаграммами определенного типа, отвечающие всем требованиям современного графического
    интерфейса (рис. 11 - 13).

    Кроме самой диаграммы для

    Схема тиражирования


  • Выборочная подписка. Сервер подписки может не подписываться
    вообще, подписаться на некоторые или на все публикации, предлагаемые
    сервером публикаций вашего предприятия.
  • Выборочная подписка на статьи публикаций. Сервер подписки
    может подписаться на все или некоторые статьи внутри публикации.
  • Защита публикаций. Каждая публикация имеет статус защищенной
    или незащищенной (по умолчанию принимается отсутствие защиты). Если
    публикация помечена как незащищенная, то она видна любому и на нее может
    подписаться любой зарегистрированный сервер. В том случае если публикация
    помечена как защищенная, она видна только тем серверам подписки, которым
    дано такое право, и только они могут на нее подписаться.
  • Публикация вертикальных элементов таблицы. При
    необходимости статья публикации может быть определена как набор столбцов
    той или иной таблицы. При этом необходимо учесть, что среди этих столбцов
    обязательно должны присутствовать те, что определяют первичный индекс.
  • Публикация горизонтальных элементов таблицы. Статья также
    может включать только некоторые записи таблицы. В этом случае сервер
    подписки получает только набор записей. (Кроме того, статья может включать
    "прямоугольную вырезку", ограниченную набором столбцов и набором
    записей.)
  • SQL Server 6.0 предоставляет исключительную гибкость в организации
    топологии системы тиражирования данных. Базовые структуры тиражирования
    включают следующие схемы:
  • один сервер публикаций, несколько серверов подписки (самая
    простая схема). Один сервер определен как сервер публикаций. Эта схема
    принимается по умолчанию и лучше всего подходит для создания
    информационных систем, централизованного распространения информации,
    снижения нагрузки основного сервера при создании различного рода отчетов и
    т.п.;
  • один сервер публикаций с использованием промежуточного
    сервера репликаций. Эта схема похожа на предыдущую, только с той
    разницей, что заботу по рассылке информации всем подписчикам берет на
    себя дополнительный сервер.
    Это снижает нагрузку на основной сервер в том
    случае, когда происходит интенсивная работа с большой базой данных.
    Основной сервер (сервер публикаций) выполняет только обработку транзакций;
  • множество серверов публикаций, один сервер подписки. При
    использовании такой схемы несколько серверов публикаций тиражируют
    данные на единственный сервер подписки. Этот сценарий позволяет
    консолидировать данные в едином центре. Подобная модель может
    использоваться для локальной обработки данных у клиентов в удаленных
    подразделениях;
  • несколько серверов подписки, несколько серверов публикаций.
    При использовании такой схемы несколько серверов могут играть двойную
    роль (выступать одновременно и как серверы подписки, и как серверы
    публикаций). Эта схема подходит для использования в децентрализованных
    организациях, системах резервирования, региональных отделениях. Подобная
    конфигурация должна быть создана вручную.

    Определение домена


    Назначение доменов для сервера аналогично назначению доменов для клиента. Различие заключается
    в том, что правила и начальные значения для сервера определяются в генерации схемы базы данных, а
    аналогичные атрибуты для клиента - сохраняются в репозитарии средства 4GL.

    Другое назначение доменов для сервера - определение пользовательских типов данных.
    Пользовательскому типу данных ставится в соответствие тип, "известный" СУБД. При выполнении
    синхронизации с базой данных для СУБД, поддерживающих пользовательские типы, выполняется
    соответствующие команды. Например, для Sybase выполняется команда:

    sp_addtype person_name, "char(64)", "NOT NULL"

    SQL Anywhere имеет продуманную

    SQL Anywhere имеет продуманную языковую поддержку. При создании каждой базы данных
    указывается, в частности, порядок сортировки символов. Эта информация используется при
    выполнении сортировки ORDER BY, сравнения символов без учета регистра, использовании
    символов для написания идентификаторов объектов базы данных, обработке фразы LIKE и
    различных строковых функций.

    Кроме встроенных языков и кодовых страниц (включая русский), SQL Anywhere позволяет
    создавать определенные пользователем новые конфигурации. Для этого описание вводится в
    текстовом виде и затем преобразуется специальной утилитой.

    Очень важны весьма невысокие требования продукта к ресурсам. Он может запускаться при 1Мб
    свободной оперативной памяти и работать в минимальной по памяти конфигурации
    Windows.

    С другой стороны, с выходом SQL Anywhere группы разработчиков могут использовать этот
    продукт с уверенностью в том, что при необходимости возможен переход на более мощные
    аппаратные и программные платформы (RISC-станции и Sybase SQL Server).

    Действительно, включение SQL Anywhere в состав линии продуктов Sybase придало новые
    качества продукту и сделало его выбор для рабочих групп еще более привлекательным не только
    по цене, но и по наиболее важным характеристикам:


  • собственная репликация данных - SQL Remote;
  • поддержка системы репликации Sybase Replication Server;
  • графический инструмент администрирования SQL Central;
  • поддержка Transact-SQL;
  • поддержка ODBC 2.1;
  • повышение производительности и мониторинг производительности;
  • расширения языка Watcom SQL;
  • универсальный серверный интерфейс SQL Anywhere Open Server.

    SQL Anywhere поддерживает два различных механизма репликации.

    База данных SQL Anywhere может участвовать в схеме репликации Sybase Replication Server. Это
    мощная, сложная и высокопроизводительная компонента, тиражирующая данные между
    разнородными СУБД, описана выше (рис.8). Для интеграции с Replication Server используется
    специальный шлюзовой компонент - Open Server Gateway для SQL Anywhere, который
    "транслирует" стандартный для продуктов Sybase интерфейс Open Client/Server в интерфейс SQL
    Anywhere.

    Для отслеживания изменений в базе данных SQL Anywhere предусмотрена компонента Replication
    Agent.

    Другой механизм репликации (SQL Remote) - это система репликации только между базами
    данных SQL Anywhere. Это менее гибкая система, чем Replication Server; например, в ней жестко
    требуется, чтобы имена объектов тиражирования были одинаковыми во всех базах данных. Зато
    SQL Remote легко администрируется, пригоден для широкого использования в том числе и в
    случаях, когда базы данных не имеют прямого соединения друг с другом.

    Варианты выдачи отчета


    Сгенерированный отчет может быть сохранен на диск (колонки разделяются запятыми,
    выравниваются или разделяются табуляцией), или передан в текстовый процессор (или электронную
    таблицу) через интерфейс DDE.

    Для подготовки развитых отчетов может быть использован специальный генератор отчетов фирмы
    Logic Works - RPTwin, который интегрирован с ERwin. Пример конструирования отчета в RPTwin
    приведен на рис.13.

    Варианты выдачи отчета

    Службы сообщений используют адрес

    Службы сообщений используют адрес получателя для сохранения и передачи сообщений к пункту
    назначения. Например, система электронной почты может сохранять сообщение на сервере до тех
    пор, пока соответствующий пользователь не подключится к системе.

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

    Публикация - это объект, описывающий тиражируемые данные. Удаленные пользователи
    оформляют подписки на публикации для получения этих данных.

    Публикация может включать данные из нескольких таблиц. Каждая таблица может быть
    представлена либо целиком, либо подмножеством столбцов, либо даже подмножеством строк по
    условию выборки.

    Система репликации администрируется централизованно в консолидированной БД средствами
    графического инструмента SQL Central.

    Публикация может быть использована несколькими подписчиками.

    В SQL Remote реализована поддержка систем передачи сообщений MAPI, VIM, SMTP и
    файлового обмена.

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


  • Два пользователя добавляют в таблицу строку с одинаковым первичным
    ключом (ПК). В этом случае второй INSERT закончится неудачно. Этой
    ситуации можно избежать при правильном проектировании БД. Например,
    включить колонку - идентификатор БД, где происходит обновление, в
    первичный ключ такой таблицы.
  • Два пользователя обновляют одну и ту же колонку в таблице (не ПК). Если
    в системе требуется обеспечить пользователям такую потенциально опасную
    возможность, то SQL Anywhere предоставляет средство обнаружить и
    разрешить конфликт с помощью специального типа триггера (RESOLVE
    UPDATE).

    Кроме собственно изображения диаграммы

    Кроме собственно изображения диаграммы каждый из редакторов позволяет вводить
    дополнительную уточняющую информацию об отдельных элементах диаграммы. Например, для
    любой сущности, представленной на ER-диаграмме прямоугольником с названием, можно вызвать
    специальное окно для задания всевозможных характеристик этой сущности, включая атрибуты,
    первичные ключи, уникальные идентификаторы, ограничения или правила проверки для значений
    атрибутов, частотные характеристики и т.д. Аналогично, для любой взаимосвязи можно
    специфицировать, является ли она идентифицирующей (входит в состав какого-либо уникального
    идентификатора), переносимой ( можно динамически переопределять для любого экземпляра
    сущности типа "деталь", какому экземпляру "мастера" он подчиняется) и т.д.

    Существенно, что в отличие от предыдущих версий ER-редакторов, здесь можно изображать
    непосредственно на диаграмме многие из таких дополнительных характеристик. Так, часто удобно
    бывает видеть на ER-диаграмме не только название сущности, но и определяющие ее атрибуты с
    указанием, какие из них являются ключевыми, какие - обязательными и т.д. (рис.11).

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

    Для одного и того же приложения предусматривается возможность построения нескольких ER-
    диаграмм и нескольких иерархий функций: это может быть полезно для сложных задач с
    огромным количеством объектов и связей. В этом случае естественно декомпозировать общую
    задачу и для каждой части рисовать свою ER-диаграмму.

    Кроме средств ввода данных и построения графических изображений каждый редактор
    предоставляет возможность выполнять различные семантические проверки построенных диаграмм
    на полноту и корректность, а также генерировать разнообразные отчеты для документирования
    концептуального уровня разработки. Развитые средства вывода позволяют получить на бумаге
    любую диаграмму с помощью плотера или любого PostScript-принтера.

    схемы БД похожа на

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

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

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

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

    На рис. 15 приводится пример использования диаграммы структуры
    модуля.

    схемы БД похожа на

    На диаграмме определяется модуль типа экранной формы, в которой в одном окне
    должны высвечиваться данные из таблицы "ОТДЕЛЫ" и данные из таблицы "СОТРУДНИКИ",
    синхронизированные друг с другом (при переходе на новую строку в первом блоке соответственно
    меняются данные во втором блоке и т.п.). Кроме того, для таблицы "СОТРУДНИКИ" определена
    дополнительная просмотровая таблица для выбора и задания для каждого сотрудника его
    начальника. Результирующая сгенерированная экранная форма приведена на
    рис. 16.

    <title>(.*)</title>

    Кроме трех графических редакторов системного проектирования, в Designer/2000 включено
    специальное средство для определения программных модулей типа процедуры, написанной на
    языке PL/SQL (универсальный процедурный язык программирования, включающий в себя
    операторы языка SQL). Это средство, так называемый навигатор процедурной логики,
    представляет собой синтаксически-ориентированный редактор, позволяющий создавать
    программные тексты на языке PL/SQL по технологии "найди-и-выбери". Это означает, что вместо
    непосредственного набора текста операторов создание программы сводится к выбору нужной
    конструкции или объекта из "каталога". Особенность этого средства - его объектно-
    ориентированный интерфейс, существенно упрощающий процесс работы: "каталог" возможных
    конструкций языка PL/SQL и объектов базы данных представлен в виде иерархии типов с набором
    удобных средств просмотра и поиска необходимых элементов.

    Административная консоль SQL Server


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

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

    Microsoft SQL Server 6.0 предлагает "активную" модель администрирования системы. В отличие от
    предыдущей версии продукта, администратор получил в свое распоряжение средства,
    позволяющие предупреждать неблагоприятное развитие событий вместо того, чтобы, сломя
    голову, кидаться исправлять последствия сбоя системы, когда пользователи уже не имеют доступа
    к хранящейся в ней информации. SQL Server 6.0 позволяет определять так называемые
    предупреждения (alert), которые являются реакцией системы на возникновение того или иного
    события.

    Как видно из рис.3 , предупреждение срабатывает при возникновении
    ошибки с кодом 018 в базе данных master.

    Административная консоль SQL Server

    Дерево реализации запроса


    Примеры заданий пакетной обработки - массовая загрузка данных, выдача сложных отчетов,
    действия по реорганизации базы данных.

    Архитектурные и технологические решения, о которых говорилось выше, направлены на то, чтобы
    обеспечить эффективную обработку всех типов заданий. Однако не менее важная проблема -
    обеспечить рациональное одновременное выполнение смеси таких задач на сервере. Если
    применение методов фрагментации выполнения ничем не ограничено, то сильно распараллеленное
    выполнение нескольких сложных запросов приведет к недопустимому замедлению OLTP-
    приложений, выполняющихся на том же сервере.

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


    Диаграмма уровня сущности


    Теперь перейдем в режим задания атрибутов (Display/Atribute Level). В редакторе "Entity/Attribute"
    зададим на русском языке имена ключевых и неключевых атрибутов. Заметим, что для дочерней
    сущности "дети" ключевой атрибут "номер служащего" не указывается вручную. ERwin обеспечивает
    его миграцию из родительской сущности. То же происходит с другими дочерними сущностями.

    Для атрибута "имя" сущности "служащий" укажем, что он является альтернативным ключом (будем
    считать, что у всех служащих уникальные имена/фамилии). Для этого после имени атрибута поместим
    указатель AK1 в скобках.

    Результат работы отображен на диаграмме ERwin (рис. 3) в нотации IDEF1X.

    Диаграмма уровня сущности

    Классификация архитектур клиент/сервер


    SOFTWARE AG использует этот подход для поддержки прикладных проектов, предлагая
    широкий набор собственных программных продуктов.

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


    Переходы между режимами Редактора Экранов


    Каждый экран, входящий в приложение, сохраняется в виде отдельного файла. Кроме этого,
    экраны могут сохраняться в виде библиотек экранов. Библиотека экранов представляет собой
    файл, содержащий хранящиеся экраны и индексную таблицу, ускоряющую поиск необходимых
    экранов. Одновременно в системе может быть открыто несколько экранных библиотек.

    Приложение NewEra может


    Генерация отчетов. NewEra предоставляет средства для описании структуры текстовых отчетов и
    их генерации. Более современные, графические, средства создания отчетов имеются в системе
    Informix-ViewPoint Pro, которая входит в комплект поставки NewEra (см. ниже).


    Sybase System 11 выпущена

    Sybase System 11 выпущена сейчас для основных UNIX-платформ. Версии Sybase SQL Server для
    Intel-платформ ожидаются в первой половине 1996 года.


    Sybase: Единая архитектура, оптимизированные продукты
    OLTP различные виды операцийDSS
    хранилища данных    		Массовое использование
    Базы данныхSQL Server - серверные
    продукты
    Высокая производительность и масштабируемость для бизнес-
    приложений
    Промежуточное ПОEnterprise CONNECT -
    разнородные системы
    Интероперабельность и репликация
    ИнструментыСемейство продуктов PowerBuilder
    Стандарт де-факто при разработке приложений, работающих с различными базами
    данных


    Первая версия CASE-инструментария фирмы ORACLE, ORACLE*CASE 5.0 появилась в 1989 году
    для сервера ORACLE/6 с ориентацией на символьный режим для конечного пользователя.
    Существенные изменения потребовались в следующей версии, ORACLE*CASE 5.1 (1993г.), в связи
    с реализацией нового сервера ORACLE/7 и перехода к графическому интерфейсу конечного
    пользователя. В настоящее время завершена работа по выпуску в промышленную эксплуатацию
    новой CASE-среды под названием DESIGNER/2000, работающей в среде MS WINDOWS. Этот
    продукт вместе со средствами разработки DEVELOPER/2000 реализуют новый подход фирмы
    ORACLE к общей среде создания и сопровождения прикладных систем (рис. 2).


    Стандартные редакторы свойств ( более 20) являются наследниками базовых редакторов и, вместе с
    последними, доступны программисту для расширения/изменения функциональности, опять-таки, с
    использованием механизмов наследования и полиморфизма. Регистрация редакторов свойств и
    регистрации компонент аналогична регистрации самих компонент.

    Так как редакторы свойств и редакторы компонент определяют design-time, существование
    таких редакторов и возможность расширения их функциональности являются вторым признаком
    открытости Delphi.

    Sybase System 11 выпущена

    Архитектура взаимодействия с СУБД


    Кроме написания SQL-запросов непосредственно разработчиком, в JAM существует возможность
    автоматической генерации SQL-запросов. Эта возможность реализуется Менеджером Транзакций
    JAM. Работа Менеджера Транзакций основана на том, что объекты приложения имеют ряд
    свойств, характеризующих взаимосвязь объекта приложения с объектом БД и то, как эти объекты
    участвуют в операциях с БД (SQL-операторы select, insert, update, delete). Экранные интерфейсные
    элементы (поля ввода/вывода) отображаются в поля таблиц БД. Экранные поля, отображаемые на
    одну таблицу БД, группируются в группу типа Образ Таблицы (table view). Кроме этого,
    существуют специальные объекты типа связь (link), описывающие связи между таблицами БД. Эта
    информация в подавляющем большинстве случаев является достаточной для автоматической
    генерации SQL запроса для выполнения той или иной операции с БД. Задание этой информации
    может быть осуществлено или непосредственно разработчиком, или же автоматически при
    импорте структуры БД (метаданных) в Репозиторий JAM. При этом для каждой таблицы БД в
    Репозитории JAM создается отдельный вход (entry), в котором создается соответствующий Образ
    Таблицы (table view) и свойства объектов (т.е. членов группы table view) настраиваются
    соответствующим образом. Если СУБД, структура БД которой импортируется, поддерживает
    конструкции "primary / foreign keys", то будут автоматически созданы объекты типа связь (link).
    Для разработки приложений с использованием Менеджера Транзакций в Редакторе Экранов
    предусмотрены следующие возможности:

  • Окно DB Interaction - представляет в графическом виде образы всех
    таблиц (Table View), присутствующих на разрабатываемом экране, и их
    отношения друг с другом;
  • Опция Trace On / Trace Off - в режимах приложения и тестирования
    трассируются все SQL команды, генерируемые Менеджером Транзакций;
  • Отладчик ядра JAM позволяет более детально анализировать работу
    Менеджера Транзакций; возможна установка точек прерывания при
    активизировании Менеджера Транзакций.

    Менеджер Транзакций, получив ту или иную команду, анализирует соответствующие свойства
    экранных объектов, строит необходимый SQL-запрос и исполняет его. Команды менеджера
    Транзакций имеют очень простую и краткую форму и могут не зависеть от содержимого
    экрана.

    Таблица 1>

    Основные команды Менеджера Транзакций


    Команда
    		Действие
    NEW
    		Подготовка к вводу новых
    записей, в том числе и для нескольких связанных
    таблиц
    VIEW
    		Выбор информации из БД с
    целью просмотра
    SELECT
    		Выбор информации из БД с
    целью изменения, отличается от команды VIEW установкой
    блокировок
    CONTINUE
    		Повторить предыдущую
    команду VIEW или SELECT для следующей
    записи
    SAVE
    		Запись сделанных измененной в
    БД
    CLOSE
    		Перевод Менеджера
    Транзакции в начальное состояние
    В табл. 1 приведены основные команды Менеджера Транзакций и их краткое
    описание.

    В результате вместо написания SQL запроса, который может состоять из десятка строк, достаточно
    вызвать Менеджер Транзакций с соответствующей командой. Например, err =
    sm_tm_command("SELECT").

    Непосредственно работа Менеджера Транзакций определяется Моделью Транзакции. Модель
    Транзакции - это алгоритм реализации каждой команды Менеджера Транзакции, который
    определяет все аспекты его работы, например установку блокировок при выполнении команды
    SELECT (выборка для модификации), генерацию уникального первичного ключа при добавлении
    новой записи (если сама СУБД не реализует этой возможности) и т.д. Для каждой поддерживаемой
    СУБД в составе соответствующего JAM/DBi поставляется своя Модель Транзакции. Модель
    Транзакции поставляется в исходных кодах и опытные разработчики могут таким образом
    модифицировать поведение Менеджера Транзакции. Каждая Модель Транзакции имеет имя и даже
    для одной СУБД в одном приложении может быть определено и использовано несколько Моделей
    Транзакции.

    В зависимости от контекста команды, выполняемой Менеджером Транзакций, существует
    возможность управления поведением экранных объектов. Например, при выполнении команды
    VIEW (транзакция "только чтение") можно запретить ввод или изменение информации в экранных
    полях и сделать кнопку "Запись" неактивной. Эта возможность реализуется через механизм стилей
    JAM. Стиль - это определение свойств для различных контекстов команд. Компонента JAM
    Редактор Стилей, которая упоминалась выше, позволяет разработчику определять свои
    стили.

    JAM может работать практически со всеми распространенными РСУБД, включая Oracle, Informix,
    Sybase, Ingres, Rdb, DB2, InterBase, Gupta, Netware SQL Server, ODBC-совместимые БД и др.

    Диаграмма уровня атрибутов в нотации IDEF1X


    Вид той же диаграммы в нотации IE (Information Engineering) показан на рис.4.

    Диаграмма уровня атрибутов в нотации IDEF1X

    Диалог описания предупреждения


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

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

    Мы уже упоминали, что к предупреждению можно привязать ту или иную задачу. Задача может
    представлять собой:


  • команду операционной системы, .CMD или .EXE файл;
  • команду процесса тиражирования;
  • команду чтения журнала;
  • команду процесса синхронизации процесса тиражирования;
  • выражение языка Transact-SQL (в том числе имя хранимой процедуры).

    В результате, прежде чем выдергивать администратора среди ночи из теплой постели, система в
    состоянии сделать попытку самостоятельно решить возникшую проблему (конечно, если
    администратор заранее подготовил ее к этому). И только в том случае, если задача после
    выполнения сообщает о невозможности решения возникшей проблемы, имеет смысл прибегать к
    помощи человека. Каждой задаче можно назначить вызов администратора по электронной почте
    или пейджеру при успешном завершении или провале.(Рис.4)

    Диалог описания предупреждения

    В то же время

    В то же время на Intel-платфорах работает СУБД для рабочих групп Sybase SQL Anywhere 5.0 -
    новая версия популярной СУБД Watcom SQL, которая теперь имеет режим совместимости с Sybase
    SQL Server на уровне языка и интерфейсов.


    Серверные продукты Sybase System 11
    OLTP различные виды операцийDDS
    хранилища данных    		Массовое использование
    В то же время СУБД


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

    На втором этапе разрабатываются детальные концептуальные модели предметной области,
    описывающие информационные потребности организации, особенности функционирования и т.д.
    Результатом являются модели двух типов - информационные, отражающие структуру и общие
    закономерности предметной области, и функциональные, описывающие особенности решаемых
    задач.

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

    И наконец, на этапе реализации создаются программы, отвечающие всем требованиям проектных
    спецификаций. Использование генераторов приложений, входящих в состав DESIGNER/2000,
    позволяет полностью автоматизировать этот этап, существенно сократить сроки разработки
    системы и повысить ее качество и надежность.

    В соответствии с общей архитектурой инструментальные средства, входящие в состав
    DESIGNER/2000, разбиваются на следующие компоненты (рис. 4):


  • средства доступа к репозитарию
  • средства управления репозитарием
  • средства анализа деловой деятельности
  • средства концептуального моделирования
  • средства проектирования системы
  • генераторы приложений


    В то же время

  • навигатор объектов репозитария
  • матричный диаграммер
  • средства администрирования
  • средства моделирования процессов
  • диаграммер ER-моделей
  • диаграммер иерархии функций
  • диаграммер потоков данных
  • диаграммер структуры приложения
  • навигатор параметров
  • навигатор процедурной логики
  • диаграммер баз данных
  • диаграммер модулей
  • генератор сервера
  • генератор форм
  • генератор отчетов

    • Диаграмма уровня атрибутов в нотации IE


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

    В редакторе "Database Schema" указываем для каждой сущности соответствующее имя таблицы.
    Затем в редакторе "Attribute Definition" задаем имена колонок таблиц, соответствующие атрибутам
    сущностей. ERwin и здесь обеспечивает миграцию имен колонок в подчиненные таблицы.

    На этом этапе можно воспользоваться и редактором "Extended Attributes" для определения
    расширенных атрибутов PowerBuilder (формата отображения, маски редактирования, правила
    контроля, выравнивания, заголовков и комментариев).

    В редакторе "Relationship Definitions" указывается физическое имя связи, которое соответствует
    имени ограничения (constraint), создаваемого ERwin в базе данных.

    Теперь все готово к созданию БД и нужно выбрать целевую СУБД (если этого не было сделано
    раньше). Выберем, например, Sybase System 10.

    В редакторе SYBASE Database Schema задаем типы данных для колонок таблиц.

    Диалог, в котором происходит выбор типа данных, приведен на рис.5.

    Диаграмма уровня атрибутов в нотации IE

    Диалог описания задачи



    Теперь давайте рассмотрим сценарий, по которому могут развиваться события. Ночью произошел
    сбой в электросети. Источник бесперебойного питания выработал свой ресурс, потом выполнил
    ShutDown сервера, и система прекратила работу. Со временем электропитание было
    восстановлено, и компьютер снова включился. Не секрет, что Windows NT способна выполнять
    автоматическую, без участия человека, регистрацию в сети. В силу того, что SQL Server и SQL
    Executive представляют собой сервисы операционной системы, им можно назначить атрибут
    "стартовать автоматически". SQL Server стартовал, и на исполнение была запущена хранимая
    процедура, которая также имеет атрибут "автостарт". Такая процедура может, например,
    выполнить проверку целостности базы данных. Если проверка прошла успешно, система
    продолжает работу в штатном режиме. Если проверка показала, что система неработоспособна,
    можно пойти как минимум двумя путями: хранимая процедура генерирует ошибку, вызывающую
    предупреждение, которое, в свою очередь, вызывает на выполнение задачу. Можно сразу поднять
    тревогу и вызвать администратора.

    Но электронная почта пригодна не только для того, чтобы поднимать тревогу, она может
    использоваться и для штатной работы. SQL Server 6.0 умеет читать почту и отвечать на письма. В
    том случае, когда задержки на прохождение электронного письма не критичны для работы,
    пользователь или администратор могут использовать почту для посылки запросов серверу и
    получения от него ответа. Это позволяет обращаться к серверу в режиме Off-line практически с
    любого компьютера (как известно, клиентское приложение одной из наиболее популярных в
    России коммуникационных сетей - Релком - прекрасно работает даже на машинах с процессором
    286).


    Инфраструктура среды распределенных приложений


    Данный продукт предлагает коммуникационный интерфейс, с помощью которого части (или
    разные) приложения могут обмениваться информацией. Функции интерфейса поддерживают
    синхронное и асинхронное взаимодействие приложений, при этом, первый тип наиболее
    подходит для реализации диалоговых систем, тогда как второй - для систем типа запрос/ответ
    или предполагающих обмен большими объемами данных.

    С точки зрения архитектуры продукт ENTIRE BROKER выполнен в виде ядра -
    коммуникационного сервера, регистрирующего доступные в сети серверы приложений
    (функциональные серверы) и клиентов, запрашивающих данные серверы.

    Взаимодействие клиентов ENTIRE BROKER с ядром базируется на еще одном продукте
    SOFTWARE AG - ENTIRE NET-WORK, с помощью которого взаимодействие частей
    приложения становится полностью независимым от используемого в системе транспортного
    протокола.

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

    Рекомендуемый SOFTWARE AG подход к построению распределенных приложений состоит в
    разработке их частей на NATURAL, в котором имеется полный набор компонентов, необходимых
    для построения распределенных приложений не зависящих от аппаратно-программных платформ.

    Сочетание ENTIRE BROKER, ENTIRE NET-WORK и NATURAL обеспечивает
    прозрачность для клиентов местонахождения сервера (необходимо знать только своего
    брокера), создавая администраторам прикладных систем условия для их правильного
    масштабирования.


    Модель базы данных в модуле RDM


    Структура данных, на основе которой будет строится
    ER-модель

    Любые комбинации столбцов таблиц и связей можно выделить для генерации индексов. SILVERRUN
    сама может сгенерировать индексы для первичных и альтернативных ключей, а также операторы
    контроля ссылочной целостности на основе характеристик связей.

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

    Для поддержки различных методологий модуль RDM предоставляет возможность переопределения
    нотации. На рис. 5 изображен экран выбора графических символов для представления различных
    характеристик связей.
    Модель базы данных в модуле RDM

    Взаимодействие JAM, CASE и СУБД


    На рис. 4 приведена схема взаимодействия JAM и CASE с использованием модуля
    JAM/CASEi.

    Следует отметить, что модуль JAM/CASEi позволяет осуществлять импорт/экспорт не только в
    раздел ERD репозитория CASE, но и в раздел DFD.

    Кроме модуля JAM/CASEi фирма-производитель распространяет модуль JAM/CASEi Developer's
    Kit. С помощью этого модуля можно самостоятельно разработать интерфейс (т.е.
    специализированный модуль JAM/CASEi) для конкретного инструмента CASE, если готового
    модуля JAM/CASEi для данной CASE-системы еще не существует.


    Cерверные продукты Sybase System

    Cерверные продукты Sybase System 11 обладают мощной и гибкой архитектурой, построенной на
    основе продуктов и библиотек Sybase Open Client/Server . Среди основных
    серверных продуктов Sybase System 11 (рис.4):


  • Sybase SQL Server - мощная высокопроизводительная реляционная СУБД;
  • Sybase MPP - расширение архитектуры Sybase SQL Server, разработанное и
    оптимизированное для массовой параллельной обработки. Он обладает
    открытой параллельной архитектурой, предназначенной для поддержки очень
    больших баз данных (VLDB);
  • Sybase IQ - серверный механизм построения битовых индексов для
    высокоскоростного выполнения сложных запросов к большим объемам данных;
  • Sybase SQL Anywhere - "легкая" полнофункциональная СУБД на Intel-
    платформах для мобильных пользователей и небольших групп;
  • Sybase Replication Server - репликационный сервер для построения
    распределенных систем на основе тиражирования данных;
  • Sybase OmniConnect - сервер, обеспечивающий работу приложений-
    клиентов в "прозрачном" режиме с несколькими серверами так, как будто
    работа идет с одним сервером; при этом в распределенную систему могут
    включаться СУБД различных производителей - Sybase, Oracle, IBM и т.д.

    Вспомогательные серверные продукты Sybase System 11 включают:


  • Sybase Backup Server - специальный сервер для высокопроизводительной
    выгрузки и загрузки баз данных, не требующий остановки SQL Server и не
    снижающий его производительности;
  • Sybase Monitor Server - в сочетании с графической клиентской частью
    выполняет мониторинг различных параметров состояния SQL Server;
  • Sybase Replication Agent - специальные компоненты, отслеживающие
    изменения в данных через журналы транзакций различных СУБД для
    включения их в систему репликации. Replication Agent существуют, в частности,
    для Sybase SQL Server, Oracle, DB2, Sybase SQL Anywhere.
  • Sybase Audit Server - записывает информацию о действиях пользователей в
    специальную базу данных, доступную для анализа.

    К инструментальным средствам фирмы Sybase относятся, в частности, лидирующее средство
    быстрой разработки приложений PowerBuilder и CASE-система S-Designor, выпускаемые
    подразделением Powersoft. Эти средства работают со всеми основными СУБД. В первой половине
    1996 года выпускаются версии PowerBuilder 5.0 (с новыми средствами компиляции и
    распределенными объектами) и S-Designor 5.0 (с модулями описания бизнес-процессов, моделей
    данных и генерации приложений). Фирма АлконсСофт является бета-тестером данных продуктов.
    PowerBuilder и S-Designor подробно описаны в публикациях .


    Наличие средств построения программных модулей генерации кода и обработки внутренней IDE-
    информации, называемых экспертами, являются третьим признаком открытости архитектуры
    Delphi.

    Диалог определения прав доступа



    Уровень
    		Компоненты SQL Server 6.0 DMF
    Уровень 1

    Представление/Манипуляция
    		Средство администрирования SQL Enterprise Manager,
    программирование на Visual Basic или Visual FoxPro
    Уровень 2
    Объекты управления
    		OLE интерфейс для доступа ко всем средствам
    администрирования и управления SQL Server
    Уровень 3

    Реализация/Обработка
    		Процессор данных SQL Server, сервисы SQL Executive

    Архитектура SQL-DMF изначально предназначена для работы в распределенных средах и
    предоставляет необходимую гибкость и масштабируемость за счет разделения процесса
    администрирования на три четко определенных уровня:


    Экран выбора символов для характеристик связей


    Различные группы пользователей имеют доступ к разным подмножествам базы данных и к ограниченному
    набору операций над ними. Для моделирования пользовательских (внешних по терминологии ANSI
    SPARC) представлений в модуле RDM используется механизм подсхем. Подсхема - это подмножество
    модели данных, доступное конкретному приложению или группе пользователей. SILVERRUN позволяет
    управлять "прозрачностью" границы между схемой и подсхемой, а также по требованию интерактивно
    переносить изменения из схемы в подсхему и наоборот. Число уровней подсхем не ограничено: можно
    создавать подсхемы подсхем.


    Определение физической модели


    Теперь можно перейти к созданию базы данных. Для этого выполняется команда "Sybase schema
    generation". ERwin построит пакет SQL-предложений генерации базы данных. На рис.6 показан диалог выбора параметров генерации пакета для генерации БД.
    На рисунке видно, что может быть задан фильтр (генерация не всех таблиц), пакет SQL-предложений
    можно просмотреть (preview), распечатать, сохранить в файл (report), выполнить генерацию
    (generate).

    Определение физической модели

    Схемы удаленного доступа к БД ADABAS посредством SQL


    В случае, если прикладная система написана на NATURAL или языках 3-го поколения с
    использованием языка манипулирования данными (ЯМД) СУБД ADABAS, доступ к удаленной
    СУБД реализуется в соответствии с рис. 6.


    Платформы клиентов
    Платформа СЭВМ (UNIX, IBM)
    Схемы удаленного доступа к БД ADABAS посредством SQL
    IBM, UNIX, MS WindowsMS Windows


    Системный администратор может разделить

    Системный администратор может разделить кэш SQL Server на несколько именованных областей и
    приписать эти области различным базам данных и объектам баз данных. Имеется возможность
    группировать именованные области кэша так, чтобы более эффективно проходил обмен с диском
    большими блоками. Связывание именованных кэшей и объектов баз данных осуществляется при
    помощи вызова системных процедур (рис.6).


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

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


    И действительно, ряд производителей программных продуктов, относящихся к перечисленным
    категориям, заявил о поддержке ими Delphi на достаточно высоком уровне интеграции
    (подразумевая, например, для CASE-систем, не только генерацию кода в соответствии с
    синтаксисом Object Pascal, но и доступ к таким продуктам непосредственно из IDE). В качестве
    примера можно привести компанию Popkin Software (производителя CASE-средства System
    Architect), объявившую о поддержки Delphi в своих продуктах еще в августе 1995 года. Известен
    ряд систем контроля версий - Intersolv PVCS и MKS Source Integrity, способных работать с Delphi
    (32-разрядная версия PVCS входит в поставку Delphi Client/Server Suite 2.0, планируемого к выходу
    в первом квартале 1996 г.) и , например, мониторов транзакций (существует опыт взаимодействия с
    Novell Tuxedo и др.).

    Описанные возможности интеграции с внешними приложениями на базе совокупности открытых
    интерфейсов, определяют четвертый признак открытости архитектуры Delphi.

    Компоненты SQL-DMF


    Ранее существовавшие подходы к системному администрированию приводили к запоздалой
    реакции на сбой системы, а администратору отводилась роль "пожарного". С другой стороны,
    обработчик событий SQL Executive изначально проектировался для поддержки активной модели
    администрирования, позволяющей администратору определять предупреждения и проводить
    корректирующие операции до возникновения проблемы. Кроме того, администратор может
    заранее определить уведомления, которые будут рассылаться по электронной почте или на
    пейджер.

    SQL Executive работает как сервис операционной системы и при необходимости может быть
    запущен автоматически для загрузки списка задач, хранящегося в таблице SQL Server.


    Консолидация модели данных с моделью в словаре


    Возможные режимы консолидации в S-Designor:
    Consolidate
    -     		консолидировать модель с моделью в словаре.
    Simulate
    -     		имитировать консолидацию без внесения
    реальных изменений в словарь метабазы.
    Create
    -     		создать проект или модель в
    словаре.
    Replace
    -     		заменить существующую модель. Данный
    режим эффективно использовать в случае, если консолидируемая
    модель значительно отличается от модели в словаре.
    Создавая проект администратор может указать имя пользователя, который станет
    владельцем этого проекта или сделать это после создания проекта. Так назначается владелец
    проекта.

    Проект может включать несколько моделей данных (Рис.7).
    Обеспечивается возможность одновременно разрабатывать отдельные модели отдельными
    разработчиками. Консолидацию выполняет администратор проекта или пользователь, имеющий
    соответствующие полномочия.
    Консолидация модели данных с моделью в словаре

    Схемы удаленного доступа к БД ADABAS посредством ЯМД ADABAS


    Данный интерфейс предлагается фирмой SOFTWARE AG в качестве основного при разработке
    переносимых приложений в среде ADABAS/NATURAL.

    Как видно из рисунка клиентами СУБД ADABAS могут быть не только приложения, выполняемые
    в среде рабочих станций, но и приложения, написанные на NATURAL или языках
    программирования 3-го поколения и выполняемые как под Windows, так и в среде IBM и UNIX.

    Дополнительно к основному интерфейсу языка манипулирования данными для платформы
    Windows SOFTWARE AG предлагает доступ к базам данных ADABAS с помощью DDE-
    протокола, оформляя доступ к СУБД в виде DDE-сервера (ADADDE). Некоторые примеры
    программных продуктов, поддерживающих DDE-протокол, также приведены на рис. 6.

    Наряду с удаленным доступом к базам данных ADABAS, SOFTWARE AG предлагает
    использовать продукт ENTIRE ACCESS для доступа к реляционным базам данных третьих фирм
    из приложений, написанных на NATURAL (рис. 7).
    Схемы удаленного доступа к БД ADABAS посредством ЯМД ADABAS

    Запросы на выборку данных

    Запросы на выборку данных и запросы на их изменение в этом случае не блокируют друг друга, и
    конкретные приложения, для которых допустим режим "грязного чтения", могут существенно
    выиграть в производительности. В то же время для транзакций, требующих целостности данных,
    нельзя использовать уровень изоляции 0.

    Установка уровня изоляции может производиться либо для конкретного запроса SELECT, либо
    для сессии пользователя в целом.


    Диаграмма строится из стандартных элементов, основными из которых являются:

    Базовый процесс - процесс, определяющий общий контекст для всех подпроцессов данной
    диаграммы, т.е. тот главный процесс, который описывается данной диаграммой.

    Шаг процесса - определенная часть деятельности в рамках базового процесса;
    впоследствии любой шаг может служить основой для нового базового процесса и новой
    диаграммы.

    Хранилища - предназначены для представления некоторого информационного фонда или
    материального склада.

    Потоки - описывают передачу информации или материальных объектов между двумя
    шагами процессов или между процессом и хранилищем.

    Организационные единицы - представляют структуру предприятия или фирмы; допускается
    иерархическая структура организационных подразделений без ограничения на уровень
    вложенности.

    События - могут быть входные и выходные; служат для связи различных диаграмм
    процессов.

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

    Запросы на выборку данных

    Вследствие такой открытости архитектуры Delphi, большое количество третьих компаний уже
    выбросило на рынок (или объявило о соответствующих планах) как различные расширения
    библиотеки компонент VCL (более 200 только коммерческих наборов компонент на октябрь
    1995г.) так и средства интеграции своих продуктов (external-site interface).

    С любым отдельным шагом

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

    С любым отдельным шагом

    Схемы удаленного доступа к реляционным СУБД с помощью ENTIRE ACCESS


    ENTIRE ACCESS позволяет разработчику приложений полностью использовать преимущества
    NATURAL как универсального инструментария разработки переносимых приложений в
    средах неоднородных баз данных, обеспечивая доступ не только к удаленным, но и к локальным
    (работающим на той же ЭВМ, что и приложение) реляционным базам данных других фирм.

    Предоставляемый этим продуктом интерфейс позволяет разработчику приложений на NATURAL
    применять для доступа к реляционным СУБД, наряду с ANSI SQL, синтаксис ЯМД,
    реализованный в NATURAL для доступа к базам данных ADABAS.

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

    Внутренняя исполнительная система NATURAL преобразовывает предложения ЯМД и SQL в
    вызовы ENTIRE ACCESS, выполняющего необходимые преобразования форматов данных и
    обмен сообщениями с соответствующей СУБД.

    В качестве транспорта запроса к удаленной РСУБД применяется продукт ENTIRE NET-
    WORK.


    Список моделей проекта


    Создав проект, администратор назначает пользователям полномочия, например, на отдельные
    подмодели. Полномочия действуют в момент консолидации. Модели или подмодели, на которые
    пользователи не имеют полномочий, недоступны для редактирования.

    Реализуя функцию управления доступом для моделей и подмоделей данных, S-Designor
    обеспечивает возможность руководителю проекта контролировать все изменения, которые влияют на
    проект в целом. При этом, модель данных всегда доступна, актуальна и гарантированно целостна.

    Структура объектной модели SQL Server


    Системы архитектуры клиент-сервер предлагают много новых задач, требующих нового подхода.
    Мощные серверы баз данных должны адаптироваться к растущим требованиям динамичной и все
    более усложняющейся работы в распределенных средах. SQL Server 6.0, снабженный развитой
    средой администрирования распределенных систем, удовлетворяет этим требованиям.


    Выбор синхронизируемых таблиц


    ERwin "знает" о таких особенностях хранения данных в отдельных СУБД, как сегменты (в Sybase) и
    табличное пространство (в Oracle). Информация о физическом размещении может быть включена в
    модель и использована при прямом и обратном проектировании.


    Концепция репликации данных


    Главный узел может находиться под управлением IBM или UNIX-ЭВМ. Узлы-реплики могут
    располагаться на любой платформе серверных ЭВМ, на которой может быть установлен ADABAS,
    и которая может быть доступна через ENTIRE NET-WORK.

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

    Файл подтверждения необходим для регистрации ранее выполненных транзакций в файлах-
    репликах.

    Файл-реплика может быть полной или выборочной копией главного файла в зависимости от
    условий репликации, задаваемых администратором распределенной базы данных.

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

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


    []
    []
    []

    Выбор СУБД для создания модели


    ERwin поддерживает также настольные (desktop) СУБД: Microsoft Access, FoxPro, Clipper, dBASE III,
    dBASE IV и Paradox.

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

    Для создания физической структуры БД может быть запрошена генерация DDL-скрипта (data
    definition language). При этом используется диалект SQL для выбранного типа и версии сервера. Хотя
    сгенерированный код не нуждается в модификации, имеется возможность его сохранить в файл или
    распечатать.


    В одном или нескольких

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

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

    В узле, содержащем первичные данные, для каждой тиражируемой базы данных запускается
    специальная компонента - репликационный агент (Replication Agent - RA). Он подключается к
    серверу БД и получает от него уведомления о завершении транзакций. Измененные данные
    передаются репликационному серверу, обслуживающему этот узел. Репликационный сервер в
    соответствии с описанием тиражирования и подписками отправляет данные в специальном
    эффективном протоколе по месту назначения - соответствующим репликационным серверам в
    удаленных узлах.

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

    По умолчанию репликационный сервер сохраняет смысл операций. Это значит, что удаление
    записи из первичной таблицы (выполнение оператора DELETE) приведет к выполнению такого же
    оператора DELETE в узле, хранящем копию таблицы; выполнение INSERT или UPDATE над
    первичной таблицей точно так же приведет соответственно к добавлению или обновлению записи
    в копии таблицы в результате работы системы репликации.
    Имеется гибкий механизм
    конфигурирования так называемых функциональных строк (function strings), которые
    переопределяют любую операцию на макроязыке с возможностью подстановки параметров.

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

    Для работы механизма асинхронного вызова процедур в нескольких базах данных создаются
    процедуры с одинаковым именем и параметрами, но, возможно, с различным текстом. В одной
    базе данных процедура помечается как предназначенная к репликации. Вызов этой процедуры
    вместе со значениями параметров передается через журнал и механизм репликации к узлам-
    подписчикам. Затем в базах данных подписчиков вызывается одноименная процедура с теми же
    значениями параметров.

    Таким образом, для обновления "чужих" для узла данных (копии данных) прикладная программа-
    клиент вместо выполнения оператора UPDATE вызывает заранее определенную в этом узле
    хранимую процедуру и передает ей параметры (например, значение первичного ключа и новые
    значения для обновляемых колонок). Тело этой процедуры пустое и она не выполняет никаких
    действий, однако ее вызов записывается в журнал. Механизм репликации обеспечивает вызов на
    узле, содержащем первичные данные, одноименной процедуры с подстановкой параметров. В теле
    этой процедуры может быть записан оператор UPDATE, обновляющий первичные данные. Тот же
    механизм репликации передаст изменения в данных узлу, инициировавшему операцию.

    Репликационный сервер и Replication Agent реализованы в виде отдельных модулей и могут
    выполняться не на том же компьютере, что сервер базы данных. Включение в систему
    репликационного сервера практически не оказывает влияние на загрузку сервера первичной базы
    данных.

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


    Oracle, Informix, Ingres, DB2, RMS, ISAM, или даже приложение Open Server.

    СУБД, хранящая первичные данные, требует наличия для нее RA. Сейчас RA имеется для Sybase
    SQL Server, Oracle, DB2, Sybase SQL Anywhere. Готовятся RA и для других СУБД. Интерфейс RA
    открыт и возможно создание RA для нестандартных источников данных.

    Некоторые применения тиражирования данных:


  • сервер, выполняющий активное обновление данных (OLTP), разгружается
    от сложных запросов, связанных с поддержкой принятия решений (DSS);
  • консолидация данных от подразделений в центре;
  • обмен данными по медленным и/или ненадежным линиях связи;
  • поддержание резервной базы данных;
  • построение сети равноправных узлов, обменивающихся данными.

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

    Задание расширенных атрибутов PowerBuilder


    Функция ERwin по генерации DataWindow позволяет сгенерировать прототипы окон данных
    будущего приложения уже на стадии создания информационной модели. Для создания Data Windows
    предлагается Wizard, с помощью которого указывается стиль окна и выбранные колонки
    таблиц.


    С использованием побитовой схемой

    С использованием побитовой схемой индексации Sybase IQ практически все данные в БД могут
    быть проиндексированы. Поэтому никакой запрос не приведет к просмотру записей таблиц. Sybase
    IQ обладает высокой производительностью для заранее запланированных запросов и отлично
    справляется с запросами "на лету".

    Sybase IQ не требует изменений в приложениях - любая программа, работающая с SQL Server,
    будет работать с IQ. Собственно Sybase IQ не выполняет отдельных обновлений данных. Он в
    прозрачном для клиента режиме передает их для выполнения SQL Server. Sybase IQ очень
    эффективно выполняет пакетные дополнения к базе данных. В отличие от технологий, основанных
    на B-деревьях, при добавлении 10 миллионов строк в таблицу, где уже есть десятки миллионов
    строк, Sybase IQ просто построит дополнительные страницы индекса и не потребует перестраивать
    весь индекс целиком.


    Например, на рис.9 для сущностей "СЛУЖАЩИЙ" и "ОТДЕЛ", определена взаимосвязь,
    описывающая распределение людей по отделам . В данном случае диаграмма моделирует
    следующие семантические ограничения:


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

    На рис. 10 приводится более сложный пример , иллюстрирующий дополнительные возможности
    ER-диаграмм: моделирование подтипов и исключающих взаимосвязей. В данном примере каждый
    сотрудник может принимать участие в некотором (не более чем одном) проекте или заниматься
    преподаванием одного учебного курса. При этом существует дополнительное правило: никто не
    может одновременно участвовать в проекте и преподавать. Такие исключающие друг друга
    взаимосвязи изображаются на диаграмме линиями, объединенными дугой (рис. 10). Кроме того,
    при изображении сущности "ПРОЕКТ" учитывается, что любой проект может быть одним из двух
    видов - исследованием или разработкой (каждый из этих подтипов описывается своим набором
    атрибутов).

    С использованием побитовой схемой

    Семейство Powersoft Enterprise Series

    PowerBuilder™ входит в состав Powersoft Enterprise Series™, семейство инструментальных
    средств для разработки масштабируемых приложений в среде клиент/сервер, которые могут быть
    использованы различными категориями пользователей организации - от разработчиков сложных
    корпоративных информационных систем до разработчиков на уровне отделов и конечных
    пользователей.
    Семейство Powersoft Enterprise Series
    Построенные на унифицированной платформе клиент/сервер и единой объектной технологии
    продукты Powersoft Enterprise Series представляют собой среду разработки приложений в
    масштабах предприятия(Enterprise Development Architecture).

    В Powersoft Enterprise Series входят различные редакции PowerBuilder. PowerBuilder Enterprise
    предназначен для создания сложных многоплатформных приложений клиент/сервер коллективами
    профессиональных разработчиков. PowerBuilder Team/ODBC обеспечивает возможность
    коллективной разработки и работает с серверами баз данных через ODBC. PowerBuilder Desktop
    предназначается индивидуальным разработчикам, создающим автономные приложения под Windows
    с помощью Watcom SQL и настольных баз данных. Advanced Developer Toolkit включает библиотеку
    многократно используемых объектов, а также развитые инструментальные средства, такие как
    редактор изображений и построитель инсталяционных дискет, а также поддержку хранимых процедур
    баз данных, NetWare и ввод данных с помощью пера.

    В Powersoft Enterprise Series также включен InfoMaker™ - персональный инструмент разработки в
    среде клиент/сервер, который позволяет конечным пользователям создавать запросы, формы, отчеты и
    деловую графику. Пользователи могут манипулировать данными, применяя подход, основанный на
    формах и не требующий программирования.


    Продукты для всех
    WATCOM C, C++

    PowerBuilder Enterprise    		Семейство Powersoft Enterprise Series
    PowerBuilder Team/ODBC
    PowerBuilder Desktop
    InfoMarker

    Семейство продуктов Powersoft Enterprise Series предоставляет менеджерам информационных систем
    возможность использовать преимущества технологии клиент/сервер в масштабе всего предприятия.
    Так как все продукты основаны на общей объектной технологии, пользователи могут создавать
    приложения и передавать их в любое время менеджерам для продолжения разработки, поддержки или
    сопровождения. Таким образом, разработчики и конечные пользователи получают инструменты,
    которые позволяют использовать преимущества технологии клиент/сервер в рамках всей
    организации.


    Серверные продукты компании Informix

    Н.Вьюкова
    СУБД INFORMIX, первая версия которой вышла в 1980 г., традиционно использовалась для
    создания информационных систем малого или среднего масштаба, работающих в режиме
    оперативной обработки транзакций. Однако, начиная с версии 6.0, сервер Informix, получивший
    название Informix-Online Dynamic Server (Informix ODS), прибрел такие черты, которые позволили
    с успехом применять эту СУБД для реализации крупных проектов.

    Многопотоковая архитектура сервера послужила базой для реализации технологии параллельной
    обработки запросов, которая включена в версию 7. Эта технология обеспечивает эффективное
    выполнение сложных запросов, характерных для систем поддержки принятия решений (Decision
    Support Systems - DSS).

    Архитектурные и технологические решения, положенные в основу Informix-ODS, нашли
    дальнейшее развитие в последнем серверном продукте компании - Informix-Online EXtended
    Parallel Server (Informix-ОXPS), который предназначен для кластерных и массово-параллельных
    платформ и предоставляет повышенный уровень производительности и отказоустойчивости.

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


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


    Синхронизация с базой данных

    В процессе разработки информационной системы может возникнуть ситуация, когда структура базы
    данных и информационная модель не соответствуют друг другу. ERwin предоставляет возможность
    привести их в соответствие.

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

    Синхронизация с базой данных

    Синхронная модель. Двухфазная фиксация

    Исторически первым появился метод синхронного внесения изменений в несколько БД,
    называемый двухфазной фиксацией (2PC - two-phase commit). Этот механизм реализован сейчас
    практически у всех производителей СУБД.

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

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


    Система моделей описания требований к ИС

    Главной целью формирования системы моделей описания требований к ИС является обеспечение
    корректного перехода от моделей описания организации к системе моделей ИС, описывающих
    конкретные компоненты проекта, такие как приложения, базы данных, общесистемное ПО,
    средства вычислительной техники и телекоммуникации, при котором обеспечивается отображение
    целей и задач организации (выраженных через ее бизнес-процессы, данные, функции и другие
    модели) в функции и компоненты ИС.

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

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

    Из полного набора требований к ИС для дальнейшего анализа и проектирования мы выделим
    требования к программному и информационному обеспечению и к интерфейсу с пользователями,
    оставляя в стороне требования к архитектуре и средствам вычислительной техники и
    телекоммуникаций.


    Системы сквозного проектирования

    А. Закис, Н. Приезжий, DataX/FLORIN






    В предшествующих выступлениях и публикации мы неоднократно рассматривали технологию сквозного проектирования информационных систем, основанную на использовании CASE инструментария фирмы Cayenne (VantageTeam), сред разработки приложений фирм Informix (4GL и NewEra) и Four Seasons (SuperNova) и кодогенераторов фирмы DataX/FLORIN (GRINDERY OneStep 4GL, GRINDERY NewEra/Yourdon, GRINDERY SuperNova/Yourdon). В данном выступлении мы хотели бы рассказать о новом продукте нашей фирмы - среде быстрой разработки GRINDERY Grabber.

    Технология

    Прежде всего, мы хотели бы ответить на вопрос, который нам неоднократно задавали во время UnixExpo, где был представлен этот продукт: почему мы взялись за его разработку в то время, когда на рынке имеется достаточное количество разнообразных CASE средств и билдеров. Ответ прост - этот продукт "создался сам" из тех технических решений, которые мы использовали при работе над собственными проектами или предлагали нашим клиентам для того, чтобы соединить различные средства автоматизации проектирования и программирования в единый технологический процесс, и которые отсутствовали (или были недостаточно развиты) в готовых продуктах .

    Что же не устраивало нас в стандартных подходах? Для ответа на этот вопрос рассмотрим две модели использования средств автоматизации: "до и от" и "от и до".

    Первый подход (пропагандируемый разработчиками билдеров и "легких" CASE средств) предполагает, что CASE используется только для проектирования и ("до") создания базы данных, а разработка приложения осуществляется ("от" готовой базы) с помощью билдеров, которые обладают собственными средствами реверсинжениринга модели данных, библиотеками классов и многими другими достоинствами. На наш взгляд, основными недостатками этого подхода является то, что технологический процесс разорван - модель данных, используемая билдером, значительно беднее модели, разработанной аналитиком в CASE (или "в голове", если CASE вообще не использовался), и аналитик вынужден передавать недостающую информацию "голосом".
    При использовании билдера выясняется, что стандартные библиотеки классов недостаточны для полнофункционального приложения, и каждый программист по-своему наращивает функциональность, что приводит к "лоскутному" интерфейсу. Стандартизация интерфейса может быть осуществлена либо организационными методами, либо за счет использования написанной "на коленке" библиотеки классов. В итоге, аналитик и программисты получают удобный инструментарий, но его использование не приводит ни к улучшению качества системы, ни к ускорению разработки.

    Второй подход (реализованный в "тяжелых" CASE средствах, например, в VantageTeam) предполагает, что в CASE поддерживает разработку "от" анализа "до" логических моделей данных и приложения, на основе которых создается база данных и осуществляется автоматическая генерация программного кода. VantageTeam предоставляет пользователю прекрасный инструментарий для проектирования приложения:
  • диаграммы содержания экранных форм (FCD - Form Contence Diagram), которые позволяют описать структуру и (в значительной степени) функциональность сложных экранных форм (предназначенных для работы с несколькими таблицами);
  • диаграммы структурных схем (SCD - Structure Charts Diagram), которые позволяют описать алгоритмы программных модулей и методы работы с экранными формами (последняя задача в рамках структурного подхода достаточно элегантно решена с помощью так называемых "предопределенных модулей");
  • диаграммы последовательности экранных форм (FSD - Form Sequence Diagram), которая задает общую структуру приложения. а также связывает формы и алгоритмы (методы).

    Но и это не панацея. Главный недостаток этого подхода состоит в том, что идеология проектирования не учитывает реальные потребности проектировщика, который должен разработать информационную систему со стандартным интерфейсом (поскольку заказчику нужна система с легко осваиваемыми рабочими местами). Проектировщику нужны средства построения логической модели стандарта интерфейса, а не полной модели всех элементов интерфейса. Детальное проектирование каждой экранной формы (средствами FCD или в билдере) при создании стандартного интерфейса является не только нудной, но и (в большинстве случаев) вредной работой (немногочисленные, как правило, "уникальные" рабочие места гораздо быстрее и проще создавать на основе типового рабочего места, а не "с чистого листа").

    Наша фирма пошла по пути проектирования стандарта. Результатом этой работы стала технология сквозного проектирования и семейство кодогенераторов GRINDERY.

    Однако их область их применения существенно ограничивалась тем, что они были настроены на логическую модель данных, формируемую VantageTeam. Затраты на приобретение и освоение "тяжелого" CASE окупаются только при создании достаточно крупных систем или при "поточном" производстве, а многие возможности, предоставляемые продуктами этого класса, не столь уж необходимы для создания небольшой системы разработчиками, хорошо знающими предметную область ( и, тем более, для воспроизведения существующей системы на другой платформе, что является весьма актуальной задачей для многих систем ). И мы занялись разработкой "легкой" технологии сквозного проектирования "от" существующей базы данных. Ее основные отличия от рассмотренной выше технологии "до и от" состоят в следующем:
  • при реверсинжениринге создается не физическая, а логическая модель данных, на основе которой осуществляется генерация стандартного интерфейса ;
  • билдеры используются только в режиме модификации, причем внесенные изменения автоматически фиксируются и воспроизводятся при повторной генерации.

    Продукт (GRINDERY Grabber v.1.0) и проект (GRINDERY Grabber v.2.x)

    GRINDERY Grabber v1.0 обеспечивает:
  • восстановление логической модели базы данных на основе информации, хранящейся в системных каталогах;
  • интерфейс для ввода параметров, описывающих стандарт приложения;
  • генерацию приложения на любом языке, поддерживаемом семейством кодогенераторов GRINDERY (в настоящее время - Informix- 4GL, NewEra, SuperNova);
  • фиксацию изменений, внесенных в программный код пользователем и их воспроизведение при повторной генерации;
  • модификацию структуры базы данных в объеме, необходимом для эффективной работы стандартного приложения.
  • GRINDERY Grabber v1.0 поддерживает:
  • групповую работу над проектами и управление версиями проектов, в том числе:

    - разграничение прав доступа;

    - независимую разработку частей проекта;

    - сборку проекта ;

  • документирование проекта.

    GRINDERY Grabber v1. 0 поддерживает разработку приложений для СУБД Informix, Oracle, CA OpenIngres и может работать на основных Unix и всех Windows платформах.

    Принципы построения стандартного интерфейса

  • Для каждой сущности (предметной таблицы базы данных) создается "рабочее место", позволяющее выполнять основные операции (INSERT, UPDATE, DELETE, QBE) с данными, содержащимися в этой таблице.
  • Рабочее место позволяет работать не только с "главной" таблицей, но и с другими ("вспомогательными" для данного рабочего места) таблицами базы данных. В том случае, когда реляционная модель данных адекватно отражает связи и бизнес-правила предметной области, вспомогательными являются "таблицы-словари" ( Master tables - таблицы, из которых импортирует ключи "главная" таблица), "таблицы-потомки" (Detail tables - таблицы, которые содержат ссылки на "главную") и "таблицы-партнеры" (связанные с "главной" таблицей отношением "многое ко многому"). Вспомогательные таблицы доступны как в режиме просмотра, так и в режиме модификации (если это необходимо для данного рабочего места).
  • Каждая таблица имеет в интерфейсе два представления:

  • в виде одной записи, содержащей полный набор полей - детальное представление.Оно используется для добавления записей в "главную" таблицу и их модификации;
  • в виде списка (браузера), который используется для навигации (поиска) по главной и вспомогательным таблицам, а также для выполнения групповых операций. При этом используется краткое представление - определяемый пользователем набор полей, достаточный для однозначной идентификации записи и содержащий наиболее часто используемую информацию (например, для таблицы "Фирма" в краткое представление целесообразно включить название фирмы и ее банковские реквизиты). Краткое представление таблицы для всех рабочих мест одинаково.

    При таком подходе основная информация, необходимая для генерации приложения "считывается" из логической модели данных. Пользователю необходимо задать незначительное количество атрибутов:
  • имена, под которыми должны отображаться таблицы и их колонки;
  • состав предметного ключа (кодогенерация рассчитана на то, что в качестве первичного используется искусственный ключ - колонка типа SERIAL);
  • форму представления колонок в графическом интерфейсе (Entry, Label etc)
  • состав краткого представления таблиц;
  • возможность модификации таблицы-словаря;
  • необходимость и форму представления информации из таблиц-потомков и таблиц-партнеров в детальной форме;
  • политику поддержки целостности при удалении.

    Структура GRINDERY Grabber

    GRINDERY Grabber включает:
  • модуль Reverse Engineering;
  • модуль DB Designer;
  • модуль Access;
  • модуль Tuner (v.2.x);
  • модуль App Designer;
  • кодогенераторы GRINDERY;
  • модуль Target Bridge;
  • модуль Test Designer (v.2.x).

    Модуль Reverse Engineering обеспечивает построение логической модели данных.

    Модуль DB Designer предназначен для проектирования (v.2.x) и модификации модели базы данных.

    В версии 1.0 поддерживается:
  • модификация базы данных в минимальном объеме, необходимом для эффективной работы приложения (переход от предметных ключей к искусственным, создание UNIQUE CONSTRAINTS для предметных ключей, создание триггеров, поддерживающих политику Nullify, создание служебных таблиц для SuperNova);
  • ведение архива пользовательского DDL.

    В версии 2.х предполагается:
  • навигационный интерфейс, обеспечивающий представление всех объектов базы данных, включая триггера и хранимые процедуры;
  • конструктор логической модели данных;
  • конструктор триггеров и хранимых процедур, основанный на синтаксической декомпозиции DDL, библиотеке шаблонов и языке подстановок.

    Модуль Access обеспечивает:
  • автоматическую генерацию DDL (в версии 1.0 - по шаблонам, в 2.х - генерация DDL для любой из поддерживаемых СУБД по логической модели данных, триггеров и хранимых процедур);


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

    Модуль Tuner обеспечивает:
  • трассировку SQL запросов;
  • фиксацию времени исполнения SQL запросов;
  • проведение исторических тестов (сравнение результатов исполнения SQL запросов с эталоном);
  • ведение архива тестов и результатов их исполнения;
  • генерацию стандартного или задаваемого пользователем структурированного отчета по результатам трассировки;
  • статистическую обработку и графическое представление результатов замеров производительности.

    Модуль App Designer предназначен для построения логической модели приложения и содержит:
  • графический (навигационный) интерфейс ввода информации;
  • генератор текстовых отчетов .

    Кодогенераторы Grindery обеспечивают генерацию исходных кодов приложений на языках Informix- 4GL, NewEra, SuperNova. В состав всех кодогенераторов входят расширенные библиотеки классов (функций). Генератор для SuperNova содержит открытую библиотеку шаблонов.

    Модуль Target Bridge обеспечивает:
  • фиксацию изменений, внесенных пользователем (только для NewEra; для Informix- 4GL и SuperNova эта функция реализована в кодогенераторе);
  • генерацию make-файла;
  • оптимизацию процесса трансляции WIF-файлов (утилита 4GLGEN для NewEra).

    Модуль Test Designer включает :
  • конструктор тестов, основанный на открытой библиотеке шаблонов и языке подстановок;
  • средства контроля полноты тестов, основанные на синтаксическом анализе SQL и логической модели базы данных;
  • генератор тестов на производительность (имитация многопользовательского режима и "клонирование" SQL запросов,
  • графический интерфейс представления теста и его воздействия на объекты базы данных.

    Сценарии использования GRINDERY Grabber

    Наша фирма предлагает следующие сценарии использования GRINDERY Grabber v.1.0
  • при работе над большими проектами (и фирм занимающихся индустриальной разработкой информационных систем) GRINDERY Grabber v.1.0 может использоваться как дополнение к "тяжелому" CASE (при использовании VantageTeam, в силу совместимости формата хранения модели данных, разработка стандарта приложения не требует создания целевой базы данных).


    Такое использование не только позволяет сократить количество дорогих рабочих мест, но и позволяет изменить подход к проектированию базы данных. В CASE достаточно разработать концептуальную модель данных (используя такие составные предметные ключи, ассоциативные объекты, субтипы), а ее приведения к "удобному для СУБД" виду будет сделано автоматически. Кроме того, GRINDERY Grabber позволяет провести быстрое прототипирование приложения, что позволяет провести окончательную верификацию модели данных;
  • при разработке средних систем и решении задач миграции существующих систем в новую среду разработки GRINDERY Grabber может использоваться не только как средство создания конечного приложения, но и как средство сравнительной оценки разных средств разработки (поскольку приложение может быть создано и протестировано в пределах срока демо лицензии);
  • при решении проблем сопровождения плохо документированных систем .

    Дополнения, предусмотренные в GRINDERY Grabber v.2.x позволят использовать его:
  • в качестве инструмента проектирования и отладки серверной части приложения;
  • как инструмент поддерживающий миграцию существующих систем на новую СУБД. При этом поддерживается не только миграция на выбранную СУБД но и ее выбор по результатам сравнительного тестирования;
  • как инструмент тестирования существующих систем. .

    Системы сквозного проектирования

    Системы сквозного проектирования

    Системы сквозного проектирования

    []
    []
    []

    Словарь Данных (Data Dictionary)

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

    Словарь Данных PROGRESS также:


  • позволяет увеличить производительность разработки приложений, за счет
    повторного использования центрально-определяемых описаний объектов;
  • гарантирует, что все Ваши приложения будут иметь предсказуемый
    внешний вид и поведение при использовании ранее определенных объектов;
  • обеспечивает независимость базы данных;
  • снижает стоимость поддержки - приложения сразу же воспринимают и
    отражают все изменения, сделанные в центрально-определяемых описаниях
    объектов. Центральное-хранимые (centrally-stored) описания данных

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

    Словарь Данных обеспечивает поддержку последовательностей (sequences) - полей глобального
    счетчика, который используется для генерации уникальный числовых последовательностей.
    Последовательности генерируют уникальный последовательный идентификатор записи без
    обращения к содержимому собственно записи в таблице. Данная возможность значительно
    повышает производительность, особенно в тех случаях, когда в приложении поддерживаются
    счетчики для большого количества пользователей. PROGRESS v.7 поддерживает расширенный
    список атрибутов объектов данных. Кроме информации о схеме базы данных, Словарь Данных
    также позволяет определить ряд таких атрибутов для объектов данных, как:


  • форматы, которые описывают каким образом поле базы данных будет

    отображено на экране или напечатано на принтере;
  • правила проверки правильности введенных данных и их целостности;
  • сообщения-подсказки;
  • визуализации, которые описывают тип объекта (текстовой блок, радио-
    кнопка и др.), используемый для отображения поля по умолчанию.

    Все средства PROGRESS ADE, а так же PROGRESS 4GL, автоматически наследуют определения
    Словаря Данных при построении новых компонентов программы. Централизованное хранение и
    поддержка определений снижают затраты на построение новых форм, отчетов и процедур.
    Использование централизованного описания объектов к тому же значительно облегчает
    поддержку приложений в дальнейшем, - изменение определения в Data Dictionary будет
    унаследовано всеми компонентами приложений, которые ссылаются на это определение.

    Проверка корректности ввода данных и триггеры базы данных

    Словарь Данных позволяет определить набор правил для проверки вводимых данных и их
    целостности, включая процедуры на 4GL. Эти правила носят название триггеров базы данных.
    Триггеры написаны на PROGRESS 4GL и связаны с определением конкретной таблицы или поля в
    Словаре Данных. PROGRESS автоматически выполняет триггер базы данных всякий раз, когда
    программа обращается к соответствующей таблице или полю. Триггеры используются для
    принудительной проверки корректности ввода данных, обеспечения безопасности и поддержки их
    целостности. В сочетании с другими установками по умолчанию, хранимыми в Словаре Данных,
    применение триггеров существенно снижает затраты сил и времени на разработку приложений,
    именно по причине их центрального хранения вместе с данными.

    Современные CASE-технологии

    А. Вендров, Центральный Банк РФ (Москва)

















    Многие организации-разработчики программного обеспечения информационных систем (ПО ИС), пытаясь внести усовершенствования в процесс разработки, обращаются к CASE-технологии. Согласно обзору передовых технологий (Survey of Advanced Technology), составленному фирмой Systems Development Inc. в 1996 г. по результатам анкетирования более 1000 американских фирм, CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85% завершились успешно). Однако, несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате которых CASE-средства становятся "полочным" ПО (shelfware). В связи с этим необходимо отметить следующее:
  • CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;
  • реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;
  • CASE-средства обеспечивают возможности для получения существенной выгоды только после успешного завершения процесса их внедрения.

    Ввиду разнообразной природы CASE-средств было бы ошибочно делать какие-либо безоговорочные утверждения относительно реального удовлетворения тех или иных ожиданий от их внедрения. Доступная информация о реальных внедрениях крайне ограничена и противоречива. Она зависит от типа средств, характеристик проектов, уровня сопровождения и опыта пользователей. Некоторые аналитики полагают, что реальная выгода от использования некоторых типов CASE-средств может быть получена только после одно- или двухлетнего опыта. Другие полагают, что воздействие может реально проявиться в фазе эксплуатации жизненного цикла ИС, когда технологические улучшения могут привести к снижению эксплуатационных затрат.

    Ключом к успешному внедрению CASE-средств является готовность организации, которая включает следующие аспекты:

  • Технология. Понимание ограниченности существующих возможностей и способность принять новую технологию;
  • Культура. Готовность к внедрению новых процессов и взаимоотношений между разработчиками и пользователями;
  • Управление. Четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения.

    В случае отсутствия готовности по данным аспектам внедрение CASE-средств скорее всего закончится неудачей независимо от степени тщательности следования различным рекомендациям по внедрению.

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

    Несмотря на все высказанные предостережения и некоторый пессимизм, грамотный и разумный подход к использованию CASE-средств может преодолеть все перечисленные трудности. Успешное внедрение CASE-средств должно обеспечить такие выгоды как:
  • высокий уровень технологической поддержки процессов разработки и сопровождения ПО;
  • положительное воздействие на некоторые или все из перечисленных факторов: производительность, качество продукции, соблюдение стандартов, документирование;
  • приемлемый уровень отдачи от инвестиций в CASE-средства. повышение внимания к планированию деятельности, связанной с информационной технологией;
  • улучшение коммуникации между пользователями и разработчиками.

    Технология освоения и внедрения CASE-средств

    Современная технология освоения и внедрения CASE-средств базируется в основном на стандартах-рекомендациях IEEE (IEEE Std 1348-1995. IEEE Recommended Practice for the Adoption of CASE Tools и IEEE Std 1209-1992. IEEE Recommended Practice for the Evaluation and Selection of CASE Tools). Процесс внедрения CASE-средств состоит из следующих этапов:
  • определение потребностей в CASE-средствах;
  • оценка и выбор CASE-средств;
  • выполнение пилотного проекта;
  • практическое внедрение CASE-средств.

    С внедрением CASE- средств обычно связывают большие ожидания. В ряде случаев эти ожидания оказываются нереалистичными и приводят к неудаче при внедрении. К таким ожиданиям можно отнести следующие:
  • понимание проектных спецификаций неподготовленными пользователями;
  • сокращение персонала, связанного с информационной технологией;
  • уменьшение степени участия в проектах высшего руководства и менеджеров, а также экспертов предметной области, уменьшение степени участия пользователей в процессе разработки приложений;
  • немедленное повышение продуктивности деятельности организации;
  • достижение абсолютной полноты и непротиворечивости спецификаций;
  • автоматическая генерация прикладных систем из проектных спецификаций;
  • немедленное снижение затрат, связанных с информационной технологией;
  • снижение затрат на обучение.

    Реализм в оценке ожидаемых затрат имеет особенно важное значение, поскольку он позволяет правильно оценить отдачу от инвестиций. Затраты на внедрение CASE-средств обычно недооцениваются. Среди конкретных статей затрат на внедрение можно выделить следующие:
  • специалисты по планированию внедрения CASE-средств;
  • выбор и установка;
  • учет специфических требований персонала;
  • приобретение CASE-средств и обучение;
  • настройка;
  • подготовка документации, стандартов и процедур использования средств;
  • интеграция с другими средствами и существующими данными;
  • освоение средств разработчиками;
  • технические средства;
  • обновление версий.

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

    Потребности организации в CASE-средствах должны соразмеряться с реальной ситуацией на рынке или собственными возможностями разработки.


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

    Оценка CASE-средств производится для определения их функциональности и качества и последующего выбора. Оценка выполняется в соответствии с конкретными критериями, ее результаты включают как объективные, так и субъективные данные по каждому средству.

    Список CASE-средств - возможных кандидатов формируется из различных источников: обзоров рынка ПО, информации поставщиков, обзоров CASE-средств и других подобных публикаций.

    Оценка и накопление соответствующих данных может выполняться следующими способами:
  • анализ CASE-средств и документации поставщика;
  • опрос реальных пользователей;
  • анализ результатов проектов, использовавших данные CASE-средства;
  • просмотр демонстраций и опрос демонстраторов;
  • выполнение тестовых примеров;
  • применение CASE-средств в пилотных проектах;
  • анализ любых доступных результатов предыдущих оценок.

    Процессы оценки и выбора тесно взаимосвязаны друг с другом. По результатам оценки цели выбора и/или критерии выбора и их веса могут потребовать модификации. В таких случаях может потребоваться повторная оценка. Когда анализируются окончательные результаты оценки и к ним применяются критерии выбора, может быть рекомендовано приобретение CASE-средства или набора CASE-средств. Альтернативой может быть отсутствие адекватных CASE-средств, в этом случае рекомендуется разработать новое CASE-средство, модифицировать существующее или отказаться от внедрения.

    Типичный процесс оценки и/или выбора может использовать набор критериев различных типов.


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

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

    Перед полномасштабным внедрением выбранного CASE-средства в организации выполняется пилотный проект, целью которого является экспериментальная проверка правильности решений, принятых на предыдущих этапах, и подготовка к внедрению.

    Современные CASE-технологии

    Пилотный проект представляет собой первоначальное реальное использование CASE-средства в предназначенной для этого среде и обычно подразумевает более широкий масштаб использования CASE-средства по отношению к тому, который был достигнут во время оценки. Пилотный проект должен обладать многими из характеристик реальных проектов, для которых предназначено данное средство. Он преследует следующие цели:
  • подтвердить достоверность результатов оценки и выбора;
  • определить, действительно ли CASE-средство годится для использования в данной организации, и если да, то определить наиболее подходящую область его применения;
  • собрать информацию, необходимую для разработки плана практического внедрения;


  • приобрести собственный опыт использования CASE-средства.

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

    После того, как CASE-средство выбрано, оно должно быть приобретено, интегрировано в проектную среду и настроено в соответствии с требованиями пилотного проекта. Границы этой деятельности зависят от тех действий, которые имели место в процессе оценки и выбора, а также от степени модификации средства, необходимой для его использования в проекте.

    Может оказаться, что в рамках пилотного проекта средства не оправдали тех ожиданий, которые на них возлагались, или же в пилотном проекте они использовались удовлетворительно, однако опыт показал, что дальнейшие вложения в средства не гарантируют успеха.
    Возможным решением о внедрении должно быть одно из следующих:
  • Внедрить средство. В этом случае рекомендуемый масштаб внедрения должен быть определен в терминах структурных подразделений и предметной области.
  • Выполнить дополнительный пилотный проект. Такой вариант должен рассматриваться только в том случае, если остались конкретные неразрешенные вопросы относительно внедрения CASE-средства в организации. Новый пилотный проект должен быть таким, чтобы ответить на эти вопросы.
  • Отказаться от средства. В этом случае причины отказа от конкретного средства должны быть определены в терминах потребностей организации или критериев, которые остались неудовлетворенными. Перед тем, как продолжить деятельность по внедрению CASE-средств, потребности организации должны быть пересмотрены на предмет своей обоснованности.
  • Отказаться от использования CASE-средств вообще. Пилотный проект может показать, что организация либо не готова к внедрению CASE-средств, либо автоматизация данного аспекта процесса создания и сопровождения ПО не дает никакого эффекта для организации.


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

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

    Характеристика современных CASE-средств

    Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО.

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

    Полный комплекс CASE-средств, обеспечивающий поддержку жизненного цикла ПО, содержит следующие компоненты;
  • репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
  • графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (потоков данных, "сущность-связь" и др.), образующих модели ИС;


  • средства разработки приложений, включая языки 4GL и генераторы кодов;
  • средства конфигурационного управления;
  • средства документирования;
  • средства тестирования;
  • средства управления проектом;
  • средства реинжиниринга.

    Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:
  • применяемым методологиям и моделям систем и БД;
  • степени интегрированности с СУБД;
  • доступным платформам.

    Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:
  • средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF, BPwin);
  • средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder, Designer/2000, Silverrun, PRO-IV, CASE.Аналитик). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
  • средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin, S-Designor и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;
  • средства разработки приложений. К ним относятся средства 4GL (Uniface, JAM, PowerBuilder, Developer/2000, New Era, SQLWindows, Delphi и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;


  • средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose, Object Team).

    Вспомогательные типы включают:
  • средства планирования и управления проектом (SE Companion, Microsoft Project и др.);
  • средства конфигурационного управления (PVCS, SCCS и др.);
  • средства тестирования (Quality Works и др.).

    На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:
  • Vantage Team Builder (Westmount I-CASE);
  • Designer/2000;
  • Silverrun;
  • ERwin+BPwin;
  • S-Designor;
  • CASE.Аналитик;
  • Rational Rose.

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

    CASE-средство Silverrun американской фирмы Сomputer Systems Advisers, Inc. (CSA) используется для анализа и проектирования ИС бизнес-класса и ориентировано в большей степени на спиральную модель ЖЦ. Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моделей (диаграмм потоков данных и диаграмм "сущность-связь").

    Silverrun имеет модульную структуру и состоит из четырех модулей, каждый из которых является самостоятельным продуктом.

    Модуль построения моделей бизнес-процессов в форме диаграмм потоков данных (BPM - Business Process Modeler) позволяет моделировать функционирование обследуемой организации или создаваемой ИС. Модуль концептуального моделирования данных (ERX- Entity-Relationship eXpert) обеспечивает построение моделей данных "сущность-связь", не привязанных к конкретной реализации.


    Модуль реляционного моделирования (RDM - Relational Data Modeler) позволяет создавать детализированные модели "сущность-связь", предназначенные для реализации в реляционной базе данных. Менеджер репозитория рабочей группы (WRM - Workgroup Repository Manager) применяется как словарь данных для хранения общей для всех моделей информации, а также обеспечивает интеграцию модулей Silverrun в единую среду проектирования.

    Платой за высокую гибкость и разнообразие изобразительных средств построения моделей является такой недостаток Silverrun, как отсутствие жесткого взаимного контроля между компонентами различных моделей (например, возможности автоматического распространения изменений между DFD различных уровней декомпозиции). Следует, однако, отметить, что этот недостаток может иметь существенное значение только в случае использования каскадной модели ЖЦ ПО.

    Для автоматической генерации схем баз данных у Silverrun существуют мосты к наиболее распространенным СУБД: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase. Для передачи данных в средства разработки приложений имеются мосты к языкам 4GL: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi. Все мосты позволяют загрузить в Silverrun RDM информацию из каталогов соответствующих СУБД или языков 4GL.

    Система Silverrun реализована на трех платформах - MS Windows, Macintosh и OS/2 Presentation Manager - с возможностью обмена проектными данными между ними.

    Vantage Team Builder представляет собой интегрированный программный продукт, ориентированный на реализацию каскадной модели ЖЦ ПО и поддержку полного ЖЦ ПО.

    Vantage Team Builder обеспечивает выполнение следующих функций:
  • проектирование диаграмм потоков данных, "сущность-связь", структур данных, структурных схем программ и последовательностей экранных форм;
  • проектирование диаграмм архитектуры системы - SAD (проектирование состава и связи вычислительных средств, распределения задач системы между вычислительными средствами, моделирование отношений типа "клиент-сервер", анализ использования менеджеров транзакций и особенностей функционирования систем в реальном времени);


  • генерация кода программ на языке 4GL целевой СУБД с полным обеспечением программной среды и генерация SQL-кода для создания таблиц БД, индексов, ограничений целостности и хранимых процедур;
  • программирование на языке C со встроенным SQL;
  • управление версиями и конфигурацией проекта;
  • многопользовательский доступ к репозиторию проекта;
  • генерация проектной документации по стандартным и индивидуальным шаблонам;
  • экспорт и импорт данных проекта в формате CDIF (CASE Data Interchange Format).

    Vantage Team Builder поставляется в различных конфигурациях в зависимости от используемых СУБД (ORACLE, Informix, Sybase или Ingres) или средств разработки приложений (Uniface). Конфигурация Vantage Team Builder for Uniface отличается от остальных некоторой степенью ориентации на спиральную модель ЖЦ ПО за счет возможностей быстрого прототипирования, предоставляемых Uniface. Для описания проекта ИС используется достаточно большой набор диаграмм. При построении всех типов диаграмм обеспечивается контроль соответствия моделей синтаксису используемых методов, а также соответствия одноименных элементов и их типов на различных типах диаграмм.

    Конфигурация Vantage Team Builder for Uniface обеспечивает совместное использование двух систем в рамках единой технологической среды проектирования, при этом схемы БД (SQL-модели) переносятся в репозиторий Uniface, и, наоборот, прикладные модели, сформированные средствами Uniface, могут быть перенесены в репозиторий Vantage Team Builder. Возможные рассогласования между репозиториями двух систем устраняются с помощью специальной утилиты. Разработка экранных форм в среде Uniface выполняется на базе диаграмм последовательностей форм (FSD) после импорта SQL-модели.

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

    Vantage Team Builder функционирует на всех основных UNIX-платформах (Solaris, SCO UNIX, AIX, HP-UX) и VMS.

    CASE-средство Designer/2000 2. 0 фирмы ORACLE является интегрированным CASE-средством, обеспечивающим в совокупности со средствами разработки приложений Developer/2000 поддержку полного ЖЦ ПО для систем, использующих СУБД ORACLE.

    Designer/2000 представляет собой семейство методологий и поддерживающих их программных продуктов. Базовая методология Designer/2000 (CASE*Method) - структурная методология проектирования систем, охватывающая полностью все этапы жизненного цикла ИС.

    Designer/2000 обеспечивает графический интерфейс при разработке различных моделей (диаграмм) предметной области. В процессе построения моделей информация о них заносится в репозиторий. В состав Designer/2000 входят следующие компоненты:
  • Repository Administrator - средства управления репозиторием (создание и удаление приложений, управление доступом к данным со стороны различных пользователей, экспорт и импорт данных);
  • Repository Object Navigator - средство доступа к репозиторию, обеспечивающие многооконный объектно-ориентированный интерфейс доступа ко всем элементам репозитория;
  • Process Modeller - средство анализа и моделирования деловой деятельности, основывающееся на концепциях реинжиниринга бизнес-процессов (BPR - Business Process Reengineering) и глобальной системы управления качеством (TQM - Total Quality Management);
  • Systems Modeller - набор средств построения функциональных и информационных моделей проектируемой ИС, включающий средства для построения диаграмм "сущность-связь" (Entity Relationship Diagrammer), диаграмм функциональных иерархий (Function Hierarchy Diagrammer), диаграмм потоков данных (Data Flow Diagrammer) и средство анализа и модификации связей объектов репозитория различных типов (Matrix Diagrammer);
  • Systems Designer - набор средств проектирования ИС, включающий средство построения структуры реляционной базы данных (Data Diagrammer), а также средства построения диаграмм, отображающих взаимодействие с данными, иерархию, структуру и логику приложений, реализуемую хранимыми процедурами на языке PL/SQL (Module Data Diagrammer, Module Structure Diagrammer и Module Logic Navigator);


  • Server Generator - генератор описаний объектов БД ORACLE (таблиц, индексов, ключей, последовательностей и т.д.). Помимо продуктов ORACLE, генерация и реинжиниринг БД может выполняться для СУБД Informix, DB/2, Microsoft SQL Server, Sybase, а также для стандарта ANSI SQL DDL и баз данных, доступ к которым реализуется посредством ODBC;
  • Forms Generator (генератор приложений для ORACLE Forms). Генерируемые приложения включают в себя различные экранные формы, средства контроля данных, проверки ограничений целостности и автоматические подсказки. Дальнейшая работа с приложением выполняется в среде Developer/2000;
  • Repository Reports - генератор стандартных отчетов, интегрированный с ORACLE Reports и позволяющий русифицировать отчеты, а также изменять структурное представление информации.

    Генерация приложений, помимо продуктов ORACLE, выполняется также для Visual Basic.

    Designer/2000 можно интегрировать с другими средствами, используя открытый интерфейс приложений API (Application Programming Interface). Кроме того, можно использовать средство ORACLE CASE Exchange для экспорта/импорта объектов репозитория с целью обмена информацией с другими CASE-средствами.

    Среда функционирования Designer/2000 - Windows 3.x, Windows 95, Windows NT.

    ERwin - средство концептуального моделирования БД, использующее методологию IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.) и реинжиниринг существующей БД. ERwin выпускается в нескольких различных конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Версия ERwin/OPEN полностью совместима со средствами разработки приложений PowerBuilder и SQLWindows и позволяет экспортировать описание спроектированной БД непосредственно в репозитории данных средств.

    Для ряда средств разработки приложений (PowerBuilder, SQLWindows, Delphi, Visual Basic) выполняется генерация форм и прототипов приложений.

    Сетевая версия Erwin ModelMart обеспечивает согласованное проектирование БД и приложений в рабочей группе.

    BPwin - средство функционального моделирования, реализующее методологию IDEF0.

    S-Designor 4.2 представляет собой CASE-средство для проектирования реляционных баз данных. По своим функциональным возможностям и стоимости он близок к CASE-средству Erwin, отличаясь внешне используемой на диаграммах нотацией. S-Designor реализует стандартную методологию моделирования данных и генерирует описание БД для таких СУБД, как ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server и др. Для существующих систем выполняется реинжиниринг БД.

    S-Designor совместим с рядом средств разработки приложений (PowerBuilder, Uniface, TeamWindows и др.) и позволяет экспортировать описание БД в репозитории данных средств. Для PowerBuilder выполняется прямая генерация шаблонов приложений.

    CASE.Аналитик 1.1 является практически единственным в настоящее время конкурентоспособным отечественным CASE-средством функционального моделирования и реализует построение диаграмм потоков данных в соответствии с методологией, описанной в подразделе 2.3. Его основные функции:
  • построение и редактирование DFD;
  • анализ диаграмм и проектных спецификаций на полноту и непротиворечивость;
  • получение разнообразных отчетов по проекту;
  • генерация макетов документов в соответствии с требованиями ГОСТ 19.ХХХ и 34.ХХХ.

    Среда функционирования: процессор - 386 и выше, основная память - 4 Мб, дисковая память - 5 Мб, MS Windows 3.x или Windows 95.

    С помощью отдельного программного продукта (Catherine) выполняется обмен данными с CASE-средством Erwin. При этом из проекта, выполненного в CASE.Аналитике, экспортируется описание структур данных и накопителей данных, которое по определенным правилам формирует описание сущностей и их атрибутов.

    Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации.


    Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML - Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант - Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

    В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций, определяющих логическую и физическую структуры модели, ее статические и динамические аспекты. В их число входят диаграммы классов, состояний, сценариев, модулей, процессов.

    В составе Rational Rose можно выделить 6 основных структурных компонент: репозиторий, графический интерфейс пользователя, средства просмотра проекта (browser), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для С++, обеспечивающий реинжиниринг - восстановление модели проекта по исходным текстам программ.

    Rational Rose интегрируется со средством PVCS для организации групповой работы и управления проектом и со средством SoDA - для документирования проектов. Интеграция Rational Rose и SoDA обеспечивается средствами SoDA.

    Rational Rose функционирует на различных платформах: IBM PC (в среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX).

    Сравнительная характеристика CASE-средств

    В заключение приведем сравнительную характеристику CASE-средств по некоторым основным критериям, приведенным выше.


    Здесь хотелось бы еще раз отметить нецелесообразность сравнения отдельно взятых CASE-средств, поскольку ни одно из них не решает в целом все проблемы создания и сопровождения ПО. Это подтверждается также полным набором критериев оценки и выбора, которые затрагивают все этапы ЖЦ ПО. Сравниваться могут комплексы методологически и технологически согласованных инструментальных средств, поддерживающие полный ЖЦ ПО и обеспеченные необходимой технической и методической поддержкой со стороны фирм-поставщиков. По мнению автора, на сегодняшний день наиболее развитым из всех поставляемых в России комплексов такого рода является комплекс технологий и инструментальных средств создания ИС, поддерживаемый фирмой "Аргуссофт Компани". В его основе лежит методология и технология DATARUN фирмы CSA. В состав комплекса входят следующие инструментальные средства:
  • CASE-средство Silverrun;
  • средство разработки приложений JAM;
  • мост Silverrun-RDM JAM;
  • комплекс средств тестирования QA;
  • менеджер транзакций Tuxedo;
  • комплекс средств планирования и управления проектом SE Companion;
  • комплекс средств конфигурационного управления PVCS;
  • объектно-ориентированное CASE-средство Rational Rose;
  • средство документирования SoDA.

    Примерами других подобных комплексов являются:
  • Vantage Team Builder for Uniface + Uniface (фирмы "DataX/Florin" и "ЛАНИТ");
  • комплекс средств, поставляемых и используемых фирмой "ФОРС":

    - CASE-средства Designer/2000 (основное), ERwin, Bpwin и Oowin (альтернативные);

    - средства разработки приложений Developer/2000, ORACLE Power Objects (основные) и Usoft Developer (альтернативное);

    - средство настройки и оптимизации ExplainSQL (Platinum);

    - cредства администрирования и сопровождения SQLWatch, DBVision, SQL Spy, TSReorg и др. (Platinum);

    - средство документирования ORACLE Book.

  • комплекс средств на основе продуктов фирмы CENTURA:

    - CASE-средства ERwin, Bpwin и Oowin (объектно-ориентированный анализ);

    - средства разработки приложений SQLWindows и TeamWindows;

    - средство тестирования и оптимизации приложений "клиент-сервер" SQLBench (ARC);

    - cредства эксплуатации и сопровождения Quest и Crystal Reports.

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

    Обеспечение целостности проекта и контроля за его состоянием

    Наилучшими показателями по данному критерию обладают комплексы Vantage Team Builder for Uniface + Uniface и комплекс "ФОРС". Это достигается за счет развитых средств контроля проектных спецификаций и высокой степени интегрированности отдельных средств, входящих в комплексы. В остальных вариантах недостаток возможностей самих средств может компенсироваться организационными мерами.

    Независимость от платформы и СУБД

    Наибольшей степенью независимости обладает комплекс "Аргуссофт Компани", поскольку его средства в принципе не ориентированы ни на какую конкретную платформу. Достаточно высокой степенью независимости обладает также комплекс Vantage Team Builder for Uniface + Uniface, остальные комплексы достаточно жестко ориентированы на конкретные СУБД (ORACLE и SQLBase).

    Открытая архитектура

    Наибольшей степенью открытости и количеством интерфейсов с продуктами других фирм также обладают комплексы "Аргуссофт Компани" и Vantage Team Builder for Uniface + Uniface.

    Качество технической поддержки

    Данный критерий является скорее оценкой работы конкретной фирмы-поставщика, чем комплекса инструментальных средств. На сегодняшний день наилучший уровень технической и методической поддержки поставляемых средств и обучения их использованию имеет фирма "Аргуссофт Компани".

    Простота освоения и использования

    Наилучшие показатели по данному критерию у комплекса "Аргуссофт Компани" и комплекса средств на основе продуктов фирмы CENTURA. Остальные комплексы достаточно сложны в освоении и трудоемки в использовании.

    Приведенная выше сравнительная характеристика комплексов средств позволяет сделать следующие выводы относительно наиболее целесообразных областей их применения:


  • крупные многоплатформенные проекты, ориентированные на спиральную модель ЖЦ: комплекс средств, поставляемых фирмой "Аргуссофт Компани";
  • крупные многоплатформенные проекты, ориентированные на каскадную модель ЖЦ: комплекс Vantage Team Builder for Uniface + Uniface;
  • крупные проекты, ориентированные на использование СУБД ORACLE: комплекс "ФОРС" - средства фирмы ORACLE;
  • средние и небольшие проекты: комплекс "Аргуссофт Компани" и комплексы, включающие локальные CASE-средства (ERwin, BPwin, S-Designor, CASE.Аналитик) в сочетании со средствами быстрой разработки приложений (PowerBuilder, Delphi, SQLWindows и др.);
  • проекты, использующие объектно-ориентированный подход: комплекс "Аргуссофт Компани" (при этом в качестве CASE-средства следует использовать Rational Rose, а в качестве средств разработки приложений одно из тех средств, с которыми взаимодействует Rational Rose.

    []
    []
    []

    Современные приложения и их требования к СУБД

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

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

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

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


    Создание и управление базой данных

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

    Художник манипулирования данными(Data Manipulation Painter) позволяет предварительно
    просматривать существующие данные, заполнять новые таблицы, а также тестировать форматы
    изображений, правила проверки и стили редактирования на реальных данных.

    Драйвера для доступа к различным серверам баз данных позволяют организовать связь PowerBuilder с
    базой данных как на этапе разработки, так и на этапе эксплуатации приложения, что дает
    возможность использовать все специфические особенности каждой базы данных, включая хранимые
    процедуры, триггеры, прокручиваемые курсоры, правила проверки ссылочной целостности и т.д. для
    баз данных, которые предоставляют эти возможности.


    Создание интерфейсов для АЦ-терминалов

    Соблюдая ряд правил, при помощи генератора окон можно создавать универсальные оконные
    интерфейсы для приложений. В число стандартных библиотек NewEra входят две библиотеки
    оконных и визуальных классов - для графических и для АЦ-терминалов. Таким образом, из одного
    и того же исходного кода можно, используя при сборке ту или другую библиотеку, создать два
    эквивалентных приложения, рассчитанных на разные типы мониторов.


    Создание приложений в Informix-ViewPoint Pro

    Informix-ViewPoint Pro - это также инструмент для построения простейших приложений без какого
    бы то ни было программирования. Приложения, создаваемые в ViewPoint Pro, состоят из окон 3-х
    типов:

  • простые окна (screen) - служат для вызова других окон, выполняют
    управляющие функции в приложении;
  • окна с формами (form) - содержат формы для ввода или просмотра
    информации из базы данных;
  • окна с отчетами (report) - содержат отчеты.
    Все типы окон могут содержать графические декоративные элементы, а также параметризуемые
    командные кнопки из фиксированного набора: Open(открыть окно), Goto (перейти в
    другое окно), Close (закрыть окно), Retrieve (выполнить выборку) и т. п.


    Создание приложений

    Из модели базы данных генерируется код для ее создания на сервере. Программируются системные
    процессы. При этом возможно разнесение процессов по узлам распределенной системы (часть процессов
    реализуется как хранимые процедуры на сервере, часть как сервисы монитора транзакций, часть - как
    программы клиентской части). Интерфейс приложений (обычно составляющий до 70-80% всей системы)
    может быть быстро создан перенесением соответствующей ему подсхемы базы данных в среду языка 4-го
    поколения).


    Создание приложения в среде PowerBuilder

    Возможности Художника баз данных (DataBase Painter) обеспечивают тесную интеграцию с
    широким спектром поддерживаемых баз данных с полным использованием специфических
    особенностей каждой из них. PowerBuilder позволяет разработчикам создавать приложения с
    прозрачным доступом и обновлением множественных источников данных.

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


    Шаг
    Процедура
    Используемые инструменты
    1
    		Создание объекта приложения Художник приложений(Application Painter)
    2
    		Проектирование графического интерфейса пользователя Художники окон, меню и объектов пользователя (Window, Menu and User Object Painters)
    3
    		Определение поведения объектов Художник PowerScript (PowerScript Painter)
    4
    		Определение режимов работы с данными Художник Окна данных(DataWindow Painter)
    5
    		Генерация отчетов Художник отчетов (Report Painter)
    6
    		Добавление подсказок в приложение Функции PowerScript
    7
    		Управление приложением Художник библиотек (Library Painter)
    8
    		Отладка приложения Отладчик (Debugger)
    9
    		Поставка завершенного приложения Художник приложений (Application
    Painter, Project Painter)


    Список литературы

  • Кодд Е.Ф. Реляционная модель данных для больших совместно используемых банков
    данных. СУБД № 1, 1995.
  • Chen P.P. The Entity-Relationship Model: Toward a Unified View of Data. ACM Transactions on
    Database Systems, vol.1., № 1, 1976.
  • Горин С.В., Тандоев А.Ю. Применение CASE-средства ERwin 2.1 для информационного
    моделирования в системах обработки данных. СУБД, N 3, 1995.
  • Горин С.В., Тандоев А.Ю. Среда разработки приложений PowerBuilder. DBMS/Russian Edition,
    № 1, 1995.

    Александр Науменко

    AlconsSoft

    tel: +7 (095) 362-5138, 918-1380

    e-mail:

    []
    []
    []

    Справка (Help)

    PowerBuilder снабжен подробной контекстно-зависимой оперативной подсказкой (Online Help),
    предоставляющей информацию из справочных руководств по PowerBuilder.


    это новое название для пятой

    Sybase SQL Anywhere - это новое название для пятой версии Watcom SQL. Это название отражает
    как интеграцию продукта в архитектуру Sybase System 11 (рис.4), так и появление мощных средств
    обеспечения работы удаленных пользователей и обмена данными. С объединением компаний
    Sybase и Powersoft в феврале 1995 года фирма Watcom вошла в состав Sybase, Inc.

    Основной диалект SQL, поддерживаемый SQL Anywhere, называется Watcom SQL. Среди новых
    качеств продукта - совместимость с Transact-SQL (версия SQL в линии продуктов Sybase).

    Диалект Watcom SQL содержит все конструкции, характерные для "больших" СУБД
    (декларативная ссылочная целостность, процедуры, триггеры) и соответствует стандарту ANSI
    SQL92. Сервер ведет журнал транзакций. Имеется одинаковый по функциональности сетевой
    сервер и "локальный" вариант, который может запускаться на одном компьютере с приложением-
    клиентом. Для приложения все равно, обращается ли оно к локальному или сетевому
    варианту.

    SQL Anywhere работает на платформах Windows 3.x, Windows NT и Windows 95 (32-разрядный),
    OS/2, DOS, Novell NetWare и QNX. В каждой из этих сред SQL Anywhere максимально
    интегрирован. Среди поддерживаемых сетевых протоколов - TCP/IP, Named Pipes, IPX/SPX.

    Приложения-клиенты могут разрабатываться с использованием ODBC, Embedded SQL и
    собственного интерфейса Watcom HLI (рис.11). Имеется собственный DDE-сервер для интеграции,
    например, с Excel, Word или Visual Basic.

    это новое название для пятой

    SQL Enterprise Manager

    Как уже говорилось ранее, SQL Server имеет развитый графический административный интерфейс
    - SQL Enterprise Manager, - способный обеспечить потребности администратора в
    централизованном управлении многими серверами в организации. Административная консоль
    использует объекты SQL-DMO для управления всеми аспектами функционирования SQL Server. В
    задачи администратора входит администрирование топологии, защиты, событий/предупреждений,
    диспетчирование, создание страховочных копий баз данных, конфигурирование и настройка
    серверов и тиражирования. SQL Enterprise Manager может также использоваться для создания,
    модификации и копирования схем баз данных и таких объектов, как образы и триггеры. Этот
    инструмент позволяет охватить всю топологию системы из любого места в сети.

    Архитектура SQL-DMF предлагает множество "точек входа" для поддержания конкретных
    потребностей администратора. В результате серверы могут управляться посредством доступа к
    объектам SQL-DMO или непосредственно. Мы полагаем, что подобная архитектура создает
    гибкую среду администрирования, удовлетворяющую требованиям администраторов как мелких,
    так и крупных систем, без необходимости принесения в жертву простоты или
    мощности.

    SQL Enterprise Manager

    SQL Executive

    Основой SQL-DMF является SQL Executive, исполняемый как сервис операционной системы и
    управляющий тиражированием, обработкой событий, предупреждений и диспетчированием
    работы компонентов внутри SQL-DMF. SQL Executive работает как "скрытый" оператор или
    "интеллектуальный агент", автоматически и постоянно отслеживающий состояние окружения
    сервера и любых распределенных служб SQL Server. Разработчики сервера убеждены, что
    критические службы, такие как тиражирование, должны быть частью основного продукта, а не
    просто "утилитами".


    SQL Enterprize ManagerOLE AutomationSQL Server Distributed Manadgement Object (SQL-DMO)SQL ExecutiveSQL Server
    SQL ExecutiveSQL Executive
    SQL ExecutiveSQL Executive

  • Тиражирование
  • Менеджер задач
  • Менеджер событий
  • Менеджер уведомлений



    • SQL Server 11 - современная реляционная СУБД

    Создание Sybase SQL Server 11 основывается на многолетнем опыте работы предыдущих версий во
    всем мире и содержит целый ряд новых возможностей.


  • Масштабируемость, высокая производительность и эффективность SQL Server 11
    основывается на проверенной технологии:
  • SQL Server 11 работает на множестве платформ, от персональных компьютеров до
    многопроцессорных суперсерверов;
  • обеспечена очень высокая производительность на каждой платформе благодаря тесному
    взаимодействию с производителями аппаратуры и оптимизации характеристик;
  • полностью симметричная многопоточная СУБД достигает высокой пропускной
    способности и поддерживает большое количество пользователей.
  • SQL Server обеспечивает надежность и целостность данных:
  • SQL Server содержит механизмы триггеров и процедур, декларативной ссылочной
    целостности, транзакций и т.д.;
  • СУБД соответствует уровню безопасности C2 NCSA (National Computer Security
    Council).
  • Доступность данных повышает производительность систем:
  • Sybase SQL Server программно поддерживает зеркальный журнал и зеркальную базу
    данных;
  • высокоскоростные средства загрузки/восстановления минимизируют влияние этих
    операций на работу системы.
  • Открытость и соответствие стандартам:
  • SQL Server соответствует стандартам ANSI/ISO SQL-89 и entry-level ANSI/ISO SQL-92;
  • поддерживаются приложения в стандарте ODBC и X/Open XA;
  • SQL Server может использовать различные сетевые протоколы, что позволяет соединить
    клиента и сервер практически на каждой платформе.
  • Легкость управления и поддержки:
  • наличие продуманной многопоточной архитектуры означает, что на компьютере
    запускается и требует управления только один процесс - СУБД;
  • для симметричной мультипроцессорной обработки можно конфигурировать количество
    процессоров, распределенных для СУБД;
  • имеется полный набор продуктов для конфигурирования областей памяти,
    пользователей, контроля доступа и производительности - от одной базы данных до множества
    сетей в масштабах предприятия.\

    Остановимся на важных особенностях SQL Server 11.


    SQL Server Distributed Management Objects (DMO)

    Другим исключительно важным компонентом являются SQL Server Distributed Management Objects
    (SQL-DMO). SQL-DMO - OLE Automation интерфейс SQL Server 6.0 открывает объекты, свойства
    и методы для всех аспектов деятельности SQL Server по управлению и администрированию SQL
    Server. Объектная модель SQL Server включает более 70 индивидуальных объектов и свыше 1500
    свойств и методов. Организация объектов значительно упрощает изучение и продуктивное
    использование компонентов административного интерфейса SQL Server.

    OLE интерфейс поддерживает использование таких средств разработчика, как Visual C++, Visual
    Basic и Visual FoxPro для создания специализированных административных сценариев, исполнение
    которых организуется средствами диспетчирования SQL Executive. Справа приведены некоторые
    из объектов и методов SQL-DMO.

    Все функции SQL Server открыты для доступа извне как объекты, свойства и методы. Подобная
    модель значительно упрощает работу с административным "слоем" за счет организации функций
    управления в терминах объектной модели SQL Server. Основной объект - "SQL Server" - включает
    коллекцию объектов "Databases". Объект "Database" включает коллекции объектов "Table",
    "View" и "StoredProcedure". Объекты имеют свойства (например, SQLServer.Name =
    "SABERTOOTH") и методы (SQLServer.Start или SQLServer.Stop). Свойства и методы
    используются для управления SQL Server.

    Метод объекта
    		Действие
    SQLServer.Stop
    		Останавливает SQL Server
    SQLServer.Start
    		Запускает SQL Server
    Database.Backup
    		Выполняет создание страховочной копии
    Index.UpdateStatistics
    		Обновляет информацию оптимизатора по индексам
    Database.Table.AddДобавляет таблицу к базе данных


    Среда разработки приложений на PROGRESS

    PROGRESS Application Development Environment (далее ADE) - это функционально полный,
    интегрированный набор инструментальных средств, позволяющих создавать и применять
    высокопроизводительные приложения для широкого диапазона программно-аппаратных
    платформ. С помощью ADE Вы можете создавать все необходимые компоненты приложений - от
    графических и алфавитно-цифровых интерфейсов до сложных логических и пакетных процессов,
    от отчетов до средств интеграции с внешними программными оболочками. Программирование на
    PROGRESS предполагает использование современных подходов к разработке приложений, таких
    как: структурированный, объектно-событийный и объектно-ориентированные подходы.

    Среда разработки приложений PROGRESS ADE состоит из следующих компонентов:


  • Построителя Интерфейса Пользователя (User Interface Builder)
  • Словаря Данных (Data Dictionary)
  • Редактора Процедур (Procedure Editor)
  • Генератора Отчетов (Report Builder)
  • Языка программирования четвертого поколения 4GL (Fourth-Generation
    Language)
  • Отладчика Приложений (Application Debugger)
  • On-Line Справочника(On-Line Help)
  • Менеджера Переводов (Translation Manager)
  • Утилиты Results (PROGRESS Results)
  • Средств Оптимизации Качества (Performance Profilers)
  • Администратора Базы Данных (Database Administration)
  • Утилиты ToolKit


    Средства генерации отчетов

    S-Designor, как и большинство аналогичных средств такого класса позволяет готовить
    отчеты по структуре данных модели. Цель подготовки отчетов - документирование разработанной
    модели данных. Можно создать любое количество стилей отчетов и после этого генерировать отчеты
    согласно выбранному стилю. Пример использования различных стилей - краткий и полный отчеты по
    модели. Подготовленный отчет можно напечатать или сохранить в формате, например, текстового
    процессора Microsoft Word. Впоследствии, отчет можно отредактировать средствами
    Microsoft Word. В отчет может быть включено графическое изображение модели данных,
    расположенной как на отдельных страницах, так и смасштабированной так, чтобы вся модель
    размещалась на одной странице. Отчет можно произвольным образом настраивать. Например,
    включать или исключать различные элементы отчетов, автоматическое формирование оглавления,
    переопределять содержимое заголовка и подвала страницы.

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


    с центральным словарем. После этого

    файле.

    Начало работы с централизованным словарем - это создание словаря администратором и регистрация
    пользователей, которые будут работать с центральным словарем. После этого администратор создает
    первый проект - только он имеет право это делать и назначает пользователям полномочия доступа к
    моделям и подмоделям данных.

    Права доступа делятся на следующие группы:
    ADMI
    -     		пользователи данной группы могут выполнять
    любые действия со словарем и с хранимыми в нем моделями.
    Upgrade
    -     		пользователи данной группы могут оперировать со
    своими моделями и подмоделями с атрибутом Public.
    Read-only
    -     		пользователи данной группы могут только читать
    информацию из словаря.
    Lock
    -     		пользователи данной группы в данный момент не
    имеют никаких полномочий.
    Структура проекта следующая: проект (project) - модель (model: концептуальная
    и/или физическая) - подмодель (sub-model). Для создания проекта в словаре администратор выполняет
    консолидацию модели в режиме Create (Рис.6).

    с центральным словарем. После этого

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

    При разработке крупных корпоративных систем особое значение приобретает организация групповой
    разработки общей модели данных. При этом, каждый разработчик разрабатывает "свою" часть
    общей модели. Для обеспечения эффективности такой работы необходимо хранение модели данных в
    месте, доступном для каждого разработчика, и механизмы, поддерживающие актуализацию модели,
    оперативное внесение изменений и контроль доступа к модели данных. S-Designor обеспечивает все
    необходимые для этого возможности.

    Принцип организации коллективной разработки в S-Designor - использование
    централизованного словаря метабазы, который хранит модели данных, и обеспечение доступа к нему.
    Для организации работы со словарем и управления коллективной разработкой предназначена
    отдельная компонента - S-Designor Dictionary. Компонента служит для создания и
    администрирования централизованного словаря.

    Словарь метабазы - это ряд таблиц, которые создаются на SQL-сервере из среды S-Designor
    Dictionary. Технология работы с централизованным словарем метабазы построена на двух
    ключевых понятиях: Consolidation (консолидация/слияние модели с моделью в словаре) и Extraction
    (операция извлечения модели данных из словаря).

    Перед тем, как внести изменения в модель данных необходимо выполнить операцию Extraction. По
    этой операции модель данных либо извлекается из словаря и загружается в S-Designor, либо
    сохраняется в файл. По операции Consolidation выполняется консолидация метаданных измененной
    модели с метаданными в словаре. Так вносятся изменения в модель в словаре.

    Консолидировать можно всю модель целиком и отдельные подмодели. Консолидация выполняется по
    следующим правилам. Сначала проверяются полномочия выполняющего операцию консолидации.
    При конфликтных ситуациях, например, если после последней операции Extraction объект модели был
    изменен - S-Designor предлагает вариант принятия решения. После консолидации можно
    сразу выполнить операцию Extraction для того, чтобы получить гарантированно актуальную модель в

    Средства Оптимизации Качества (Performance Profilers)

    Среда разработки приложений PROGRESS ADE включает в себя две утилиты, называемые
    Средствами Оптимизации Качества и предназначенные для настройки параметров среды в
    приложениях и базах данных PROGRESS с целью максимального увеличения общей
    производительности.

    Средство Оптимизации Качества Приложения Позволяет пользователю собирать и измерять
    статистическую информацию, касающуюся качества PROGRESS процедур. Разработчики могут
    оценить, как много времени требуется для выполнения каждой компоненты, и каким будет
    изменение качества работы приложения в зависимости от внесенных изменений.

    Средство Оптимизации Качества Базы Данных

    Средство Оптимизации Качества Базы Данных отслеживает и измеряет интенсивность обращений
    к базе, использование ресурсов и состояние базы данных PROGRESS. На основе информации,
    полученной от данного оптимизатора, разработчики и администраторы могут точнее настроить
    базу данных для получения оптимального качества приложения.



    Средства проектирования представлений (View)

    При разработке информационных систем со сложной структурой данных эффективно использовать
    представления (View). Цель создания представлений - структурировать и в итоге упростить
    построение сложных запросов к базе данных.

    Эффективность средств проектирования представлений заключается в том, что для разного уровня
    сложности представлений в S-Designor можно использовать наиболее подходящие для этого
    конструкторы. Для быстрого проектирования наиболее простых представлений, например
    эквисоединения двух таблиц, достаточно, выделив необходимые таблицы, выполнить команду
    "построить представление". Для более сложных представлений можно использовать графический
    конструктор запросов (аналогичный конструктору в PowerBuilder ).
    И, наконец, при необходимости можно использовать конструктор для создания представления на
    языке SQL.


    Средства разработки Oracle как

    Л. Сорокин, Oracle











    Средства разработки Oracle

    Корпорация Oracle предлагает целый ряд средств разработки, которые позволяют создавать надежные, работающие приложения, способные пережит не одну смену компьютерных технологий, аппаратно-программных платформ и групп разработчиков.

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

  • Designer/2000     - Средство описания разрабатываемой системы в виде всеохватывающей модели и генерации на ее основе законченных приложений для различных средств разработки.

  • Developer/2000 - Многоплатформленное и масштабируемое средство визуального создания промышленных приложений, легко настраиваемых в зависимости от мощности сервера и клиентских компьютеров и переносимых на работу в среду Internet/Intranet.

  • Power Objects - Инструмент для разработки приложений небольшого масштаба, способного работать с разнообразными источниками данных.
  • Programmer/2000 - Набор предкомпиляторов
    для C/C+, заметно упрощающих создание приложений на C/C+ для сервера Oracle7.

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

    Необходимо отметить, что в отличие от "универсальных" средств разработок, ориентированных на работу с любыми СУБД (Delphi, Visual Basic, PowerBuilder), "родные" инструменты полностью используют все возможности сервера Oracle7. А именно, поддержка последовательностей и синонимов, работа с механизмом обеспечения секретности на сервере, доступ к хранимым на сервере процедурам и переменным, управление оптимизатором выполнения SQL-команд - использование этих возможностей либо невозможно в универсальных средствах разработок, либо требует большого труда при кодировании.

    Инструменты сквозного проектирования и разработки приложений

    На этапе предварительного обследования деятельности предприятия (той деятельности, которую необходимо автоматизировать) используется компонента Designer/2000 - средство построения диаграмм деловых процессов BPR (Business Process Modeler).
    С его помощь возможно не только построить модель всех процессов, протекающих в ходе повседневной деятельности организации (предприятия), но и произвести ряд анализов, способных выявить узкие места. Даже без последующего создания приложения, такая модель позволяет лучше понять как протекает деятельность организации и найти пути по ее улучшению.

    На следующем этапе строится концептуальная модель будущего приложения с помощью ряда стандартных диаграмм - диаграмм Сущность-Связь, Иерархий Функций и Потоков Данных. Эта концептуальная модель подробно детализируется, расписывается ее "проекция" на средства разработки и характеристики будущего приложения. Диаграммы концептуальной модели достаточно просты для понимания, и на этапе моделирования достаточно легко наладить обратную связь с заказчиком, для достижения полного взаимопонимания в постановке задачи.

    Процесс создания модели предполагает коллективную работу над проектом. Существуют мощные средства организации такой работы, разделения модели на части для независимой разработки и "сшивания" частей модели в целое.

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

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

    Генерация для клиентской части возможно для целого ряда различных средств разработок. Сейчас поддерживаются :

  • Oracle Developer/2000


  • Oracle Power Objects
  • Oracle WebServer
  • MS Visual Basic 3.0 и 4.0
  • Классы C/C+

    Этот список с течением времени постоянно расширяется. Необходимы минимальные изменения в настройке модели приложения, что бы произвести генерацию приложения для другого средства разработки. Таким образом обеспечивается независимость приложения от:

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

    Важной особенностью является возможность восстановить модель приложения по уже существующему приложению, созданного без применения Designer/2000, с помощью процедуры реинжиниринга. Так же и вручную сделанные изменения в сгенерированной системе можно отразить в модели приложения и при последующей генерации они не будут потеряны.

    Таким образом, с помощью Designer/2000 осуществляется инженерный подход к созданию промышленных приложений, позволяющий гарантированно создавать работающие, надежные приложения с требуемой функциональностью, независимые от средств разработки и аппаратно-программной платформы.

    Обеспечение независимости от смены платформ и технологий

    Другой иллюстрацией подхода корпорации Oracle к обеспечению создания независимых от платформы приложений является Developer/2000. Это инструментарий визуального проектирования клиентских приложений для технологии Клиент-сервер. Developer/2000 полностью переносим на все используемые ныне платформы, начиная от символьных терминалов и кончая графическими средами вроде Windows или Motif.


    Если при разработке не использовались платформенно зависимые особенности (например компоненты OCX/ActivX для Windows), то перенос приложения на другую платформу не требует никакого кодирования!
    Рост популярности приложений для Internet/Intranet вызвал необходимость для разработчиков изучения как новых технологий, так и новых сред разработки для Web. Перенос приложения в среду Internet/Intranet означал практически полностью его переписывание на новом средстве разработки. Поэтому многие фирмы-производители инструментальных средств поддержали технологию Netscape Plug-In, которая позволяла определенным способом распространять и вызывать приложения через Web, не сильно их переделывая. Но на самом деле, это только временное решение, т.к. для выполнения приложения необходимо держать на клиентском компьютере полностью Run-Time среду, а само приложение целиком закачивается с Web-сервера.

    Применение Developer/2000 позволяет перенести прикладную систему в среду Internet/Intranet более элегантным способом. Существует возможность разместить Run-Time среду Developer/2000 на Web-сервере, а откомпилированное приложение передается ей безо всякой модификации. Специальный кэтридж Web Developer'а формирует на лету Java Applets, которые передаются на клиентский компьютер в любую программу просмотра Web. Пользователь видит перед собой тот же пользовательский интерфейс, как если бы приложение выполнялось на его компьютере, а работать может даже на DOS-компьютере с 640 КБ памяти!

    Таким образом, наряду с мощными возможностями по созданию полнофункциональных клиентских приложений с богатым пользовательским интерфейсом, Developer/2000 позволяет легко переносить созданные системы на любые существующие ныне платформы и использовать самые передовые технологии не переписывая ни строчки кода!

    Поддержка разработчиков

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


    В их числе:

  • Соответствующая международным стандартам техническая поддержка продуктов Oracle, функционирующая на территории СНГ.
  • Возможность ознакомления с пробными (trial) версиями продуктов Oracle, прежде чем принять решения об их закупке и затем возможность предварительного ознакомления с новыми версиями продуктов.
  • Два периодических русскоязычных журнала ("Мир Oracle" и "Oracle Magazine - Русское издание"), посвященных продуктам Oracle, содержащих большое число статей для разработчиков.
  • Действующие группы пользователей Oracle, периодические семинары.
  • Большой выбор учебных курсов по продуктам Oracle, как и в представительстве корпорации Oracle в СНГ, так и у его партнеров.

    Все это позволяет разработчикам иметь доступ к самым передовым технологиям Oracle, максимально эффективно использовать продукты корпорации.

    Заключение

    Средства разработки Oracle позволяют реализовать инженерный подход к разработке сложных промышленных приложений, направленный не только на получение быстрого первоначального результата, но и на обеспечение долгого жизненного цикла созданного приложения, простоты его развития и миграции на новые платформы. Использование инструментов Oracle не только позволяет полностью воспользоваться всей мощью сервера Oracle7, но и обеспечить:

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

    []
    []
    []

    Стратегическая система моделей организации.

    Процесс создания и развития систем согласованных моделей, описывающих деятельность
    организации, начинается с построения стратегической системы моделей организации, которая
    описывает основные аспекты деятельности организации на стратегическом уровне. Главное
    назначение стратегической системы моделей заключается, во-первых, в определении основных
    целей и задач организации, и во-вторых, в формировании моделей бизнес-процессов,
    описывающих основные виды деятельности организации и реализующих ее стратегические цели и
    задачи.

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

    Модели, входящие в стратегическую систему моделей, строятся при обследовании организации
    путем опроса экспертов на уровне высшего руководящего персонала, определяющего стратегию
    организации, а также на базе основных документов организации. Эти модели хранятся в
    репозитории проекта.

    Все создаваемые далее модели организации строятся на базе построенных бизнес-процессов по
    результатам обследования деятельности организации, проводимого на уровне подразделений.
    Модели строятся с помощью CASE-средств, и сохраняются в репозитории проекта. Построение
    этих моделей допускает распараллеливание работ при проведении обследования и при
    построении моделей.

    Дальнейшее развитие систем согласованных моделей происходит на базе схемы преобразования
    моделей, представленной на рис.3, которая описывает развитие согласованных моделей по
    основным аспектам, определяющим деятельность организации (данные, функции, люди, сеть,
    время, правила).

    Стратегия IBM в области инструментальных средств разработки приложений

    Игорь Ларин, IBM
    Требования, предъявляемые современными условиями к инструментальным средствам разработки
    приложений.

    Моделирование и проектирование бизнес-процессов и структур данных.

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

    Средства управления командной разработкой программного обеспечения.

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

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

    Для определения и спецификации бизнес-процессов будущего приложения предназначен инструмент IBM
    Business Requirements Tool. Этот продукт предназначен для системных аналитиков, проектировщиков

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

    Следующий этап разработки - моделирование данных. Инструменты IBM моделирования данных
    предоставляет возможность определения и отображения деловой информации в виде концептуальных
    моделей, независимых от конкретной реализации базы данных. Концептуальные модели определяются на
    основе метода Чена моделирования связей сущностей. Эта модель делает возможным проектирование
    конечным пользователем структуры данных будущего приложения. Как только проектирование
    завершено, в дело вступает программа-генератор модели данных. Она увязывает концептуальные модели
    с логическими структурами, специфическими для конкретной базы данных. Программа генератор модели
    данных - имеет графический редактор, позволяющий описывать сущности, связи и атрибуты, и
    включающий средства преобразования концептуальных моделей в логические(реляционные) и наоборот,
    логические в концептуальные. Далее, продукт DataAtlas берет на себя контроль и стандартизацию
    спецификаций реляционных баз данных.

    Стратегия IBM в области инструментальных средств разработки приложений
    После определения логической и физической структуры данных, а также дизайна будущего приложения
    разработчики могут приступать непосредственно к программированию. И здесь IBM предлагает самый
    широкий выбор возможных инструментов. Для разработки можно выбрать либо один из языков третьего
    поколения, т.е. обычных процедурных языков, либо применить объектно-ориентированный подход с
    использованием языков С++, Smalltalk, O-o Cobol, либо программировать на языке четвертого поколения


    от IBM 4Gl. При этом, IBM старается избавить разработчика от рутинной работы и позволить ему
    сосредоточиться на разработке смысловой части приложения. Для достижения этой цели используется
    технология визуального программирования - создание приложений из уже готовых частей. Программа
    собирается из произвольного числа модулей, каждый из которых может быть либо создан при разработке,
    либо получен от независимого поставщика, либо взят из поставляемых со средствами разработки
    библиотек. Разработчик, имея единую концепцию визуального программирования IBM VisualAge, в
    праве выбрать любой из предлагаемых языков программирования или же использовать несколько языков
    в рамках технологии IBM стандартизации объектов System Object Model. Кроме того, разработчик
    свободен также в выборе компьютерной платформы для исполнения, разработанного им приложения. Ему
    предоставляется широкий выбор из платформ IBM (OS/2, OS/400, AIX, MVS...) а также платформ третьих
    поставщиков.

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

    []
    []
    []

    Стратегия IBM

    В такой ситуации подход IBM к созданию ООИС заключается в применении технологий, в
    наибольшей степени соответствующих специфике решаемой задачи. Так, в системе организации
    коллективной разработки программного обеспечения Team Connection используется объектно-
    ориентированная СУБД Object Store, специально лицензированная у компании Object Design.
    Выбор объектно-ориентированной СУБД определяется при этом необходимостью управлять
    сравнительно небольшим объемом данных при их сложной структуре и разнообразии методов
    обработки. Иной подход предлагается IBM для построения корпоративных информационных
    систем, где приоритетными являются соображения надежности и производительности, а также
    совместимости с прежними версиями и промышленными стандартами. Полагая, что при
    современном уровне развития информационных технологий такие характеристики может
    обеспечить только реляционная СУБД, IBM предлагает для таких систем новую версию DB2,
    которая сохраняет всю функциональность реляционной СУБД, но расширяет ее новыми
    средствами, выходящими за рамки реляционной алгебры и призванными снять некоторые
    ограничения реляционной модели . В значительной мере на такой подход
    влияет и необходимость защиты инвестиций, сделанных пользователями в реляционные
    технологии, и в известной степени он является компромиссным, однако позволяет снять многие
    острые проблемы, стоящие перед современными СУБД.


    "Строительные блоки" приложений - компоненты

    Как известно, фундаментальной основой визуальных средств Delphi является компонентный
    подход. В чем же он заключается?

    Delphi строится на базе компилятора объектно-ориентированного языка Object Pascal,
    продолжающего линию диалектов Pascal - Turbo Pascal и Borland Pascal. По мере своего развития,
    каждая очередная реализация Pascal компании Borland включала все новые расширения
    синтаксиса, отражающие последние достижения в области языков программирования. Если
    подходить к оценке качественных "ступеней" развития Pascal, особо следует отметить три из них,
    направленные на поддержку концепции повторного использования кода:


  • модульная архитектура, с возможностью разделения интерфейсной и
    описательной частей (Turbo Pascal 4.0);
  • средства объектной ориентации, со всеми, присущими ей
    характеристиками - наследованием, инкапсуляцией и полиморфизмом (Turbo
    Pascal 5.5);
  • поддержка механизмов RTTI (Run-Time Type Information), позволяющих
    получать информацию о базовых характеристиках объектных типов (классов) и
    их экземпляров (объектов) с помощью языковых средств, непосредственно
    встроенных в системную библиотеку и структуру организации описаний классов
    (Delphi 1.0 - Object Pascal);

    Следствием введения поддержки RTTI стала возможность создания визуального инструмента
    разработки приложений, каковым и является Delphi. На определенном уровне иерархии
    наследования базовой библиотеки классов Delphi появляется класс TPersistent,
    обеспечивающий необходимый уровень абстракции потокового ввода/вывода объектов (экземпляров
    классов). Его наследником выступает класс TComponent, определяющий основы поведения
    компонент Delphi VCL (Visual Component Library) в режиме design-time (этап
    "конструирования" приложения). На оконечных точках ветвей иерархии VCL находятся как таковые
    компоненты - готовые к визуальному использованию классы, непосредственно регистрируемые в
    рабочей библиотеке компонент и доступные из Палитры Компонент (Components Palette) IDE
    Delphi.

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

    С другой стороны, механизмы регистрации и дальнейшего наследования уже существующих
    стандартов динамического связывания (Windows DLL) и компонентной архитектуры (VBX в
    Delphi 1.0 и OCX - в 32- разрядной версии Delphi) позволяют использовать в Delphi доступные
    внешние инструменты (например, компиляторы C++) и, созданные с их помощью, программные
    блоки.

    Самодостаточность Delphi для расширения набора доступных компонент является первым
    признаком открытости архитектуры этого инструмента.

    Структура и оформление окна

    Разработчику предоставляется типичный для инструментов такого типа интерфейс - мышь, меню,
    панель инструментов, окно редактирования атрибутов.

    На пространство окна "наклеиваются" стандартные органы управления - разного рода кнопки,
    выпадающие списки, тексты, поля ввода, графические элементы оформления; достаточно указать
    мышью нужный орган на панели инструментов и место, куда его следует поместить. Для
    группирования органов управления используются рамки (frame), они необходимы, в частности,
    если нужно создать несколько групп радиокнопок.

    В окне могут использоваться также визуальные объекты созданных ранее классов.

    Атрибуты окна и его органов (цвет, шрифт, надпись и др.) задаются в окне редактирования
    атрибутов.

    Имеется также генератор многоуровневых меню, в котором определяется меню для текущего
    окна.


    Структура JAM

    Пакет JAM имеет модульную структуру и состоит из следующих компонент:

  • Ядро системы. Ядро является законченным модулем и
    позволяет полностью разрабатывать приложения;
  • JAM /DBi - модуль интерфейса к СУБД. Для каждой СУБД,
    поддерживаемой JAM`ом, существует специализированный модуль. Например,
    JAM/DBi-Oracle, JAM/DBi-Informix, JAM/DBi-ODBC и т.д. Модули JAM/DBi
    являются дополнительными для ядра и самостоятельно использоваться не
    могут;
  • JAM/RW - модуль генератора отчетов. Модуль JAM/RW является
    дополнительным для ядра и самостоятельно использоваться не может;
  • JAM/CASEi - модуль интерфейса к CASE верхнего уровня (например,
    CASE структурного анализа и дизайна). Для каждой CASE, поддерживаемой
    JAM`ом, существует специализированный модуль. Например, JAM/CASEi-
    TeamWork, JAM/CASEi-Innovator и т.д. Модули JAM/CASEi являются
    дополнительными для ядра и самостоятельно использоваться не могут;
  • JAM/TPi - модули интерфейса к Мониторам Транзакций. Существует
    два варианта этих модулей - TPi-Server и TPi-Client. Для каждого МТ,
    поддерживаемого JAM`ом, существуют специализированные модули.
    Например, JAM/TPi-Server TUXEDO и т.д. Модули JAM/TPi являются
    дополнительными для ядра и самостоятельно использоваться не могут.

    Суперпредставления

    Суперпредставление, так же, как и представление (view), является описанием информационного
    среза БД, но несет некоторую дополнительную структурную нагрузку, имеет наглядное внешнее
    представление. При помощи ViewPoint Pro администратор строит серию суперпредставлений,
    отражающих существенные информационные связи. На их основе прикладные специалисты, не
    обладающие навыками программирования, могут при помощи средств разработки ViewPoint Pro
    быстро создавать приложения, отвечающие их потребностям.

    Генератор суперпредставлений ViewPoint Pro позволяет описывать их структуру не в терминах
    операторов SQL SELECT, а в терминах связей между таблицами. Связь задается операцией
    соединения столбцов двух таблиц с явным указанием типа: "один к одному", "один к 0 или к
    одному", "один ко многим", "один к нулю или многим".


    Супертаблицы - органы управления для взаимодействия с БД

    Для взаимодействия с БД генератор окон предоставляет две разновидности органов управления,
    называемых супертаблицами (SuperTable):

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

    Редактор предлагает также заготовки командных кнопок, часто используемых при работе с БД -
    Retrieve (выполнить выборку), Insert Row (вставить строку), Delete Row (удалить строку), Apply
    All - сохранить в БД изменения, сделанные пользователем в супертаблице, и др. В супертаблицу
    можно обычным образом включить стандартные органы управления. Таким образом,
    конструктивно супертаблица представляет собой рамку, содержащую суперполя и другие органы
    управления.

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

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

    Развитая встроенная функциональность супертаблиц и суперполей позволяет достаточно легко
    реализовать:

  • Выполнение и просмотр заданной выборки. Выборка задается либо
    статически, при описании супертаблицы, либо динамически, программным
    способом.
  • Выполнение "запроса по образцу". Пользователь задает в полях
    супертаблицы интересующие признаки, затем нажимает кнопку "Выбрать" - в
    супертаблице появляется результат выборки.
  • Редактирование данных. Пользователь изменяет выбранные данные,
    уничтожает и вставляет строки, затем нажатием соответствующей кнопки
    фиксирует сделанные изменения в БД.
    Доступ к БД в супертаблицах реализован на основе универсального объектного интерфейса,
    который позволяет использовать Informix или любую СУБД, доступную посредством интерфейса
    ODBC.


    Связи категоризации

    Некоторые сущности определяют целую категорию объектов одного типа. В ERwin в таком случае
    создается сущность для определения категории и для каждого элемента категории, а затем вводится
    для них связь категоризации. Родительская сущность категории называется супертипом, а дочерние -
    подтипом.

    Например, сущность "сотрудник" может содержать данные как о штатных работниках, так и о
    временно нанятых. Первые и вторые имеют различные, частично пересекающиеся наборы атрибутов
    (минимальное пересечение подтипов составляет первичный ключ). Общая часть этих атрибутов,
    включая первичный ключ, помещается в сущность-супертип "сотрудник".

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

    В сущности-супертипе вводится атрибут-дискриминатор, позволяющий различать конкретные
    экземпляры сущности - подтипа.

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

    В ERwin полная категория изображается окружностью с двумя подчеркиваниями, а неполная -
    окружностью с одним подчеркиванием.


    Связи (relationships) в ERwin

    Связь - это функциональная зависимость между двумя сущностями (в частности, возможна связь
    сущности с самой собой). Например, важно знать фамилию сотрудника, и не менее важно знать, в
    каком отделе он работает. Таким образом, между сущностями "отдел" и "сотрудник" существует связь
    "состоит из" (отдел состоит из сотрудников). Связь - это понятие логического уровня, которому
    соответствует внешний ключ на физическом уровне. В ERwin связи представлены пятью основными
    элементами информации:

  • тип связи (идентифицирующая, неидентифицирующая,
    полная/неполная категория, неспецифическая связь);
  • родительская сущность;
  • дочерняя (зависимая) сущность;
  • мощность связи (cardinality);
  • допустимость пустых (null) значений.
    Связь называется идентифицирующей, если экземпляр дочерней сущности идентифицируется через ее
    связь с родительской сущностью. Атрибуты, составляющие первичный ключ родительской сущности,
    при этом входят в первичный ключ дочерней сущности. Дочерняя сущность при идентифицирующей
    связи всегда является зависимой.

    Связь называется неидентифицирующей, если экземпляр дочерней сущности идентифицируется иначе,
    чем через связь с родительской сущностью. Атрибуты, составляющие первичный ключ родительской
    сущности, при этом входят в состав неключевых атрибутов дочерней сущности.

    Для определения связей ERwin выбирается тип связи, затем мышью указывается родительская и
    дочерняя сущность. Идентифицирующая связь изображается сплошной линией; неидентифицирующая
    - пунктирной линией. Линии заканчиваются точкой со стороны дочерней сущности.

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

    Атрибуты первичного ключа родительской сущности по умолчанию мигрируют со своими именами.
    ERwin позволяет ввести для них роли, т.е. новые имена, под которыми мигрирующие атрибуты будут
    представлены в дочерней сущности.
    В случае неоднократной миграции атрибута такое
    переименование необходимо. Например, сущность "посредническая сделка" имеет атрибут "код
    предприятия-продавца" и "код предприятия-покупателя". В данном случае первичный ключ сущности
    "предприятие" ("код предприятия") имеет две роли в дочерней сущности.

    На физическом уровне имя роли - это имя колонки внешнего ключа в дочерней таблице.

    Мощность связи представляет собой отношение количества экземпляров родительской сущности к
    соответствующему количеству экземпляров дочерней сущности. Для любой связи, кроме
    неспецифической, эта связь записывается как 1:n.

    ERwin в соответствии с методологией IDEF1X предоставляет 4 варианта для n, которые
    изображаются дополнительным символом у дочерней сущности: ноль, один или больше (по
    умолчанию); ноль или один; ровно N, где N - конкретное число.

    Допустимость пустых (NULL) значений в неидентифицирующих связей ERwin изображает пустым
    ромбиком на дуге связи со стороны родительской сущности.

    Обозначения мощности соответственно ноль, один или больше, один или больше, ноль или один в
    нотации IE приведены на рис. 1.

    Связи (relationships) в ERwin

    Sybase Backup Server

    Sybase Backup Server - это специальный сервер для высокопроизводительной выгрузки и загрузки
    баз данных, не требующий остановки SQL Server и не снижающий его производительности.

    Дамп базы данных и журнала производится без прекращения использования БД. Поэтому имеется
    возможность выполнять дамп часто, что повышает надежность системы. Backup Server выполняет
    весь необходимый ввод-вывод. Команды на дамп или загрузку выдаются непосредственно для SQL
    Server, который обращается к Backup Server. Основные характеристики Backup Server:


  • можно выполнять дамп параллельно частями так, что данные из одной БД и
    журнала будут одновременно записываться на несколько (до 32) устройств;
  • один дамп может занимать несколько лент или файлов;
  • имеется возможность выполнять выгрузку и загрузку в локальной сети так,
    что SQL Server находится на одном компьютере, а Backup Server и лента - на
    другом;
  • поддерживаются все платформо-специфичные опции работы с лентой,
    такие, как именование томов, размеры блоков и т.д.;
  • несколько выгрузок и загрузок могут управляться с одного или нескольких
    локальных или удаленных серверов.

    При правильной конфигурации производительность выгрузки может превышать 10 Гигабайт в
    час.

    Выгрузка производится в два этапа - сначала выгружается состояние данных на момент начала
    дампа, а затем оно дополняется изменениями, произошедшими за время дампа.

    Имеется возможность получения как полного дампа базы данных, так и дампа
    изменений.


    Иерархическая конфигурация управления
    Уровень 1

  • память
  • процедурный кэш

    • Уровень 2

  • атрибуты объектов
  • буферы кэшей

    • Уровень 3

  • полный доступ ко всем конфигурационным переменным (более 300)


    • Sybase IQ

    В системах поддержки принятия решений используется два типа продуктов. Одни оптимизированы
    для предварительно известных запросов, а другие - для запросов "на лету" (т.е. заранее
    неизвестных). Sybase IQ не требует заранее определять "пути", то есть не требует использовать
    предварительные знания о структуре запросов.


    Архитектура Sybase MPP
    Sybase IQSybase IQSybase IQ
    Sybase MPP    		Sybase IQSybase IQSybase IQSybase IQ
    Sybase IQSybase IQSybase IQSybase IQ
    Sybase IQSybase IQSybase IQSybase IQ
    ПриложенияSybase SQL ServerБазы данных


    Sybase MPP

    Sybase MPP - это расширение архитектуры Sybase SQL Server, разработанное и оптимизированное
    для массовой параллельной обработки. Он обладает открытой параллельной архитектурой,
    предназначенной для поддержки очень больших баз данных (VLDB). Sybase MPP использует
    стандартный SQL и открытые интерфейсы. С ним работают те же приложения, что и с SQL Server,
    без необходимости перепрограммирования (рис.9).

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

    Дополнительные процессоры и диски могут добавляться в систему постепенно, достигая
    масштабируемости в сотни раз. Имеется возможность тиражировать и перестартовать ключевые
    компоненты системы так, чтобы обеспечить быстрое восстановление при сбоях.

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

    Для управления системой имеются графические утилиты.


    Табл. 1. Данные с высоким уровнем секретности


    ИмяДиагноз
    ИвлевРак легких
    ИвановПневмония
    ЯрцевОжог второй степени
    СуворовМикроинфаркт


    Табл. 2. Данные с низким уровнем секретности

    Обратим внимание на то, что сведения о пациенте по фамилии Иванов присутствуют на обоих
    уровнях, но содержат разные диагнозы.

    Мы хотим реализовать такую дисциплину доступа, чтобы пользователи с низким уровнем
    благонадежности могли манипулировать только данными на своем уровне и не имели
    возможности сделать какие-либо выводы о присутствии в секретной половине сведений о
    конкретных пациентах. Пользователи с высоким уровнем благонадежности должны иметь доступ к
    секретной половине таблицы, а также к информации о прочих пациентах.

    Дезинформирующих строк о секретных пациентах они видеть не должны:


    ИмяДиагноз
    ИвановСПИД
    ИвлевРак легких
    ИвановПневмония
    ПетровСифилис
    СидоровСтреляная рана
    ЯрцевОжог второй степени
    СуворовМикроинфаркт


    Табл. 3. Данные, доступные пользователю с высоким уровнем секретности


    (Обратим внимание на то, что строка "Иванов Пневмония" здесь отсутствует.)

    Размножение строк, обеспечивающее необходимую дисциплину доступа, стандартными средствами
    SQL можно реализовать следующим образом:

    CREATE TABLE BaseTable1 (

    PatientName char (20),

    Disease char (20),

    Level char (10)

    ) WITH PRIMARY KEY (PatientName, Level)

    ;

    CREATE TABLE BaseTable2 (

    UserName char (20),

    SecurityLevel char (10)

    ) WITH PRIMARY KEY (UserName)

    ;

    CREATE VIEW PatientInfo (

    PatientName,

    Disease

    ) AS SELECT PatientName, Disease

    FROM TABLE BaseTable1

    WHERE BaseTable1.Level = (

    SELECT SecurityLevel FROM BaseTable2

    WHERE UserName = username ()

    ) OR (

    BaseTable1.Level = "LOW"

    AND NOT EXISTS (

    SELECT * FROM BaseTable1 AS X

    WHERE X.PatientName = BaseTable1.PatientName

    AND X.Level = "HIGH"

    )

    )

    ;

    Всем пользователям предоставляется доступ только к представлению PatientInfo.
    Пользователи с низким уровнем благонадежности увидят только информацию, выдаваемую
    первой конструкцией WHERE:

    WHERE BaseTable1.Level = (

    SELECT SecurityLevel FROM BaseTable2

    WHERE UserName = username () )

    поскольку для них поле SecurityLevel имеет значение "LOW". В формирование представления
    для благонадежных пользователей внесут вклад обе конструкции WHERE, причем в случае
    совпадения имен менее секретные записи будут заслонены более секретными (конструкция NOT
    EXISTS).

    Мы видим, что в отличие от систем с меточной безопасностью, стандартные SQL-серверы
    предоставляют довольно тяжеловесные средства для реализации механизма размножения строк.
    Тем не менее, эти средства не так плохи, как может показаться на первый взгляд. Можно надеяться,
    что оптимизатор SQL-запросов, входящий в комплект любой современной СУБД, сделает время
    доступа к представлению PatientInfo сравнимым с временем извлечения строк из базовых
    таблиц.

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


    Технические предложения на разрабатываемый проект содержат:

  • моделирование бизнес-процессов, включающее описание организационной
    структуры предприятий, их технологических процессов и систем
    документооборота, а также связей с внешними организациями;
  • разработка планов реинжиниринга предприятий;
  • определение Автоматизированных Рабочих Мест (АРМов) и
    информационного взаимодействия между АРМами и внешними базами
    данных;
  • определение основных задач и направлений, решаемых в системе;
  • постановки всех функциональных подсистем;
  • разработка технологии решения задач пользователей в условиях автоматизации;
  • проектирование концептуальной модели базы данных;
  • определение основных входных и выходных сообщений;
  • определение требований к системному программному обеспечению и
    инструментальным средствам, с помощью которых будет осуществляться
    прикладное программирование;
  • определение требований к техническим средствам, средствам связи,
    обеспечивающим надежную и эффективную эксплуатацию системы.
  • определение конфигурации и состава разрабатываемых систем.
  • определение организационной структуры и оценка необходимой численности
    эксплуатационного персонала разрабатываемых систем.

    Технология быстрой разработки приложений на основе CASE-средств фирмы CADRE

    А.В.Закис, М.И.Макаров, Н.И.Приезжий, DataX/FLORIN, Inc.
    VantageTeam Builder фирмы CADRE (известный ранее как WESTMOUNT I-CASE Yourdon) - одно из
    наиболее мощных на Российском рынке средств разработки информационных систем. Основанный на
    структурном подходе, он позволяет вести разработку параллельно по трем направлениям -
    построение модели данных, разработка модели поведения системы (функциональной модели) и
    проектирование интерфейса системы. В нашей предшествующей статье мы
    описали основные возможности продукта. Также весьма обстоятельно они описаны в статье Вендрова
    . Поэтому в настоящей статье мы ограничимся весьма кратким общим обзором
    продукта, а основное внимание уделим более детальному анализу инструментов кодогенерации. В
    частности, мы поделимся некоторыми результатами собственного использования VantageTeam Builder
    для быстрой генерации приложений, в том числе, для разработки собственного генератора
    GRINDERY. В силу ограниченности опыта авторов в статье рассматривается генерация приложений
    только для СУБД Informix, хотя VantageTeam Builder позволяет вести разработку приложений для
    различных СУБД, в том числе для Sybase, Oracle и Ingres.


    Тенденции в мире систем управления базами данных

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


    Типизация данных

    Реализованная в S-Designor типизация данных - средство достижения универсальности типов
    данных, используемых в модели. На уровне концептуальной модели разработчик оперирует с
    внутренними типами данных S-Designor. Эти типы данных представлены достаточно
    широким набором и, что важно, независимы от целевой СУБД. При переходе на физический уровень
    эти типы данных заменяются типами данных целевой СУБД. Правила соответствия универсальных
    типов данных и целевых определяются во внешнем текстовом файле, доступном для редактирования.
    В нем же определяются все правила кодирования SQL-предложений для конкретной СУБД.
    Соответствие типов данных и конструкции SQL-предложений для конкретной СУБД можно
    переопределять, хотя такая необходимость возникает крайне редко.


    Типы данных, определяемые пользователем

    Эта версия DB2 дает пользователю возможность определять новые типы данных. Новый тип
    данных должен соответствовать одному из базовых типов, предоставляемых системой, но для них
    может быть определена своя семантика. При этом DB2 способна манипулировать такими данными
    в соответствии с определенной для них логикой. Можно задать набор операций, допустимых для
    некоторого типа данных, изменив его по сравнению с относящимся к базовому типу.

    В DB2 реализован механизм строгой типизации. К данным новоопределенного типа применимы
    при этом только те операции, которые определены для него самого, а не для базового класса. Для
    СУБД такой подход предоставляет мощный механизм контроля целостности данных.

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

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


    Тиражирование данных

    Одной из наиболее интересных новых возможностей SQL Server 6.0 является тиражирование
    данных.

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

    Тиражирование данных

    Требования к аппаратным ресурсам

    JAM как среда разработки и приложения, построенные с его использованием, не являются
    ресурсоемкими системами. Достаточно сказать, что на платформе MS-Windows достаточно иметь
    8MB ОЗУ и 50 MB дискового пространства для среды разработки. На UNIX-платформах
    требования к аппаратуре нивелируются природой UNIX.


    Триггеры

    Триггеры - это определяемые пользователем действия, которые выполняются, когда над таблице, к
    которой прикреплен триггер, выполняются операции INSERT, UPDATE или DELETE. В SQLBase
    действия триггера являются хранимыми процедурами. Иными словами, пользователь создает
    хранимые процедуры, которые описывают действия, совершаемые триггерами.

    В SQLBase триггеры используются для решения трех основных задач:


  • Усиление ссылочной целостности - Триггеры могут быть использованы для
    реализации ограничений ссылочной целостности, выходящие за пределы
    стандартных ограничений SQLBase. Например, пользователь может захотеть
    реализовать правило. каскадного изменения данных (update cascade rule). Он
    может это сделать, создав триггер, который будет обновлять дочернюю
    таблицу (таблицы) при каждом изменении колонки в родительской таблице.
  • Проверка данных - Триггеры могут выполнять разнообразную проверку
    данных. Значения колонок могут передаваться в триггерные процедуры в
    качестве параметров, где над ними могут производиться самые разнообразные
    операции. В текущей версии SQLBase реализован механизм, который
    позволяет производить ввод данных в таблицы непосредственно из триггера,
    без передачи информации извне. Например, пользователь может создать
    триггер, который будет получать из приложения данные для ввода в строку
    таблицы, создавать уникальный ключ для этой строки внутри своей процедуры
    и передавать в базу данных полную строку с ключом. Помимо генерации
    ключей, триггеры SQLBase могут выполнять и другие подобные операции.
  • Регистрация изменения данных - Создатель таблицы или администратор
    базы данных может пожелать иметь информацию о времени каждого
    изменения данных в таблице, а также о том, какой пользователь эти изменения
    производил. Для этого он создает триггер, в который поступает системное
    время операции UPDATE и имя пользователя. Процедура триггера затем
    вводит эту информацию в специальную таблицу регистрации изменений.
    Использование триггеров подобного типа позволяет организовать системы

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

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

    Триггер может быть определен для выполнения либо перед операцией insert/update/delete (before
    триггер), либо после нее (after триггер). Типичный пример использования before триггеров -
    проверка данных. After триггеры полезны в тех случаях, когда хранимая процедура триггера
    содержит код, анализирующий содержимое таблицы, на которой определен триггер, и этот код
    должен включать результаты последней операции insert/update/delete.

    Операции insert/update/delete, которые содержат предложения WHERE или суб-запросы (sub-
    selects), модифицируют более одной строки таблицы. Триггеры SQLBase могут быть
    сконфигурированы таким образом, чтобы запускаться только один раз за всю операцию или
    каждый раз при изменении отдельной строки.

    Update триггеры могут быть определены таким образом, чтобы запускаться только при изменении
    отдельных колонок таблицы (селективные update триггеры) или реагировать на любое изменение
    данных в таблице.

    При передаче данных в процедуры триггеров можно использовать следующие типы данных в
    качестве параметров процедур:


  • Значения колонок таблицы - Поскольку триггер определяется на конкретной
    таблице базы данных, он "знает" о ее строении: количестве, именах и типах
    колонок и т.д. Поэтому значения колонок таблицы могут передаваться в
    процедуру непосредственно по своим именам.
  • Константы
  • Псевдоконстанты - В процедуру можно передавать некоторые ключевые
    слова SQLBase, такие как USER, SYSTIME и другие.

    Если в процессе выполнения операции UPDATE содержимое колонки изменяется, имеется


    возможность передать в процедуру триггера как старое, так и новое значение колонки. Для этого
    служит предложение REFERENCING в определении триггера. Если предложение REFERENCING
    не используется, по умолчанию значение колонки является старым для before update триггеров и
    новым для after update триггеров. Поскольку для insert триггеров старых значений не существует,
    значение колонки по умолчанию является новым. Аналогично, значение колонки для delete
    триггера является старым.

    Ограничения триггеров


  • При использовании триггеров существует целый ряд ограничений:
  • Все триггеры должны иметь уникальные имена.
  • Нельзя иметь два идентичных триггера. Другими словами, не может быть
    двух before insert триггеров на одной таблице.
  • Если update триггер определен на конкретной колонке или группе колонок,
    на данной таблице нельзя определить update триггер на всю таблицу.
  • На таблице можно определить не более двух insert, двух delete и четырех
    update триггеров одновременно.
  • Допускается не более восьми уровней рекурсии триггеров. Рекурсия
    триггеров возникает в тех случаях, когда операция insert/update/delete внутри
    процедуры триггера запускает другой триггер.
  • Предложение REFERENCING допускается только для update триггеров.
    Кроме того, это предложение возможно только для триггеров, запускающихся
    для каждой изменяемой строки отдельно, поскольку в противном случае
    значения колонок становятся неопределенными.
  • Хранимая процедура триггера должна быть статической.

    Пример триггера

    Ниже приведен пример триггера, который реагирует на обновление колонки в таблице.
    Предположим, мы имеем таблицу T1, содержащую целочисленную колонку C1 и таблицу T2 с
    колонками (OldC1 int, NewC1 int, Updater char(10)). В триггер передаются старое и новое значение
    колонки C1 и имя пользователя. Триггер затем вводит эту информацию в таблицу T2. (Отметим
    возможность определения хранимой процедуры триггера непосредственно в теле триггера с
    помощью оператора INLINE.)

    create trigger tg1 before update of c1 on t1
    referencing old as o new as n
    (execute inline (o.c1, n.c1, user)
    procedure p1 static
    parameters
    number: old
    number: new
    string: updater
    actions
    call sqlimmediate( 'insert into t2 values (:old, :new, :updater)' )
    for each row;

    Убираются внутрифирменные барьеры

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

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

    Удаленное отображение данных (эмуляция терминала)

    Средства эмуляции терминалов исторически являются одними из первых продуктов, реализующих
    возможность совместного функционирования ГЭВМ, СЭВМ и ПЭВМ. Они по-прежнему остаются
    одними из наиболее популярных продуктов, особенно для удаленного администрирования
    ресурсами ГЭВМ и СЭВМ.

    SOFTWARE AG предлагает использовать в качестве эмулятора терминалов продукт ENTIRE
    CONNECTION (рис. 3).


    ГЭВМ (IBM)СЭВМ (UNIX)MS Windows
    Удаленное отображение данных (эмуляция терминала)


    Удобные объекты (Object Easy)

  • Наследование, инкапсуляция и полиморфизм
  • Доступ к элементам управления других фирм
    PowerBuilder использует практический подход к объектной технологии, позволяющий разработчикам
    информационных систем осуществить быстрый переход к объектно-ориентированной разработке без
    необходимости знать и использовать специфические трудноизучаемые языки программирования. Он
    полностью поддерживает наследование, инкапсуляцию и полиморфизм.

    Приложение, созданное при помощи PowerBuilder, является композицией ряда объектов, таких как
    окна, меню, функции, структуры и Окна данных. Объекты, выполняющие общие функции,
    такие как Кнопка печати (Print button), могут многократно использоваться в разных
    приложениях, реально сокращая время разработки, а также повышая продуктивность программистов
    и качество программ.

    PowerBuilder включает графическую среду для создания определенных пользователем объектов,
    событий и функций, которая значительно упрощает повторное использование кода и делает более
    удобным сопровождение. Поддержка многоуровневого наследования облегчает разработку и
    сопровождение библиотек объектных классов. Доступ к элементам управления других фирм, таким
    как объекты VBX и C++, осуществляется прозрачно при помощи Художника объектов
    пользователя (User Objects Painter).


    Удобство и простота работы

    Понятие "интуитивно понятный интерфейс" означает, что уже после 1-2 часов экспресс-обучения
    человек свободно может общаться с программой. Такие системы учитывают психологию людей,
    они дружелюбны и понятны, широко используют изображения и звук вместо текста. Работать с
    такой системой может даже непрофессионал, и ему не требуется изучать тома документации.
    Человек видит на экране просто свой рабочий стол со стопками чистых бланков, папками с
    подшивками документов, журналами и ведомостями.

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


    Укрупненная система моделей организации.

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

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

    В процессе отображения бизнес-процессов по уровням организационной иерархии формируется и
    уточняется общий список бизнес-процессов, и могут появиться новые бизнес-процессы.


    Улучшение работы OLTP приложений

    В Oracle 7.3 модифицированы многие алгоритмы, связанные с обработкой OLTP приложений.
    Увеличена скорость выполнения таких приложений, улучшено использование буферов памяти,
    более компактным стал программный код, SQL-операторы и процедуры занимают меньше места в
    оперативной памяти. Триггеры БД теперь хранятся в откомпилированном виде, что
    ускоряет их выполнение. Улучшена работа Parallel Server Option. Обмен данными между
    узлами кластера сведен к минимуму, уменьшена вероятность возникновения коллизий. SQL*Net
    может при открытии нового сеанса связи с кластером учитывать загрузку узлов кластера.
    Улучшены алгоритмы работы Oracle в среде мониторов транзакций.

    Следует также упомянуть о появлении механизма сериализованных транзакций. Ранее Oracle
    обеспечивал согласованный результат выполнения запроса без выполнения блокировки. Однако
    для того, чтобы обеспечить эту согласованность в рамках транзакции приходилось объявлять эту
    транзакцию read only (т.е. она не содержала операторов, модифицирующих данные). Это снижало
    результаты Oracle при тестировании по тесту ТРС С, т.к. запросы и модификации приходилось
    выносить в отдельные транзакции. Новый вид сериализованных транзакций позволяет смешивать
    в общей транзакции и DML операторы и операторы запроса. При этом такая транзакция работает
    на согласованном представлении БД, т.е. не замечает всех изменений, производимых во время ее
    работы другими транзакциями. Таким образом механизм согласованности без блокировки
    расширен на всю транзакцию.


    Улучшение работы с Data Warehouse

    В этой области все улучшения можно разбить на 2 группы:


  • улучшение алгоритмов оптимизации специфичных для Data Warehouse
    запросов;
  • ускорение выполнения запросов к большим таблицам.

    Задачи, связанные с использованием Data Warehouse породили группу специфических запросов,
    для которых не годятся стандартные методы оптимизации. Кроме того, успешное выполнение
    запросов к большим таблицам невозможно без распараллеливания работы. И оптимизатор должен
    учитывать при выборе плана выполнения запроса такие факторы, как степень распараллеливания,
    количество процессоров, распределение данных таблицы по дискам, распределение таблиц по
    узлам распределенной БД, близость тех или иных процессоров и дисков в МРР архитектурах. Не
    учитывание этих факторов может значительно замедлить выполнение SQL операций. Например, в
    некоторых случаях параллельное сканирование таблицы выгоднее, чем выборка из нее по индексу.
    Cost based оптимизатор Oracle 7.3 учитывает все эти факторы. Кроме того, для правильного
    построения плана выполнения SQL оператора желательно учитывать распределение данных в
    столбцах таблицы. Поэтому Oracle 7.3 позволяет собирать такую информацию и строит на ее
    основе гистограммы распределения данных в столбце, а оптимизатор использует эти
    гистограммы при принятии решения.

    Для Data Warehouse часто используются звездные запросы (star query). В них извлекается
    информация из одной огромной центральной таблицы и множества мелких таблиц -
    справочников. Oracle 7.3 выделяет и оптимизирует такие запросы. При этом сначала соединяются
    справочники, а затем эта небольшая сводная справочная таблица соединяется с центральной
    таблицей. При работе с центральной таблицей используются индексы.

    В задачах Data Warehouse часто используются представления (View ), полученные за счет
    объединения (Union) множества мелких таблиц однотипной структуры. Например, продажи за год
    - объединение продаж за месяц. Операции выборки из таких больших VIEW будут ускорены, если
    быстро будут исключены из рассмотрения те мелкие таблицы, которые не удовлетворяют

    условиям запроса. Например, если нас интересуют продажи за первые 10 месяцев, то не следует
    учитывать продажи за ноябрь и декабрь. Оптимизатор Oracle 7.3 учитывает это при работе.
    Ускоряется и выполнение запросов с условием NOT IN (анти JOIN ). Оптимизатор также
    учитывает новые алгоритмы Oracle, ускоряющие выполнение SQL операторов. Среди них следует
    отметить следующие:

    Новый алгоритм соединения таблиц с использованием хэширования (hash join). Этот
    алгоритм исключает необходимость сортировки и слияния участвующих в соединении таблиц. Он
    дает ускорение в 10 - 100 раз. Он очень удобен и для параллельной обработки. Основная идея
    заключается в том, что меньшая из таблиц (или меньшая часть двух соединяемых фрагментов
    таблиц) хэшируются в оперативной памяти. А вторая таблица (фрагмент) сканируется и для
    каждой ее строки по хэш функции находится в оперативной памяти соответствующая запись
    первой таблицы. Разделение таблиц на фрагменты также выполняется с учетом хэш функций.

    Битовые индексы. Для индексирования столбцов с низкой кардинальностью ( т. е.
    содержащих небольшое число значений, например: пол - М или Ж, цвет - красный, желтый, синий)
    удобно использовать битовые (bit map) индексы. Для каждого значения столбца строится битовая
    линейка, в которой число битов равно числу значений в столбце и биты, соответствующие
    позиции данного значения в столбце, установлены в 1. Например, для столбца "пол" будет
    построено 2 битовых линейки. Операции поиска по этому столбцу сведутся для Oracle к
    выполнению логического И/ИЛИ над этими линейками. Кроме того, битовые линейки хранятся в
    упакованном виде. Oracle умеет одновременно работать как с битовыми (т.е. более компактными,
    чем обычные индексы) так и с обычными индексами. Тип индекса прозрачен для приложения, но
    скорость выборок из больших таблиц с битовыми индексами возрастает значительно. Ранее
    битовые индексы использовались в SQL*Textretrieval для работы с текстовыми БД.

    Усиление распараллеливания выполнения операций.


    В Oracle 7.3 распараллеливаются такие
    подэтапы выполнения SQL запроса, как SCAN, JOIN, AGREGATE, DUBLICATE
    ELIMINATION, UNION, UNION ALL, HASH JOIN. Поэтому выборки, построения и
    перестройки индекса, копирования таблиц реализуются быстрее.

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

    Выделенные временные табличные пространства. В предыдущих версиях Oracle оператор
    SQL, выполняющий сортировку, создавал, использовал, а затем удалял временные области в БД.
    Это требовало времени на управление выделением пространства. Кроме того, в том же Tablespace
    могли находиться и другие объекты БД. Создание выделенных tablespace только для сортировки
    позволит избежать этих накладных расходов.

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

    Улучшение работы с очень большими БД

    В этой области все улучшения можно разбить на три группы: ускоренная подготовка БД к работе;
    улучшение управления пространством в БД, повышение производительности при работе с
    большой БД.

    До сих пор для повышения надежности работы прикладной системы на базе Oracle использовались
    два варианта: кластерная архитектура (Oracle Parallel Server) и репликация. В версии Oracle 7.3
    добавляется новая возможность - STAND BY (резервная) база. Это очень удобно,
    например, на случай возможности взрыва центрального офиса с основной БД. Stand by база
    создается на другом компьютере (возможно в другом районе) и является копией основной базы.
    Она находится в режиме постоянного восстановления и не доступна для работы. Восстановление
    резервной базы ведется автоматически на основе передаваемых ей от основной базы журнальных
    файлов. В случае уничтожения основной базы, резервная очень быстро переводится в рабочий
    режим и становится основной. В последующее время на месте старой основной БД можно
    организовать новую резервную БД. Основная и резервная БД должны работать на одинаковых
    компьютерах, одинаковых версиях операционной системы и Oracle.

    До сих пор в случае сбоя БД Oracle выполнял ее восстановление в два этапа: rollout - откат вперед
    с восстановлением всех потерянных при сбое изменений и rollback - откат назад транзакций, не
    законченных к моменту сбоя. До окончания этих двух последовательных этапов БД была
    недоступна для работы. Процесс открытия большой БД после сбоя мог затянуться надолго.
    Поэтому в Oracle 7.3 Вы можете выполнить быстрое восстановление и получить доступ к
    БД после первого этапа, а rollback будет выполняться позднее в фоновом режиме. Это снизит
    время простоя БД.

    Новая утилита DB_VERIFY позволит Вам выполнить контроль целостности БД, ее блоков,
    backup копий БД. В версии Oracle 7.3 значительно улучшено управление пространством в БД.
    Объекты БД ( таблицы, индексы, сегменты отката и т.д. ) могут состоять из частей (экстентов),
    разбросанных по tablespace.
    Их число было ограничено. Сейчас это ограничение снято и очень
    большие объекты БД могут занимать неограниченное число экстентов. Кроме того, если в
    результате модификации данных область, занимаемая таблицей, индексом и т.д. заполнена лишь
    частично, то можно освободить неиспользованное пространство, передав его в общий пул
    свободного пространства tablespace (команда ALTER TABLE ... DEALLOCATE UNUSED).
    Это позволит разместить в БД больше объектов. Если в БД образуется несколько смежных
    участков свободного пространства, то процесс SMON умеет склеивать их в единый кусок. Однако
    теперь это может сделать и администратор БД с помощью команды ALTER TABLESPACE ...
    COALESCE.

    Ну и наконец для больших БД логический экспорт БД и ее больших объектов всегда занимал
    много времени. Утилита экспорта EXP работала с БД как обычное приложение, использующее
    команды языка SQL и стандартный вариант их обработки. Новый (прямой) режим
    экспорта работает в несколько раз быстрее, поскольку он "обходит" многие фазы стандартной
    обработки SQL и выбирает данные из БД в обход Oracle Server.

    Uniface

    (Compuware)

    Uniface 6.1 представляет собой среду разработки крупномасштабных приложений "клиент-сервер"
    и имеет следующую компонентную архитектуру:


  • Application Objects Repository (репозиторий объектов приложений) содержит метаданные, автоматически используемые всеми остальными компонентами на протяжении жизненного цикла ИС.
  • Application Model Manager поддерживает прикладные модели, каждая
    из которых представляет собой подмножество общей схемы БД с точки зрения
    данного приложения.
  • Rapid Application Builder - средство быстрого создания экранных форм
    и отчетов на базе объектов прикладной модели. Оно включает графический редактор форм, средства прототипирования, отладки, тестирования и документирования. Реализован интерфейс с разнообразными типами оконных элементов
    управления (Open Widget Interface) для существующих графических систем -
    MS Windows (включая VBX), Motif, OS/2.
  • Developer Services (службы разработчика) - используются для
    поддержки крупных проектов и реализуют контроль версий, права доступа,
    глобальные модификации и т.д. Это обеспечивает разработчиков средствами
    параллельного проекти-рования, входного и выходного контроля, поиска,
    просмотра, поддержки и выдачи отчетов по данным системы контроля версий.
  • Deployment Manager (управление распространением приложений) -
    средства, позволяющие подготовить созданное приложение для
    распространения, установить и сопровождать его (при этом платформа
    пользователя может отличаться от платформы разработчика). В их состав
    входят сетевые драйверы и драйверы СУБД, сервер приложений (полисервер),
    средства распространения приложений и управления базами данных. Uniface
    поддерживает интерфейс практически со всеми известными программно-
    аппаратными платформами, СУБД, CASE-средствами, сетевыми протоколами
    и менеджерами транзакций.
  • Personal Series (персональные средства) - используются для
    создания сложных запросов и отчетов в графической форме, а также для
    переноса данных в такие системы, как WinWord и Excel.

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

    Таблица характеристик СП

    Поддержка полного жизненного цикла ИСОбеспечение целостности проекта Независимость от платформыОдновременная групповая разработка БД и приложений
    СПWest-mount I-CASE + UnifaceDesigner/2000+Developer/2000SILVER-RUN + JAMERwin/ERX + PowerBuilder
    ++++
    ++--
    +
    (ORACLE, Informix, Sybase, Ingres и др., dbf-файлы)    		-
    (целевая СУБД - только ORACLE)    		+
    (ORACLE, Informix, Sybase, Ingres и др.)    		+
    (ORACLE, Informix, Sybase, поддержка ODBC)
    +-
    *)
    		-
    *)    		-
    *)

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

    Анализ данных, приведенных в таблице, показывает, что из перечисленных СП только комплекс
    Westmount I-CASE+Uniface наиболее полно удовлетворяет всем критериям, принятым в качестве
    основных. Так, например, в комплексе Westmount I-CASE+Uniface целостность базы проектных
    данных и единая технология сквозного проектирования ИС обеспечивается за счет использования
    интерфейса Westmount-Uniface Bridge. Следует отметить, что каждый из двух продуктов сам по
    себе является одним из наиболее мощных в своем классе.

    Таким образом, наиболее развитыми средствами разработки крупномасштабных ИС на
    сегодняшний день является, по мнению автора, комплекс Westmount I-CASE+Uniface. С другой
    стороны, его применение не исключает использования в том же самом проекте таких средств, как
    PowerBuilder, для разработки сравнительно небольших прикладных систем в среде MS
    Windows.

    []
    []
    []

    Унификация атрибутов

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

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

    Рассмотрим пример: сущность "сотрудник" имеет первичный ключ "код сотрудника" и связан
    идентифицирующей связью с сущностями "супруга" и "дети". При этом происходит миграция
    первичного ключа в зависимые сущности. В свою очередь, сущность "супруга" связана
    неидентифицирующей связью с сущностью "дети". Имеются два пути миграции ключа, однако в
    сущности "дети" атрибут "код сотрудника" появляется один раз в качестве элемента первичного
    ключа.

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


    Управление эскалацией блокировок

    Эскалация блокировок в SQL Server - это предельное количество блокировок страниц данных для
    таблицы, при достижении которого транзакция будет блокировать таблицу целиком. Имеется
    возможность управлять этой границей, которая по умолчанию составляет 200 страниц.


    Управление конфигурацией

    Для управления сервером имеется как набор хранимых процедур и set-команд, так и графическое
    средство.

    При работе с параметрами конфигурации в командном режиме введено три уровня представления -
    базовый уровень, служащий для управления основными параметрами, промежуточный уровень и
    детальный уровень, на котором доступны все параметры тонкой настройки (рис.10). Параметры
    организованы иерархически в соответствии с группами функций SQL Server, которыми они
    управляют. Имеется возможность создать несколько поименованных конфигураций и легко
    переключаться между ними.


    Управление объектами

    Объекты, созданные в процессе разработки приложения, хранятся в библиотеках PowerBuilder.
    Разработчики могут использовать в приложении объекты из одной или нескольких библиотек.
    Обычно каждый член коллектива разработчиков имеет свою собственную тестовую библиотеку, а
    также использует разделяемые библиотеки общих объектов, хранящиеся на сетевых файловых
    серверах.


    Управление оптимизатором SQLBase

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

    В новой версии SQLBase 6 пользователю предоставлена возможность изменять эту статистику и,
    таким образом, воздействовать на оптимизатор и реальное выполнение SQL запросов.

    Изменение статистики возможно с помощью новой команды UPDATE STATISTICS. Полное
    описание синтаксиса этой команды приведено в документации по SQLBase. Вкратце же синтаксис
    команды UPDATE STATISTICS выглядит следующим образом:

    Для модификации табличной статистики

    UPDATE STATISTICS ON TABLE имя-таблицы

    SET колонка-статистики = ...., ;

    Например,

    UPDATE STATISTICS ON TABLE ORDER

    SET ROWCOUNT = 10000, PAGECOUNT=100;

    (количество строк в таблице равно 10000, а количество страниц - 100)

    Для модификации индексной статистики

    UPDATE STATISTICS ON INDEX имя-индекса

    SET колонка-статистики = ...., ;

    Например,

    UPDATE STATISTICS ON INDEX ORDER_IX1

    SET HEIGHT = 2, CLUSTERCOUNT = 10000, LEAFCOUNT = 10000/150,
    DISTINCTCOUNT(order_num) = 5000 ;

    Управление статистикой базы данных


    Управление статистикой базы данных в SQLBase служит следующим целям:

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

    Помочь разработчику и администратору смоделировать реальную базу данных используя малое
    количество фактических данных.

    Следует отметить, что существующий метод воздействия на выполнение SQL запросов с помощью
    команды UPDATE STATISTICS является очень сложным и весьма нелинейным. В новой версии
    SQLBase планируется появление специального модуля "Управление планом выполнения", которая
    даст возможность специалистам и пользователям воздействовать на способы выполнения запросов
    к базе данных непосредственным образом.


    Управление публикациями и статьями в них

    После того как база данных открывается для публикации (это видно по соответствующей
    пиктограмме в диалоговом окне среды администрирования), администратор определяет, какие
    таблицы или/и части таблиц подлежат тиражированию. Организация
    тиражирования данных SQL Server обеспечивает высокую гибкость и позволяет точно
    указать, какие элементы базы данных получает тот или иной подписчик.(Рис.9,10)

    Управление публикациями и статьями в них

    Управление транзакциями

    Архитектура Sybase System 11 поддерживает как синхронную, так и асинхронную модель
    управления транзакциями. Модель выбирается в соответствии с требованиями предметной
    области.

    Централизованное хранение данных и доступ к центральной БД в условиях географически
    распределенной системы приводят к необходимости установления соединений между центральным
    сервером, хранящим данные, и компьютерами-клиентами. Большинство компьютеров-клиентов
    отделены от центрального сервера медленными и недостаточно надежными линиями связи,
    поэтому работа в режиме удаленного клиента становится почти невозможной. Этим можно
    объяснить часто существующую ситуацию, когда в узлах распределенной системы функционируют
    группы автоматизированных рабочих мест (АРМ) и эти группы АРМ не связаны друг с
    другом.

    Содержательная сторона задачи обычно требует обмена данными между группами АРМ, так как
    изменения в данные могут вноситься в одной группе АРМ, а использоваться - в другой. Обмен
    данными на практике часто реализуется регламентной передачей файлов, либо через модемное
    соединение, либо "с курьером".

    То, что данные доставляются к месту назначения не системными средствами, а путем
    экспорта/импорта файлов, приводит к необходимости участия человека в процессе обмена, что
    влечет за собой неоперативность поступления данных и необходимость реализации внешних
    механизмов контроля целостности и непротиворечивости. Результатом является высокая
    вероятность ошибок. Кроме того, реализация всех алгоритмов обмена данными и контроля в этом
    случае возлагается на прикладных программистов, проектирующих АРМ. Объем работ по
    программированию и отладке подпрограмм обмена соответствует числу различных АРМ. Это
    также приводит к повышению вероятности ошибок в системе.

    В современной технологии АРМ объединены в локальную сеть. АРМ-клиент выдает запросы на
    выборку и обновление данных, а СУБД исполняет их. Запросы клиента в соответствии с
    требованиями задачи сгруппированы в логические единицы работы (транзакции).
    Если все
    операции с базой данных, содержащиеся внутри транзакции, выполнены успешно, транзакция в
    целом выполняется успешно (фиксируется). Если хотя бы одна из операций с БД внутри
    транзакции не выполнилась успешно, то все изменения в БД, произведенные к этому моменту из
    транзакции, отменяются (происходит откат транзакции). Такое функционирование обеспечивает
    логическую целостность данных в базе данных.

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

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

    прежнему поддерживает уровни изоляции транзакций

    Sybase System 11 по- прежнему поддерживает уровни изоляции транзакций 1-3. К ним добавился
    уровень 0, который для данных, уже модифицированных некоторой транзакцией, предотвращает
    их изменение другими транзакциями. Другие транзакции, модифицирующие такие данные,
    блокируются до завершения первой транзакции. Однако другим транзакциям позволяется
    считывать измененные, но незафиксированные данные. Уровень изоляции 0 также известен под
    названием "грязное чтение".


    Производительность: Именованные кэши
    прежнему поддерживает уровни изоляции транзакций

  • Таблицы и индексы ставятся в соответствие именованным кэшам
  • Уменьшается уровень конкуренции за ресурсы менеджера буферов
  • Можно управлять использованием памяти для баз данных, индексов и таблиц
  • Возможно назначение кэша для объекта во время исполнения
  • Оптимизатор учитывает особенности работы с множественными кэшами

    • Microsoft еще более расширила

    У SQL Server 6. 0 Microsoft еще более расширила возможности параллельной обработки
    симметричной архитектуры сервера. За счет параллельного выполнения широкого диапазона
    внутренних функций СУБД с использованием множественных потоков операционной системы при
    работе на многопроцесорных системах резко возрастает производительность и масштабируемость
    многих операций (таких как определенные типы запросов, сканирование таблиц, создание
    индексов, создание/восстановление страховочных копий, проверка целостности базы данных и
    т.д.).

    Установка максимального числа строк на странице

    При создании таблицы или индекса можно указать максимальное число строк, хранимых на
    странице данных или странице индекса. Эта возможность позволяет оптимизировать блокировки
    для часто обновляемых таблиц. SQL Server использует установленное значение при добавлении и
    удалении строк.


    Утилита Results

    Утилита Результаты - это средство доступа к данным и формирования отчетов для конечного
    пользователя, которое позволяет непрограммистам удовлетворять собственные потребности по
    обработке данных и создании отчетов. Утилита Результаты работает в режиме образца-подсказки
    при создании запросов и отчетов. Пользователь начинает работу с построения запроса к базе
    данных. Затем при помощи меню-управляемого интерфейса он создает запрос для выбора
    информации из базы, которую он хотел бы видеть в отчете.

    После того, как запрос определен, у пользователя имеется возможность просмотреть полученную
    информацию в различных форматах, включая:

  • Формы - выбранные данные отображаются по одной записи для
    детального изучения информации
  • Таблицы - данные отображаются в виде строк и столбцов, в формате
    сходном с форматом представления данных в электронных таблицах.
    Пользователь может просматривать данные, перемещаясь вперед или назад
    по этой таблице.
  • Отчеты - данные отображаются в виде отчета, с заголовками,
    сносками, итогами и т.д., определенными пользователем. Пользователи могут
    воспользоваться шаблонами отчетов, созданных разработчиками приложения,
    утилитой Результаты или Построителем Отчетов.
  • Наклейки - данные отображаются в одном из стандартных форматов
    для наклеек: конверты, складские наклейки и др.
  • Экспортирование - позволяет пользователю записать данные во
    внешний файл в различных форматах хранения данных.
    Так как сама утилита Результаты написана на языке 4GL PROGRESS, она является легко
    изменяемой и расширяемой, а также может быть легко включена в любое PROGRESS
    приложение


    Утилита Tools

    Когда Ваше приложение должно устанавливаться в различных местах, то сразу возникает ряд
    вопросов.

    Будет ли разрешено пользователям модифицировать имеющиеся процедуры и, возможно,
    добавлять новые?

    Будет ли разрешено пользователям изменять определения Словаря Данных?

    Есть ли необходимость поставлять обновленные версии приложения без повторной поставки всей
    системы?

    Утилита Tools содержит набор программ, предназначенных для упаковки и распространения
    приложений PROGRESS, включая программы для:

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


    Внешние функции хранимых процедур

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


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

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

    В случае SQLBase процедурным языком является SAL. Однако, как указывалось выше, язык
    хранимых процедур SQLBase все еще является подмножеством полного языка SAL, имеющегося в
    SQLWindows. Кроме того, многие пользователи SQLBase хотели бы иметь возможность создавать
    собственные процедуры, не будучи привязанными к какому-либо конкретному языку.

    Естественно, одним из способов расширения функциональности хранимых процедур SQLBase
    является расширение используемого подмножества языка SAL. Такой путь, однако, не дает
    возможности пользователям гибко добавлять компоненты и собственные функции для реализации
    дополнительной функциональности существующих систем. Поэтому процесс придания хранимым
    процедурам SQLBase большей "открытости" проводится по двум направлениям:


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

    Первым шагом на этом пути является поддержка в SQLBase нового типа объектов базы данных,
    называемого внешней функцией (External Function).

    Внешняя функция - это любая пользовательская функция, которая располагается в отдельной
    библиотеке (Dynamic Link Library или DLL для платформы Windows) и может быть динамически

    вызвана для выполнения из другой задачи. Функция может быть написана на любом языке,
    допускающем создание DLL. Единственным ограничением является требование использования в
    качестве параметров типов переменных, поддерживаемых SQLBase, и следование требованиям
    программного интерфейса.

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

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

    Применение внешних функций дает пользователям SQLBase следующие преимущества:


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

    Внешняя функция является новым объектом схемы базы данных SQLBase.


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

    CREATE EXTERNAL FUNCTION MyFunc
    PARAMETERS (Number: INT)
    RETURNS (BOOLEAN: WORD)
    DESCRIPTION 'Sample External Function Declaration'
    LIBRARY MYLIB.DLL
    EXPORT ORDINAL 2
    EXECUTE IN SAME THREAD
    Типы данных для параметров функции и возвращаемого значения состоят из двух частей. Сначала
    описывается "внутренний формат", соответствующий стандартным типам данных SAL. Могут
    быть использованы все типы данных SAL, которые поддерживаются хранимыми процедурами (см.
    выше). "Внешний формат", который следует за внутренним, описывает один из стандартных
    форматов C, который служит для передачи данных во внешнюю функцию.

    Предложение EXECUTE IN описывает как SQLBase будет загружать динамическую библиотеку и
    в каком контексте с точки зрения сервера базы данных будет выполняться внешняя функция. Это, в
    свою очередь, определяет тип операций, которые могут осуществляться внутри внешнего
    кода.

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


  • Набор пользовательских функций трансформации и трансляции данных,
    которые могут быть использованы при извлечении строк из результата запроса,
    а также при вставке и изменении строк. Функция такого типа может принимать
    значение одной (или нескольких) колонки и возвращать трансформированные
    данные на основе действующих в организации правил (business rules) для
    отображения в приложении.
  • Следующая категория функций может быть названа "Предупреждения и
    уведомления". Их суть состоит в том, что при наступлении определенного
    состояния базы данных могут запускаться триггеры. Эти триггеры выполняют
    хранимые процедуры. Может оказаться полезным уведомлять некоторых


    пользователей или приложения о наступлении определенного состояния базы
    данных. Одним из примеров такого типа функций может быть функция,
    направляющая по электронной почте сообщение определенным
    пользователям о том, что данные в созданных ими таблицах были изменены
    другими пользователями. С помощью этих же функций можно в принципе
    реализовать механизм "теплой связи", когда пользователь будет получать
    уведомления от сервера всякий раз, когда будут изменены данные его result
    set.
  • Еще одной иллюстрацией возможностей технологии внешних функций
    может являться пример удаленного доступа для запуска хранимых процедур.
    Например, приложение может вызвать хранимую процедуру на локальном
    сервере SQLBase, чтобы получить доступ к некоторым данным. Однако,
    хранимая процедура может содержать логику, распознающую ситуацию когда
    требуемые данные на сервере отсутствуют или являются устарелыми. В таком
    случае использование внешней функции поможет установить контакт к
    удаленной базе данных и извлечь нужные данные. Эти данные затем могут
    быть занесены в локальную базу данных и возвращены приложению.
  • Другим классом внешних функций могут быть генераторы отчетов в режиме
    off-line. При этом вместо запуска приложения отчетов с клиентской машины
    весь модуль (или набор функций) может быть создан в виде динамической
    библиотеки, которая вызывается из хранимой процедуры как внешняя функция.
    Код этой функции может осуществлять контакт с базой данных и извлекать
    нужные для генерации отчета данные. Основным преимуществом такого
    подхода является повышение производительности, поскольку весь код будет
    выполняться на сервере без передачи данных и команд по сети.

    Многие ведущие производители СУБД включают поддержку вызова внешних функций из серверов
    баз данных. Некоторые из них поддерживают только вызовы внешних функций с помощью
    расширений процедурных языков ( в качестве примеров можно привести Microsoft SQLServer для
    NT и Sybase). Другие допускают вызов функций также из SQL запросов.К таким система
    относятся Oracle 7 и Rdb. В последующих версиях SQLBase. фирма Gupta планирует реализовать
    несколько механизмов вызова внешних функций, включая их использование в выражениях SQL
    запросов (сейчас в этих целях используются встроенные функции SQLBase).

    Возможности интеграции и направления развития

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


    Введение в PowerBuilder

    PowerBuilder включает набор инструментов, обеспечивающих всестороннюю поддержку разработки
    приложений: Интеллектуальный SQL (SQL Smart), Удобные объекты (Object Easy),
    Коллективную разработку (Enterprise Enabled) и Интегрированную среду проектирования
    (Developer Designed).


    Распределенные базы данных невозможно рассматривать

    Распределенные базы данных невозможно рассматривать вне контекста более общей и более
    значимой темы распределенных информационных систем. Процессы децентрализации и
    информационной интеграции, происходящие во всем мире, неизбежно должны рано или поздно
    затронуть нашу страну. Россия, в силу своего географического положения и размеров "обречена"
    на преимущественное использование распределенных систем. На мой взгляд, это направление
    может успешно развиваться лишь при выполнении двух главных условий - адекватном развитии
    глобальной сетевой инфраструктуры и применении реальных технологий создания распределенных
    информационных систем.

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

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

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

    Поведение и мотивация разработчиков вполне понятны и оправданы. Ставится задача - построить
    информационную систему "клиент-сервер" на базе локальной сети с централизованной базой
    данных.

    В последнее время технология клиент- сервер стала темой номер один в компьютерном мире.
    Многие склонны считать это скорее модой, чем объективной тенденцией развития
    информационных технологий. Однако, нельзя отрицать тот факт, что на сегодняшний день именно
    в технологии клиент-сервер нашли и находят свое отражение наиболее передовые идеи и решения,
    которые будут доминировать на рынке в 90-е годы нашего столетия, да и в начале следующего
    тысячелетия.

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

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

    Данная статья посвящена одному из ярких представителей сегодняшней технологии клиент-сервер
    - реляционной СУБД SQLBase фирмы Gupta Corporation. Эта СУБД завоевала широкое признание
    во всем мире и у нас в России, где за полтора года было продано почти полторы тысячи серверов
    SQLBase для различных платформ.

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

    BM Database 2 представляет собой реляционную систему управления базами данных. Она
    позволяет пользователям работать с реляционными данными, используя язык структурных
    запросов SQL. Первая реализация этой СУБД появилась в 1983 году для операционной системы
    MVS , и впоследствии была перенесена на многие другие платформы. Еще
    более широкую популярность приобрел введенный в DB2 язык SQL, являющийся в настоящий
    момент общепринятым для работы с реляционными базами данных в архитектуре
    клиент/сервер.

    Изначально разработанная для работы с коммерческими данными, DB2 завоевала сильные
    позиции на рынке реляционных СУБД как весьма стабильная система, пригодная для
    автоматизации организаций любого масштаба.

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

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

    Основу CASE-технологии и инструментальной среды фирмы ORACLE
    составляют:


  • методология структурного нисходящего проектирования, при которой
    разработка прикладной системы представляется в виде последовательности
    четко определенных этапов (рис.1);
  • поддержка всех этапов жизненного цикла прикладной системы, начиная с
    самых общих описаний предметной области до получения и сопровождения
    готового программного продукта;
  • ориентация на реализацию приложений в архитектуре "клиент-сервер" с
    использованием всех особенностей современных серверов баз данных,
    включая декларативные ограничения целостности, хранимые процедуры,
    триггеры баз данных, и с поддержкой в клиентской части всех современных
    стандартов и требований к графическому интерфейсу конечного пользователя;.
  • наличие централизованной базы данных, репозитария, для хранения
    спецификаций проекта прикладной системы на всех этапах ее разработки.
    Такой репозитарий представляет собой базу данных специальной структуры,
    работающую под управлением СУБД ORACLE;
  • возможность одновременной работы с репозитарием многих
    пользователей. Такой многопользовательский режим почти автоматически
    обеспечивается стандартными средствами СУБД ORACLE. Централизованное
    хранение проекта системы и управление одновременным доступом к нему всех
    участников разработки поддерживают согласованность действий
    разработчиков и не допускают ситуацию, когда каждый проектировщик или
    программист работает со своей версией проекта и модифицирует ее
    независимо от других;
  • автоматизация последовательного перехода от одного этапа разработки к
    следующему. Для этого предусмотрены специальные утилиты, с помощью
    которых можно по спецификациям концептуального уровня (модели
    предметной области) автоматически получать первоначальный вариант
    спецификации уровня проектирования (описание структуры базы данных и
    состава программных модулей), а по последним после всех необходимых
    уточнений и дополнений автоматически генерировать готовые к выполнению
    программы;
  • автоматизация различных стандартных действий по проектированию и
    реализации приложения: предусматривается генерация многочисленных
    отчетов по содержимому репозитария, обеспечивающих полное
    документирование текущей версии системы на всех этапах ее разработки; с
    помощью специальных процедур предоставляется возможность проверки
    спецификаций на полноту и непротиворечивость и т.д.


    СтратегияАнализПроектированиеРеализацияДокументированиеВнедрениеПоддержка


    Продукт S- Designor фирмы Powersoft адресован разработчикам информационных
    систем. Это графический инструмент для проектирования структуры реляционных баз данных. S-
    Designor реализует популярную методологию информационного моделирования, основанную на
    представлении информационных объектов и взаимосвязей между ними в виде ER-диаграммы
    ("сущность-связь"). Используемая в S-Designor нотация - IE (Information Engineering).

    В S-Designer эффективно реализована связь как со множеством современных СУБД, так и со
    средствами разработки приложений. По завершении разработки модели данных S-Designor
    генерирует пакеты SQL-предложений для широкого набора СУБД, включая Oracle, Ingres,
    Informix, Sybase, RDB, SQL Server, DB2, AS/400, SQLBase, Access и Paradox. Имеется
    встроенный ISQL. Для поддерживаемых СУБД автоматически генерируются триггеры,
    обеспечивающие ссылочную целостность. Предусмотрена возможность редактировать хранимые
    процедуры непосредственно при подготовке физической модели. Для обеспечения сопровождения
    существующих систем S-Designor позволяет проводить восстановление модели по структуре
    базы данных (БД). В течение всего цикла разработки модели данных ( Рис. 1) с помощью S-
    Designor могут быть получены разнообразные отчеты по модели.

    На этапе проектирования модели данных S-Designor дает возможность определить элементы
    пользовательского интерфейса будущих приложений, работающих с проектируемой базой данных.
    Это достигается редактированием репозиториев систем 4GL. В качестве средств разработки
    поддерживается PowerBuilder , TeamWindows,
    Progress, Uniface и другие.

    S-Designor работает в среде Microsoft Windows и Windows NT. Для
    его использования достаточно компьютера с процессором 386SX и объемом памяти от 4
    мегабайт. В S-Designor присутствуют элементы, характерные для программ редактирования -
    линейка инструментов, интерфейс " drag-and-drop", импорт/экспорт графических файлов,
    инструменты для создания стандартных графических элементов, управление цветом и шрифтовым
    выделением.

    При работе с S-Designor сразу заметны очень высокая скорость отрисовки диаграммы и
    эффективная реализация интерфейса к СУБД.

    Развитые средства быстрого редактирования объектов модели и достаточно полный набор средств
    управления расположением объектов на диаграмме - характерные черты, делающие S-
    Designor особенно привлекательным.

    Высокоскоростное создание/восстановление страховочных копий

    Высокоскоростное создание/восстановление страховочных копийСоздание/восстановление страховочных
    копий теперь может выполняться почти на порядок быстрее за счет использования одновременно
    до 32 устройств (диски или стриммеры), на которых создается страховочная копия базы данных.
    Специалистами Microsoft была достигнута производительность копирования более 20 Гб/час. Это
    означает, что при работе с большими и очень большими БД страховочная копия может быть
    создана в нерабочие часы. Теперь же использование новых возможностей SQL Server позволяет
    работать с базами данных 100 Гб и выше на соответствующим образом конфигурированных
    компьютерных системах. Это отвечает требованиям организаций, устанавливающих большие базы
    данных на относительно дешевых компьютерных системах.


    CASE представляет собой интегрированный программный

    (CADRE Technologies Inc.)

    Westmount I- CASE представляет собой интегрированный программный продукт, обеспечивающий
    выполнение следующих функций:


  • графическое проектирование архитектуры системы (проектирование
    состава и связи вычислительных средств, распределения задач системы
    между вычислительными средствами, моделирование отношений типа "клиент-
    сервер", анализ использования мониторов транзакций и особенностей
    функционирования систем в реальном времени);
  • проектирование диаграмм потоков данных, "сущность-связь", структур
    данных, структурных схем программ и последовательностей экранных форм;
  • генерация кода программ на 4GL целевой СУБД с полным обеспечением
    программной среды и генерация SQL-кода для создания таблиц БД, индексов,
    ограничений целостности и хранимых процедур;
  • программирование на языке C со встроенным SQL;
  • управление версиями и конфигурацией проекта;
  • генерация проектной документации по стандартным и индивидуальным
    шаблонам;
  • экспорт и импорт данных проекта в формате CDIF.

    Westmount I-CASE можно использовать в конфигурации "клиент-сервер", при этом база
    проектных данных может располагаться на сервере, а рабочие места разработчиков могут быть
    клиентами.

    Westmount I-CASE функционирует на всех основных UNIX-платформах и VMS. В качестве
    целевой СУБД могут использоваться ORACLE, Informix, Sybase и Ingres.

    В качестве отдельного продукта поставляется интерфейс Westmount-Uniface Bridge,
    обеспечивающий совместное использование двух систем в рамках единой технологической среды
    проектирования (при этом схемы БД, структурные схемы программ и последовательности
    экранных форм непосредственно в режиме on-line, без создания каких-либо файлов экспорта-
    импорта, переносятся в репозиторий Uniface, и, наоборот, прикладные модели, сформированные
    средствами Uniface, могут быть перенесены в репозиторий Westmount I-CASE. Возможные
    рассогласования между репозиториями двух систем устраняются с помощью специальной
    утилиты).

    В рамках версии Westmount I-CASE 4.0 предполагается обеспечить возможность
    функционирования клиентской части в среде Windows 95, а серверной - в среде Windows NT.

    WSQL DDE-сервер

    Dynamic Data Exchange (DDE) - это метод взаимодействия приложений. DDE использует
    архитектуру клиент-сервер. Так, приложение-клиент (например, Excel или Word) может
    запрашивать данные у приложения-сервера.

    WSQL DDE-сервер - это Windows-приложение, которое позволяет выбирать и изменять данные в
    БД SQL Anywhere. Получаемые данные могут передаваться приложению-клиенту через буфер в
    памяти или через системный буфер (Clipboard).


    Запуск (Run)

    Щелчок левой кнопкой мыши на пиктограмме Run (запуск) приведет к запуску текущего приложения
    в среде разработки PowerBuilder для проверки его функциональности.


    Защита данных и поддержка работы

    Возможность аудирования, новое свойство SQLBase 6, позволяет регистрировать информацию о
    том, что происходит на сервере баз данных. Это дает возможность администраторам и
    пользователям SQLBase осуществлять следующие дополнительные функции:


  • Мониторинг активности сервера баз данных - Регистрация разнообразной
    информации на регулярной основе.
  • Дополнительные возможности защиты данных - Предыдущие версии
    SQLBase осуществляли защиту данных на уровне имени и пароля
    пользователя, однако не регистрировали попытки нарушить систему защиты.
    Аудирование позволяет регистрировать такие случаи как попытки доступа к
    базе данных с неправильным именем или паролем. Кроме того, есть
    возможность регистрировать попытки нарушения пользователем его
    привилегий по отношению к объектам базы данных, например, попытки считать
    информацию из закрытых для него таблиц.
  • Отладка приложений - Можно использовать аудирование для отладки
    конечных приложений путем просмотра того, какие действия приложение
    осуществляет по отношению к базе данных и серверу.
  • Повышение производительности базы данных - Аудирование базы данных
    позволяет получить информацию обо всех SQL запросах и транзакциях. Это
    свойство можно использовать непосредственно на рабочем месте
    пользователя для решения проблем типа "Я нажимаю вот эту кнопку и потом
    жду 20 минут выполнения запроса". Поскольку аудирование предоставляет
    временную информацию о выполнении запросов, его можно использовать для
    анализа причин снижения производительности конечных приложений.

    Существует два класса аудирования: глобальный аудит и аудирование производительности. В
    свою очередь, каждый из классов состоит из нескольких категорий описание этих категорий
    приведено на рис. 6.

    Класс
    Категория
    ОписаниеGlobal
    Performance
    Rejected logons
    		Регистрирует неудавщиеся
    попытки контакта с базой данных. Используется для
    идентификации пользователей, которые пытаются
    получить доступ к закрытым базам
    данных.
    Security violations
    		Регистрирует
    пользователей, пытающихся получить доступ к
    данным не имея соответствующих
    привилегий.
    Valid logons/logoffs
    		Регистрирует все
    удавшиеся события соединения и отсоединения.
    Используется для регистрации сеансов работы
    пользователей с системой.
    Valid
    connects/disconnects
    		Регистрирует все команды
    CONNECT и DISCONNECT.
    Database create,
    drop, install and deinstalls
    		Регистрирует выполнение
    операций CREATE DATABASE, DROP DATABASE,
    INSTALL DATABASE и DEINSTALL
    DATABASE.
    Recovery
    operations
    		Регистрирует все операции
    ROLLBACK.
    Backup and restore
    operations
    		Регистрирует все операции
    BACKUP и RESTORE.
    Database deadlocks
    and timeouts
    		Записывает информацию о
    всех событиях deadlock и timeout. Очень важная
    категория, которая может быть использована для
    разрешения проблем блокировок.
    Table access
    information
    		Регистрирует информацию
    о том, кто реализует доступ к таблицам базы
    данных.
    Table update
    information
    		Регистрирует информацию
    о том, кто выполняет операции insert/update/delete по
    отношению к таблицам базы данных.
    Connects and
    disconnects
    		Регистрирует время
    выполнения каждой операции
    connect/disconnect.
    SQL command
    compilation, execution, storage and retrieval
    		Эта категория
    регистрирует информацию о времени компиляции и
    выполнения запроса, записи и извлечения хранимой
    команды или процедуры.
    End of transaction
    		Регистрирует
    длительность каждой транзакции. Может
    использоваться для выявления долго идущих
    транзакций, которые могут являться источниками
    deadlock и timeout.
    <
    Информация аудирования записывается в файл аудита. Файл аудита является плоским текстовым
    файлом. Его содержимое можно просматривать из программы SQLConsole или в любом текстовом
    редакторе.

    Хотя SQLBase позволяет иметь до 32 активных файлов аудита одновременно, следует помнить, что
    аудирование оказывает влияние на производительность сервера.

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

    Процесс аудирования базы данных инициируется на уровне сервера. Это значит, что для запуска
    процесса аудирования необходимо иметь соединение с сервером. Аудирование можно начать
    несколькими различными способами. Наиболее удобным является использование программы
    SQLConsole. Окно Audit Manager этой программы позволяет просто и удобно сконфигурировать
    аудирование, запустить и остановить его, а также просмотреть любой активный файл аудита из
    имеющихся на сервере.

    Можно также запустить процесс аудирования новой командой на языке SQL START AUDIT. Так
    как эта команда, подобно всем другим SQL запросам, может быть скомпилирована и выполнена,
    START AUDIT можно выполнить из приложений SQLWindows с помощью функций SqlPrepare,
    SqlExecute или SqlPrepareAndExecute.

    После запуска процесса аудирования он остается активным до получения специальной команды
    STOP AUDIT. SQLBase записывает строку в конфигурационный файл сервера, и эта строка
    остается там все время, в течение которого аудирование является активным. Таким образом, если
    сервер SQLBase сбрасывается и запускается снова, все активные файлы аудита остаются
    активными.

    []
    []
    []