Связи в реляционной модели

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

Проектирование модели в 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);
Утилиты динамического администрирования БД, обеспечивающие
следующие функции:
отслеживание динамики показателей эксплуатации БД: показатели
доступны в любой момент на фоне работы приложений, эти показатели
("статистика") могут использоваться для поддержки оптимального
динамического построения путей доступа к данным,
создание резервных копий БД, также как и ведение копий БД
горячего резерва на фоне работы приложений, восстановление и откат
фрагментов и полной БД,
возможна динамическая реорганизация БД (переразмещение БД и
отдельных физических фрагментов, логическая и физическая
реструктуризация данных), однако, эти возможности являются
ограниченными.
Учет пользовательских требований к представлению данных в большем
диапазоне, чем ранее. Требования к учету специфики представлений часто
стали преобразовываться из положений желательности наличия разных
внешних моделей данных к положению доступности значительного числа
пользовательских инструментов, имеющих различные интерфейсы и,
практически, различные внешние модели данных.

Методология проектирования от данных

Моделирование в 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).

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

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

Обеспечение максимальных возможностей для каждого работника, то есть
поддержка выполнения всех бизнес-функций тем самым работником, который
и получает конечный результат. Со стороны ИС, БД и СУБД для этого
требуется:
обеспечение средств доступа ко всем необходимым данным с
использованием распределенных БД, средств репликаций данных,
управления событиями в данных и процессах обработки транзакций;
использование архитектуры и программных средств хранилища
данных, средств Оперативной Аналитической Обработки Данных (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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как ответ на новые требования можно рассмотреть рекомендации к новым методам и
инструментам проектирования БД. (Конечно, в предположении, что все новое есть ранее кем-то
уже обнаруженное старое.)

в условиях Нового Системного Проектирования

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 - системы.