4. Основные требования к базам данных в рамках корпоративных информационных систем.

В первую очередь, при выборе СУБД от ведущих производителей, следует оценить реальные затраты на приобретение, программирование, запуск и сопровождение системы. В этом помогут материалы конкурентов: прочитав, почему Oracle Database, IBM DB2 UDB и Microsoft SQL Server одновременно дешевле и производительней друг друга и насколько снизятся расходы после перехода на Oracle Database, IBM DB2 UDB или Microsoft SQL Server, вы получите необходимые данные для того, чтобы сделать адекватные расчеты «под себя».

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

Если требуется интегрированная платформа с высокой надёжностью, производительностью, уровнем безопасности и степенью готовности в условиях разнородного парка ЭВМ разных архитектур, то это Oracle или IBM. Выбор здесь будет зависеть от конкретных условий, которые вам предложат поставщики. Если нет особой необходимости искать интегрированную платформу (или планируется её разработка своими силами), но остальные требования те же, в игру включаются Software AG и Progress Software. Выбор здесь будет определяться совокупной стоимостью владения, наличием у поставщиков готовых решений и опыта в вашей области. На однородных Wintel-платформах выбор чаще будет в пользу продукции Microsoft, особенно при разработке Web-порталов. Однако и другие игроки могут тут себя показать, например, при необходимости автоматизировать сложный производственный процесс или обеспечить возможность высокопроизводительной работы со сверхбольшими объёмами данных.

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

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

Хранилища данных.

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

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

Можно сказать, что современное Хранилище существенно расширяет традиционные функции, включая в себя такие компоненты и процессы как:

- расширенный уровень подготовки данных;

- сервис-ориентированное взаимодействие между инструментами и процессами;

- событийно управляемое (event-driven) взаимодействие между компонентами;

-новые системы администрирования и управления метаданными (общие – разделяемые метаданные, бинаправленные метаданные (bidirectional metadata), хранение версий, сложная модель управления);

-специально оптимизированный уровень хранения данных.

Рассмотрим их более подробно.

Расширенный уровень подготовки данных

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

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

Одним из самых неожиданных факторов при разработке ХД оказываются расходы на поддержку после внедрения.

Сервисно-ориентированное взаимодействие между инструментами и процессами

Все компоненты представлены в виде сервисов. Сервис – это системный компонент, в котором функции декларируются с помощью языка общих определений (common definition language). Такой компонент размещается и запускается с помощью общего механизма обнаружения и запуска. Эта концепция заимствуется из общей парадигмы сервис-ориентированной архитектуры (SOA). Разница лишь в том факте, что в предлагаемом решении выделяются компоненты взаимодействия, которые представлены в виде сервисов (они, в свою очередь, могут быть веб-сервисами на основе UDDI).

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

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

Управление метаданными

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

Интегрированные метаданные

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

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

хранение версий — чтобы расширять Хранилище дополнительными источниками с минимальными конфликтами данных, необходимо хранить версии метаданных;

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

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

Надежная модель администрирования