CA-Open Ingres как Открытая Система

Г. М.Ладыженский

Oracle CIS, (+7 095) 258-41-80 glodigen@ru.oracle.com

Введение

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

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

Предлагаемая статья представляет собой попытку взглянуть с этой точки зрения на одну из реляционных СУБД, представляющую собой дальнейшее развитие известной системы Ingres. Речь пойдет о системе управления базами данных CA-OpenIngres, которая в настоящей момент является продуктом крупнейшей мировой корпорации Computer Associates (что объясняет происхождение приставки в названии системы). Она была анонсирована в начале 1994 года ее прежним владельцем - корпорацией ASK Group и получила новый импульс в развитии, став собственностью Computer Associates.

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

Тем не менее, имеет смысл говорить о следующих ее аспектах:

• переносимость;
• межоперабельность;
• расширяемость;
• масштабируемость;
• интернационализация

Ниже они будут рассмотрены на примере СУБД CA-OpenIngres.

1. Переносимость

Переносимость (портируемость - portability) - это такое разделение программной системы и ее операционного окружения, которое позволяет без существенных изменений перенести программу в другое операционное окружение [1].

Переносимость может рассматриваться в трех аспектах.

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

Мобильный сервер базы данных необходим в ситуациях, когда разработка и эксплуатация прикладной программной системы осуществляется на различных платформах, для вертикального или горизонтального масштабирования (о масштабируемости будет сказано ниже), а также в распределенной информационной системе, где может быть несколько узлов на базе разнородных платформ, но гарантировано абсолютно идентичное поведение сервера на всех этих узлах. СУБД CA-Ingres - мобильная система, одна из лидеров по числу поддерживаемых платформ (более 50). Традиционная операционная среда CA-Ingres - различные версии ОС UNIX для компьютеров множества поставщиков (Amdahl, Bull, Cray, DEC, HP, IBM, ICL, Motorola, NCR, Sun, Silicon Graphics, Sequent, Unisys), в том числе версии ОС UNIX для компьютеров на базе процессоров Intel 386/486, Pentium (SCO UNIX, UnixWare, Solaris 2.4), а также операционная среда VAX VMS и OpenVMS. В последние годы в этот перечень вошли операционные системы Novell NetWare, OS/2, Windows NT. На момент, когда пишутся эти строки, доступна бета-версия CA-OpenIngres на пяти ведущих платформах - DEC, HP, IBM (IBM RS/6000), ICL, Sun. Они же составляют группу платформ, на которых первоначально (Q2Y95) будет функционировать CA-OpenIngres Release 1.1.

В сферу ответственности коммуникационных средств включается обеспечение прозрачности расположения, прозрачности сети, автоматической перекодировки данных при передаче по сети. В CA-OpenIngres прозрачность расположения достигается за счет использования виртуальных имен узлов, управление которыми осуществляет сервер имен (name server), который адресует запросы клиентов серверам. В то же время CA-OpenIngres поддерживает нормальное взаимодействие клиентов и серверов практически в любой операционной и сетевой среде, объединяющей разнородные компьютеры. Коммуникационный сервер CA-OpenIngres/Net поддерживает большинство промышленных протоколов обмена данными (TCP/IP, DECnet, SNA, SPX/IPX, NetBIOS, асинхронный). Кроме того, он же решает задачу согласования форматов представления данных на клиенте и сервере (разрядность, порядок следования байт в слове и т.д.) и обеспечивает перекодировку символов при передаче по сети, если кодировки на клиенте и сервере не совпадают. Все эти возможности также отражают качество мобильности, поскольку означают полностью прозрачный доступ к данным независимо от того, на каких узлах сети они располагаются.

Потребительское качество мобильных приложений очевидно. Возможна, например, разработка прикладной программы в операционной системе Solaris 2.x (оконная графическая среда X Windows) на рабочих станциях Sun с последующим переносом на персональные компьютеры под управлением MS Windows. Средства разработки прикладных программ для CA-OpenIngres представляет среда для быстрой разработки приложений CA-OpenROAD [2], которая разработана на базе CA-Ingres/Windows4GL. CA-OpenROAD позволяет проектировать схемы баз данных Ingres и генерировать исходные коды приложений на объектно-ориентированном языке четвертого поколения Ingres/Windows4GL. Он используется в рамках CA-Ingres/Windows4GL - графической оконной среды для разработки и запуска приложений с GUI. В числе ее полезных характеристик отметим возможность вызова из приложений процедур и функций, разработанных на языках C, Ada, Pascal, FORTRAN. Созданное в среде Ingres/Windows4GL приложение мобильно как в смысле операционной системы (UNIX, VAX VMS, OS/2, Windows NT, MS Windows), так и в смысле оконной графической среды (различные реализации X Windows, MS Windows) и стандарта GUI (OSF/Motif, OpenLook). Для переноса приложения в другую операционную среду требуется только компиляция его кодов на соответствующей платформе. Возможные проблемы переноса ограничиваются согласованием размеров и расположения окон и метрик шрифтов. Для запуска приложения на любой платформе необходим компонент CA-Ingres/Windows4GL Runtime.

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

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

Для СУБД оно может означать следующее.

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

Во-вторых, качество сервера базы данных, которое позволяет ему выступать в качестве менеджера ресурсов (resourse manager) в системе обработки распределенных транзакций (Distributed Transaction Processing - DTP).

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

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

Второе определяется поддержкой СУБД XA-интерфейса. Наконец, третье достигается за счет поддержки коммуникационными средствами стандарта Open DataBase Connectivity (ODBC), разработанного специалистами корпорации Microsoft.

CA-OpenIngres обеспечивает шлюзы как к реляционным СУБД (Rdb, DB2, ALLBASE/SQL), так и к системам, опирающимся на другие модели данных (RMS, IMS). Для доступа к этим СУБД используется обобщенный набор различных диалектов языка SQL - Ingres/OpenSQL, скрывающий от разработчика их различия. Если разрабатываемое приложение гарантированно будет обращаться к двум или более СУБД из приведенного выше списка (в который включена и собственно СУБД Ingres), то оно должно быть реализовано на Ingres/OpenSQL (но не на Ingres/SQL).

Ingres/OpenSQL включает основные операторы SELECT, UPDATE, INSERT, DELETE, CREATE TABLE, CREATE VIEW, DROP и стандартные SQL-функции (AVG, MAX, MIN, COUNT, SUM). Исключены операторы блокировок и индексирования, некоторые функции SQL, аргументами которых являются строки таблиц и расширения оператора CREATE TABLE, устанавливающие физические характеристики таблиц. Наличие шлюзов к другим СУБД - важное потребительское качество, позволяющее плавно перейти к новой системе, обеспечив доступ из вновь разработанных приложений к унаследованным из старой системы массивам данных в их прежнем формате.

Шлюзы поддерживает новый компонент системы - CA-OpenIngres/Enterprise Access. В новой версии системы - CA-OpenIngres Version 1.1 OpenSQL будет расширен в соответствии со стандартом SQL92. Планируется также разработать шлюзы в следующие системы: CA-IDMS, CA-Datacom, IBM DB2/6000, DB2/OS2, SQL/400, Oracle, Sybase, Microsoft SQLServer, Informix.

Поддержка XA-интерфейса важна в распределенной гетерогенной среде, когда роль координатора глобальных транзакций играет монитор транзакций, который полностью берет на себя поддержку двухфазовой фиксации транзакций. Это - так называемая трехзвенная (three-tiered) модель технологии "клиент-сервер" или модель сервера приложений [3]. В ней СУБД (одна или несколько) рассматриваются как частный случай менеджера ресурсов, а их роль сводится исключительно к обработке баз данных. Все прикладные функции реализуются в рамках приложения и оформляются как транзакции. Если в процессе выполнения транзакции затрагивается несколько узлов распределенной системы, причем на каждом из них доступ к базам данных обеспечивается некоторой СУБД, то транзакция считается глобальной. Такая транзакция может быть обработана лишь в том случае, когда каждая из СУБД, принимающая в этом участие, поддерживает XA-интерфейс.

Границы транзакции определяются в приложениях вызовами функций менеджера транзакций (tpbegin(), tpcommit(), tpabort()), которые, в свою очередь, содержат обращения к тем библиотечным функциям СУБД, которые обеспечивают обработку локальных транзакций средствами данной СУБД. Последние (функции) как раз и представляют собой XA-интерфейс. Существует стандарт этого интерфейса, разработанный X/Open. В настоящий момент XA-интерфейс поддерживают СУБД Oracle 7.x, Informix On-Line 5.x, Informix On-Line 6.x, CA-OpenIngres 1.1, Sybase 10. Средства поддержки XA-интерфейса обычно поставляются как расширение сервера БД. Не является исключением и CA-OpenIngres. Сервер БД может быть дополнен компонентом CA-OpenIngres DTP, который поставляется отдельно. Он позволяет обращаться к серверу Ingres следующим мониторам транзакций: CICS (IBM), Encina (Transarc), Tuxedo (Novell). Практическая ценность поддержки XA-интерфейса несомненна: он делает возможным переход от популярной ныне двухзвенной модели "клиент-сервер" к более гибкой, универсальной и перспективной трехзвенной модели, реализованной в мониторах транзакций - к технологии, которая завоевывает все большее число сторонников в среде профессиональных разработчиков, в том числе и в нашей стране.

Поддержка ODBC сегодня стала фактическим стандартом средств быстрой разработки приложений в операционной среде MS Windows для SQL-ориентированных реляционных СУБД. В CA-OpenIngres, как и в других СУБД, это качество обеспечивается драйвером ODBC, поставляемым вместе с компонентом CA-OpenIngres/Client Net. По сути, поддержка ODBC означает, помимо SQL и ESQL, еще один уровень доступа к базам данных, но существенно более стандартизированный и масштабный - в том смысле, что, во-первых, операционная среда ODBC - это MS Windows, который приобрел статус промышленного стандарта интерфейса пользователя, и, во-вторых, сегодня большинство систем быстрой разработки приложений поддерживают ODBC. Практическая ценность ODBC-интерфейса не требует комментариев - исключительно удобно иметь инструментарий для создания прикладных программ, гарантированно единым способом обращающихся к разнородным базам данных.

Говоря о межоперабельности, нельзя не упомянуть такое важное качество CA-OpenIngres, как возможность интеграции с большинством существующих CASE-систем, которая обеспечивается за счет поддержки открытого словаря данных и соответствия системы промышленным стандартам CASE (стандарты ANSI-RDS, CASE Data Interchange Format, ANSI SQL, PCTE, X/Open). В отличие от некоторых СУБД, опирающихся на собственные (proprietary), закрытые словари данных, CA-OpenIngres предоставляет общедоступный стандартизированный доступ к словарю данных (подход, которого сегодня придерживается большинство разработчиков СУБД). Он, в частности, позволяет, используя разнообразные информационные и функциональные модели, автоматически генерировать как схемы баз данных в формате Ingres, так и исходные коды приложений на одном из двух диалектов языка четвертого поколения: Ingres/4GL и Ingres/Windows4GL.

В качестве примера интеграции CASE-систем с CA-Ingres отметим две системы. Первая - ObjectTeam (один из продуктов фирмы CADRE Technologies) - рассматривается как высокотехнологичное средство объектно-ориентированного анализа и проектирования, опирающееся на модель Шлайер-Меллора (Shlayer-Mellor). Одним из этапов анализа является создание информационной модели предметной области, которая затем проецируется в информационную среду конкретной СУБД (Informix, Ingres, Oracle, Sybase). Конкретно, по подготовленным аналитиком ER-диаграммам генерируются SQL-процедуры создания объектов баз данных (в том числе и триггеров, хранимых процедур и событий), специфичные для данной СУБД. Вторая система - Westmount CASE - позволяет не только создать информационную модель, но и автоматически сгенерировать код прикладной программы либо на Ingres/4GL, либо на Ingres/Windows4GL. Вообще, CA-Ingres интегрирована с большинством известных автору CASE-систем. Поддержка открытого словаря данных, осуществляемая в рамках специальной программы Ingres/OpenCASE, может рассматриваться как один из серьезных аргументов, характеризующий Ingres как открытую систему.

Развитие современных СУБД происходит в направлении интеграции функций администрирования баз данных с функциями системного администрирования, опирающейся на планируемый промышленный стандарт Management Information Base (MIB). БД MIB, которая определяет характеристики нижнего уровня управления базами данных, общие для множества баз данных различных поставщиков, позволит управлять ими и осуществлять мониторинг на основе промышленного стандарта SNMP (Simple Network Management Protocol). В этом контексте заслуживают внимания новые возможности, предлагаемые Ingres в рамках CA-OpenIngres Management Architecture (IMA), обеспечивающей открытый интерфейс к MIB с целью мониторинга и управления системными характеристиками, такими так производительность, блокировки и журналирование.

Отметим также как важнейшую возможность интеграции CA-OpenIngres с системой CA-Unicenter [4]. Последняя специально спроектирована для управления распределенной неоднородной вычислительной средой и предлагает графический интерфейс, позволяющий администратору управлять несколькими неоднородными операционными системами способом, не зависящим от их технических и концептуальных различий. Пользователям могут быть интересны следующие направления интеграции: расширение с помощью CA-Unicenter возможностей архивирования и восстановления CA-OpenIngres, управление конфигурацией ресурсов, инсталляция приложений CA-OpenIngres, управление сигнализаторами событий, авторизация и администрирование доступа к БД.

CA-Unicenter обеспечивает безопасность общими методами, скрывающими детали администрирования доступа к БД, характерные для используемых систем. В CA-Unicenter безопасность обеспечивается подходом, опирающимся на систему правил (policy-based). Так, например, одно из правил может гласить, что "персоналу бухгалтерии разрешено работать с данными о платежах с 9.00 до 17.00 во все дни недели, исключая субботу, воскресенье и праздничные дни". CA-Unicenter гарантирует, что оно будет действовать по отношению ко всем ресурсам: базам данных, таблицам, процедурам, приложениям, файлам, компьютерам, даже к принтерам, используемым для распечатки платежных ведомостей,- независимо от типа операционных систем и расположения компьютеров в сети.

3. Расширяемость

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

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

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

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

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

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

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

В CA-OpenIngres концепция новых типов данных получила дальнейшее развитие. Спектр поддерживаемых типов данных был расширен за счет графических типов - точки, отрезка, прямоугольника, ломаной, окружности. Над данными этих типов допускаются операции определения пересечения (пересекаются ли объекты A и B ?) и включения (расположен ли объект A внутри объекта B ?), а также операции вычисления площади, периметра, расстояния между точками и длины отрезков и ломаных. Дополнительные типы данных и функции их обработки интегрированы в новый компонент системы - CA-OpenIngres/Spatial Object Library, который также поставляется как расширение сервера БД. Практическая ценность этого компонента очевидна прежде всего разработчикам графических информационных систем, которые получают в руки удобный инструмент, позволяющий оперировать с базовыми примитивами предметной области.

4. Масштабируемость

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

На практике масштабируемость обеспечивается такими характеристиками, как многопотоковая, мультисерверная архитектура, специальные возможности поддержки сверхбольших баз данных (такие как многотомные таблицы), оптимизатор запросов, опирающийся на статистические характеристики баз данных. Эти возможности существовали уже в предыдущей версии - Ingres 6.4 [5].

В системе CA-OpenIngres они получили дальнейшее развитие. В настоящий момент эта СУБД поддерживает некоторые кластерные системы и SMP-системы. Планируется расширить возможности системы до полной параллельной архитектуры, включая распараллеливание запросов и параллельное выполнение множества запросов на различных процессорах. Кроме того, Computer Associates планирует выпустить специальную версию сервера Ingres, "CA-OpenIngres/FastPath", которая обеспечит максимальную производительность в полностью статическом окружении за счет минимизации кода ядра СУБД и исключительной обработки предварительно откомпилированных и оптимизированных запросов. В рамках CA-OpenIngres планируется также продолжить сотрудничество с рядом производителей компьютеров в целях создания эффективных систем обработки данных. Примером может служить реализация совместных с фирмой ICL проектов - CA-OpenIngres SmartDisk (поддержка ICL Search Accelerator) и Gold Rush (высокопроизводительная система со 125 RISC-процессорами, 15 гигабайтами памяти и терабайтами дискового пространства). Отметим, что Computer Associates намерена опубликовать результаты тестов TPC-C (чего ASK Group ранее никогда не делала). Предполагается, что все эти действия направлены на развитие огромных потенциальных возможностей системы прежде всего в области поддержки сверхбольших баз данных (сфера, в которой Computer Associates традиционно имеет сильные позиции - не будем забывать о таких системах, как CA-IDMS, CA-Datacom), обслуживания тысяч пользователей, оперативной обработки интенсивных потоков запросов и т.д. - то есть на те области, которые и определяют реальную масштабируемость.

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

Один из подходов к повышению производительности системы предполагает переход от одного к двум компьютерам - серверам БД, первый из которых поддерживает исключительно OLTP-приложения, а второй специально выделен для поддержки систем принятия решений (Decision Support System - DSS). Разделение постоянно конфликтующих OLTP- и DSS-приложений позволяет существенно увеличить пропускную способность on-line-сервера, перенеся на него всю ответственность за оперативную обработку транзакций и изолировав на выделенном компьютере ресурсоемкие DSS-приложения. Взаимная согласованность данных обеспечивается специальным компонентом - репликатором (CA-OpenIngres/Replicator), который, будучи установлен на обоих компьютерах, тиражирует изменения в данных (с точностью до транзакции) на каждом из них на другой.

Таким образом, CA-OpenIngres/Replicator [6] может рассматриваться как эффективный инструмент горизонтального масштабирования. Этот компонент CA-Ingres представляет одну из сильнейших сторон системы, предоставляя практически полный арсенал для реализации с его помощью технологии тиражирования данных.

5. Интернационализация

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

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

Во-вторых, исключительно важно, чтобы все ресурсы системы, связанные с поддержкой национальных алфавитов (кодовые таблицы, системные сообщения и т.д.) были вынесены из ядра СУБД на уровень файловой системы, а выбор алфавитов и кодировок достигался установкой соответствующих значений переменных окружения или параметров конфигурационных файлов. В CA-OpenIngres поддерживается именно такой подход. Более того, в этой системе выделены соответствующие ресурсы как сервера БД, так и компьютера-клиента, что, в частности, позволяет иметь на клиенте и сервере различные кодировки - трансляция кодов символов осуществляется при передаче данных по сети, во взаимодействии компонентов CA-OpenIngres/Client Net и CA-OpenIngres/Server Net.

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

В настоящий момент CA-OpenIngres поддерживает символы русского алфавита в кодировке KOI-8 и ISO-5589/5 на сервере и на клиенте в операционной системе UNIX и VMS и в кодировке Cyrwin, "альтернативной" и KOI на персональных компьютерах под управлением MS Windows и DOS. Все компоненты CA-Ingres протестированы на соответствие этим кодировкам, локализованные версии сертифицированы и официально поддерживаются. CA-OpenIngres снабжена набором более чем 30 кодировок и поддерживает практически все европейские национальные алфавиты и большую часть алфавитов стран Юго-Восточной Азии.

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

Заключение

Эта статья - очень краткий обзор возможностей новой версии CA-OpenIngres в контексте открытых систем. Многие новые интересные особенности системы остались за рамками статьи. В качестве резюме сформулируем направления, где система является одним из технологических лидеров и которые заслуживают особого внимания отечественных пользователей СУБД:

• Технология тиражирования данных в распределенных системах (CA-OpenIngres/Replicator);
• Расширение сервера за счет интеграции новых типов данных (CA-OpenIngres/Object Management Extension, CA-OpenIngres/Spatial Object Library);
• Расширенная архитектура управления (CA-OpenIngres/Management Architecture).

Литература

1. International Data Corporation. "Unix and Advanced Operating Systems" February 1994, IDC #8595, Vol.2: Software, Database & OLTP Software.
2. Г.М.Ладыженский. "ASK OpenROAD - дороги, которые мы выбираем", "Сети", N 6, Москва, 1994.
3. Г.М.Ладыженский. "Технология "клиент-сервер" и мониторы транзакций", "Открытые Системы", Москва, Лето 1994.
4. Computer Associates. "The CA-OpenIngres Vision". Statement of Direction, 1994.
5. Г.М.Ладыженский, Г.Г.Барон. "Ingres - современные тенденции в архитектуре сервера базы данных", "Открытые Системы", Москва, Осень 1993.
6. Г.Г.Барон, Г.М.Ладыженский. "Технология тиражирования данных в распределенных системах", "Открытые Системы", Москва, Весна 1994.