Центральная тема номера - "Проектирование Информационных Систем". Первоначально рассматривавшийся вариант темы был уже: "Проектирование баз данных". Однако приходящие в редакцию статьи и беседы с их авторами подтвердили давно известное: проектирование БД находится в теснейшей взаимосвязи с разработкой Информационной Системы в целом, и, естественно, большинство статей выходили за первоначально предполагавшиеся рамки.
Нужно обратить внимание еще на одну сторону дела. Если предметом рассмотрения является проектирование (БД или ИС), центральной фигурой становится не инструмент, а проектировщик. Конечно, важно обмениваться опытом использования программных инструментов, обсуждать общие и частные методики. Но при проектировании конкретного "изделия" на первый план выходит другое: как сделать работоспособную и полезную систему в реальных условиях? А это есть условия: несовершенства СУБД, CASE-систем, систем программирования и т.п.; неполноты, неуниверсальности или излишней громоздкости методик проектирования; ограничений реальных возможностей команды разработчиков, аппаратной базы; и многие другие ограничения, имеющиеся в конкретном проекте.
Может быть, ремесло и искусство проектирования и состоит в том, чтобы вооружиться лучшими - но для данного проекта - из реально доступных средств и реализовать требования к БД или ИС, преодолевая объективные ограничения инструментов, методов и других ресурсов.
Представляется, что статьи данного номера журнала несут читателю ценную информацию на эту тему. Правда, "коллекция" таких статей хуже поддается простому разделению на классы, как это было сделано в обзоре темы 3-го номера "СУБД" за прошлый год: отдельно CASE, отдельно 4GL, отдельно их сравнение. По этой причине далее статьи обсуждаются в некотором "слабом" порядке, предпочтительно от описаний комплексных проектов к отдельным вопросам применения инструментов или методов проектирования.
Наиболее всестороннее описание опыта проектирования крупной ИС представляет статья О.М. Москаленко "Опыт проектирования и разработки банковской системы для трехуровневой архитектуры "клиент-сервер". Особая направленность этой статьи: приемы проектирования БД и прикладных программ, составляющих систему, работающую под управлением монитора транзакций TUXEDO. Автор сознательно не акцентирует внимание на вопросах проектирования БД, показывая свое представление о том, какое место занимает этот вопрос среди других проблем. Много внимания уделено вопросам программной и коммуникационной архитектуры ИС. Система реализована на Ingres, но разработчики описывают решения, позволяющие облегчить ее перенос на Informix или Oracle. Интересен раздел "Организация работы". Полезно, что изложение ведется от описания требований к системе (в том числе специфически банковских) к приемам их реализации. В отношении проектирования БД: проектировщики отказались от ряда обычно рекомендуемых средств и приемов (нормализация таблиц данных, включение поддержки ограничений целостности БД в схему через триггеры). Дальнейший пересказ был бы так же вреден, как сообщение имени преступника в начале детектива Агаты Кристи. Главное: автор ясно формулирует именно свою позицию (несомненно интересную), объясняет ее и предупреждает об ограниченности области ее применения.
Следующей статьей, отражающей комплексные вопросы проектирования на примерах реальных систем, является статья С.А. Синягова "Построение и проектирование баз данных. Интеграция инструментов и интерфейсов". Хочется предупредить читателя: на первый взгляд, текст может произвести впечатление некоторого перечисления программных продуктов, но важно увидеть в нем другое. В лаконичном тексте, почти в форме тезисов, сформулированы оценки и решения, часто - не тривиальные, принятые в двух различных проектах. Первый - ИС торгового офиса. Использованы инструменты СУБД Informix и ориентированные на нее. Используется CASE-система Vantage Team Builder, которая характеризуется автором как обладающая большой степенью открытости и настраиваемости. В отличие от предыдущей статьи, активно применяются триггеры и хранимые процедуры. Второй проект - ИС широкого пользования для работы с различными данными о растениях. Описывается погружение ИС в среду Internet, опыт столкновения с ограничениями при разработке пользовательского интерфейса в версии для WWW. Как основное средство программирования использован C++. Отмечена оправданность подхода, соединяющего структурные методы проектирования с объектно-ориентированными средствами реализации. К сожалению, по многим вопросам изложение слишком лаконично и не содержит объяснения некоторых важных оценок, например описания параметров и стандартов, по которым VantageTeam Builder признается открытым инструментом.
Статья Кима Е.К., Шабаева И.Г., Бычкова В.А. "Проектирование трехмерных баз данных в СУБД uniVerse" содержит характеристику подхода к использованию особенностей модели данных этой СУБД в реальных проектах. Известно, что эта модель данных со времени появления PIC-системы предусматривает наличие в файлах данных повторяющихся полей и групп. В статье описывается расширение SQL, позволяющее работать с такими ненормализованными таблицами (непервая нормальная форма NF2) - определять схему БД, писать запросы. Использованные в статье примеры и иллюстрации относятся к фрагментам реализации ИС контроля и управления торговым домом. Указываются не только преимущества, полученные за счет применения NF2, но и другие, основанные, например, на малой ресурсоемкости uniVerse. В отношении проектирования БД: авторы указывают, что использование т.н. "постреляционной медели данных uniVerse" позволяет более гибко выбирать не только структуру БД, но и методы решения задач в подсистемах ИС. В частности, оказалось рациональным использовать мемориально-ордерную систему бухгалтерского учета, что основано на хранении "электронных накладных", содержащих все данные, связанные с одной операцией учета, в единственной таблице (что не получается при применении двумерных реляционных таблиц).
А.А. Сахаров назвал свой материал "Принципы проектирования и использования многомерных баз данных (на примере Oracle Express Server)". Материал имеет отношение к проблематике OLAP и DataWare House. Его можно рекомендовать и как введение в проблематику проектирования аналитических систем обработки данных (СОД). Это - достаточно насыщенный текст, содержащий описание и внешних потребностей, диктующих требования к реализации, и внутренних различий СОД разных классов. Определяются и иллюстрируются элементы многомерных моделей (гиперкубической и поликубической): ячейка, срез и др. Описываются операции манипулирования измерениями, способы определения иерархических отношений между ними. На этой основе описываются элементы подхода к проектированию многомерной БД (МБД). Читатель может получить практически полезную ориентацию: с чего ему надо начинать проектирование, какую информацию собирать, какие факторы ограничений многомерной модели учитывать? Приводятся тексты конкретной схемы МБД, процедур анализа и выдачи отчетов на языке Express Server. Обсуждается пример загрузки данных из реляционного источника в показатель МБД. Следующие три статьи относятся к более локальным, но без сомнения важным вопросам.
Первая из них - А.И. Громов, М.С. Каменнова, А.Н. Старыгин, "Создание электронного архива и реорганизация бизнес-процедур компании" - относится к тому аспекту проектирования, который может быть назван "Функциональный анализ и автоматизация существующей рутинной деятельности". Предложена и описана в качестве типовой последовательность действий по построению локальных функциональных моделей деятельности на предприятии, т.н. "бизнес-процедур", разработка показателей эффективности их выполнения, анализ применения тех или иных средств автоматизации (в данном случае - на примере электронного архива) и их влияние на эффективность выполнения процедур. На основе выбора конкретного варианта автоматизации строится измененная бизнес-процедура. В статье есть указание на то, что изложено представление авторов об излагаемом предмете. В связи с этим нужно отметить, что предложенный план анализа и проектирования вряд ли правомерно считать планом реконструкции бизнес-процессов, или даже реорганизации бизнес-процедур. В разбираемом примере специально накладываются ограничения (даже запреты) на поиск мало-мальски кардинальных усовершенствований деятельности как таковой. По сути, ищется та точка в рутинной "бумажной" работе, автоматизация которой даст зримый эффект сокращения затрат времени без изменения метода работы по существу. Известны ограниченность, а иногда и вред этого подхода, поскольку он не направлен на повышение эффективности управления предприятием как объектом. По подобным причинам покупка, доработка (адаптация) и эксплуатация электронного архива, к тому же - добавление персонала для централизованного управления согласованием документов (как это предлагается в статье) в условиях конкретных предприятий могут многократно повысить их непродуктивные затраты. Может - в конкретных условиях - оказаться гораздо дешевле и даже эффективней по другим параметрам нанять еще 2-х - 4-х архивных работников. С этой точки зрения, вряд ли можно рекомендовать предложенный план в качестве типового при реорганизации системы управления на предприятии или разработке ИС.
Вместе с тем статья полезна как пример применения техники ABC (Activity Based Costing) - стоимостного функционального анализа - в простейших его вариантах.
"Аномалии в реляционных базах данных" А.О. Голосова - это возвращение проектировщиков БД к истокам вопросов о существовании и проектировании "хороших" схем баз данных. Почему какую бы индустриальную РСУБД вы ни использовали в мало-мальски сложных случаях, не удается получить идеальной - хотя бы только на логическом уровне - схемы БД? Какие факторы определяют это? Как они проявляются в концептуальной схеме и как - в схеме БД? Что делать, чтобы распознать появляющиеся противоречия? И, наконец, что необходимо, чтобы формировать своды правил для получения хороших схем? Отталкиваясь от предложений Р. Фейджина, автор формулирует сначала содержательное неформальное определение аномалии, как противоречия между концептуальной схемой предметной области (ПрО) и схемой БД, а затем - определения аномалий первого и второго рода, объединение которых задает строгую формулировку для обсуждаемых коллизий. В заключение приводится последовательность действий по разработке методики построения хорошей схемы БД для конкретной пары "концептуальная модель - модель данных конкретной СУБД". Однако хочется надеяться, что проектировщики БД и до реализации такой программы действий в ее полном объеме могут извлечь из статьи практическую пользу, если, отталкиваясь от самых общих содержательных положений, будут в процессе моделирования и проектирования сознательно вычленять из описания концептуальной схемы нереализуемые в модели данных СУБД ограничения ПрО, документировать их и решать проблему их реализации другими, но явно контролируемыми средствами с прогнозируемыми последствиями.
Статья О.В. Чикало "Применение SQL-Bench для тестирования серверной части клиент-серверных приложений" возвращает к незаслуженно забытым проблемам физического проектирования БД, их настройки (тьюнинга), настройки соответствующих слоев архитектуры всей ИС. Десять и пятнадцать лет назад эта тематика была достаточно популярна, в первую очередь - для систем и БД на ЕС ЭВМ. Затем, в эпоху общего downsizing, эти вопросы, казалось бы, потеряли актуальность. После возврата к большим многопользовательским ИС проблема могла бы встать сразу, но на время она была сглажена двумя факторами. Во-первых, рост размера БД некоторое время отставал от роста доступного объема стремительно дешевеющей дисковой памяти. Во-вторых, переход на SQL-серверы упростил физическую реорганизацию БД при наличии свободной памяти на дисках. Казалось, спроектируй размещение БД "по умолчанию", а когда возникнут задержки, поэкспериментируй параметрами размещения, переписывая базу в режиме разгрузки-перезагрузки. Однако эти времена для одних ИС уже кончились, для других - кончаются. Именно в этом контексте полезна статья О.В. Чикало, представляющего инструмент натурного моделирования режимов многопользовательского доступа к БД, точки и цели его применения при проектировании системы с SQL-базами данных.
Несколько слов о публикации материала Е.З. Зиндера "Проектирование баз данных: новые требования, новые подходы". Печатается изложение доклада автора на конференции "Корпоративные базы данных" (март 1996 г.). Публикация преследует две основные цели: 1) показать границы применимости классических методов проектирования БД; 2) отметить направления новых подходов в проектировании. Особенность ситуации состоит в том, что новые требования остры, а ожидать появления новой законченной методологии нет возможности, а может быть, на ближайшие годы нет и оснований. Надо определять (искать, разрабатывать) перспективные методы и использовать их, хотя бы частично, в соответствующих позициях реальных проектов. С этой целью рассматриваются новые подходы в организации проектирования БД, в общих архитектурных принципах построения корпоративных БД, некоторая совокупность новых подходов в методах проектирования БД. В последних формулируются: ограничения принципа исключения избыточности при проектировании БД, подходы к уменьшению консервации проблем предприятий в корпоративных БД, аспекты компонентной открытости и смысловой интероперабельности ИС и БД, необходимость опоры на понятийные модели, проблемы физического проектирования БД.
Используется термин "смысловая интероперабельность", в отличие от привычной "семантической". С одной стороны, в русском языке семантика, смысл и значение определены как синонимы (см. словарь Ожегова). С другой стороны, есть необходимость различать различные аспекты значения данных, которые становятся актуальными в зависимости от интерпретатора и его ситуации. В общем же случае определение согласующейся с конкретной потребностью информации может производиться именно ситуативно. Поэтому методически полезно говорить о конкретном, актуальном в частной ситуации смысле, в котором из содержания БД вычленяется лишь часть потенциально и вероятно существующего значения, о том смысле, который эта БД или ее часть в конкретном акте обмена информацией имеет или приобрело для человека: для пользователя, для хозяина ИС и БД.
Наконец, как актуальное положение формулируется необходимость определения границ применимости двух концепций: 1) проектирование БД как предмета, осознанно отделенного от прикладных программ и других текущих методов их интерпретации; 2) объектно-ориентированное проектирование, в котором объект инкапсулирует и данные, и методы их обработки.
В заключение обзора хочется обратить внимание читателей на то, что представленные публикации и сам этот обзор уже традиционно оставляет место для других мнений и дискуссий.