Хранилища данных и корпоративная память

 

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

Условно разделяют рабочую базу данных, отвечающую за текущее функционирование предприятия, и хранилище данных (data warehouse), назначение которого – накопление всего массива данных с целью даль­нейшего анализа. Как правило, от ра­бочей базы данных требуется высо­кая производительность с поддерж­кой транзакций. Хранилище данных, в свою очередь, может иметь несколь­ко другую структуру и быть доступ­ным только на чтение для аналитиков. Данные из рабочей базы данных пе­риодически заносятся в хранилище. При этом может происходить провер­ка данных на непротиворечивость, преобразование структуры данных в вид, удобный для анализа и т.д. Архи­тектура хранилища данных показана на рис. 5. Использовать хранилища данных имеет смысл даже тогда, когда планируется применять простейшие методы анализа данных типа OLAP.

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

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

Машинное обучение – ключ к кибернетическому бессмертию

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

ИСТОРИЯ РАЗВИТИЯ ИНТЕРФЕЙСОВ ДОСТУПА К БАЗАМ ДАННЫХ

 

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

АВТОМАТИЗАЦИЯ ПРОИЗВОДСТВА. ODBC

Сорок лет назад нормальное ис­пользование базы данных в подавля­ющем большинстве случаев можно было представить примерно так: опе­ратор сидит за терминалом СУБД и вручную делает выборки. В скором времени автоматизация производства проникла и сюда: с началом внедре­ния автономных программных комп­лексов базы данных услуги человека-работника стали ненужными. На тот момент стандарты описывали лишь логику построения РБД и язык SQL, призванный стать унифицированным интерфейсом между человеком и СУРБД, но не между программой и СУРБД. Как и всегда в подобных ситу­ациях, в мире воцарился хаос: каж­дый производитель пытался протолк­нуть свой программный интерфейс доступа и навязать его потребителю. Устав от этого бардака, наиболее со­знательные производители объеди­нились в группу SAG (SQL Access Group), которая занялась разработкой унифицированного CLI (Call Level Interface, а проще - "библиотека функций"), позволяющего приложе­ниям работать с базами данных. Раз­работка оказалась удачной и была стандартизирована ISO и EIC. Стан­дарт ISO/EIC DBC CLI не слишком удо­бен и гибок по современным нормам, перегружен низкоуровневыми рутин­ными операциями, но он впервые поз­волил программистам писать системы, взаимодействующие с РБД, и малой кровью переносить их между базами различных производителей.

В 1992 году небезызвестная компа­ния Microsoft с небольшим опоздани­ем обратила внимание на популяр­ность и востребованность технологий, связанных с реляционными базами данных. Завоевать этот сегмент рынка засильем своих технологий к тому времени уже не представлялось воз­можным, поэтому новый продукт ком­пании основывался на ISO/EIC CLI и получил название ODBC - Open Database Connectivity. Проект ODBC отличался от своего предка расши­ренным набором функций и разделе­нием на два компонента: ODBC-драй-веры, предоставляющие непосред­ственный доступ к БД, и ODBC-диспет-чер (менеджер) который с одной сто­роны управляет драйверами, а с дру­гой взаимодействует с прикладным ПО. Такой подход позволяет ODBC-приложениям полностью абстрагиро­ваться от специфики конкретной РДБ, легко переключаясь между ними даже в процессе работы.