Тема 13. Информационные хранилища данных
Технологии создания больших информационных массивов
Трудно представить сколько-нибудь значимую информационную систему, не имеющую в качестве основы, или важной составляющей БД. Концепции и технологии БД складывались в процессе развития систем автоматизированной обработки информации. После появления реляционного подхода создание БД превратилось из искусства в науку, но окончательно его не исключившая. Тем не менее, сложилась дисциплина (скорее инженерная, чем чисто научная), основанная на достаточно формализованных подходах, включающая широкий спектр приёмов и методов создания БД.
Базам свойственна «перманентность» данных. Соответственно назначение систем управления базами данных (СУБД) – обеспечение сохранности данных в течение длительного времени, а также возможностей их выборки и актуализации. Данные существуют всегда, пока есть потребность в их использовании[1], хотя характер использования, как и пути извлечения практической пользы, могут быть самыми разными: от оперативной актуализации значений до уничтожения данных, от их использования для совершенствования сложных систем управления до формирования «чемоданов компромата».
БД в развивающихся информационных технологиях – сравнительно консервативное направление, где СУБД и сами базы представляют «долговременные сооружения». Элементная база ЭВМ и парадигмы программирования меняются быстрее, чем хранимые данные теряют актуальность. В таких условиях, в отличие от прикладных программистов, создатели БД (от разработчиков СУБД до администраторов БД) должны постоянно помнить о проблеме «наследственности» – как интегрировать в создаваемую систему наследуемые данные, находящиеся под управлением устаревшей СУБД, и о том, как построить систему, чтобы вновь создаваемые данные могли быть, в свою очередь, наследованы следующим поколением систем и разработчиков.
Достаточно консервативны и концепции БД. Эта консервативность не только следствие свойства «долговечности», но и того факта, что базы вторичны по отношению к описываемым ими реальным процессам и объектам, достаточно стабильным и типичным. Кроме того, модели данных строились в значительной степени «по аналогии» с организационными и технологическими структурами – иерархическими, сетевыми, матричными.
Широкое использование БД различными категориями пользователей привело, с одной стороны, к созданию интерфейсов, требующих минимум времени на освоение средств управления системой, а с другой – к построению мощных, гибких СУБД имеющих, в том числе, развитые средства защиты данных от случайного или преднамеренного разрушения. Появились и средства автоматизации разработки, позволяющие создать БД любому пользователю, даже не владеющему основами теории БД.
БД – важная, но функционально не основная, а обеспечивающая (информационная) составляющая человеко-машинной системы. При этом развитие способностей взаимодействующих субъектов (человек-машина) имеет принципиальные отличия. Разделение информации на табличную (числовую), текстовую и графическую отражает последовательность, в которой эти виды информации «осваивались» компьютерами. Первые языки программирования были рассчитаны исключительно на обработку числовой информации (Fortran, Algol). Первыми появляются и табличные БД, также преимущественно рассчитанные на обработку числовых таблиц (файлов). Затем осваиваются текстовые файлы и текстовые БД (автоматизированные информационно-поисковые системы с библиографическими и полнотекстовыми базами). Наконец, с существенным повышением быстродействия и ёмкости памяти компьютеров, на сцену выходят графические и мультимедийные базы.
Эта последовательность прямо противоположна той, в которой данные виды информации осваивает человек. Действительно, сначала он знакомится с графическими образами (птицы, цветы и бабочки на шкафчиках для одежды в детском саду), затем – учится читать и писать, и только потом осваивает таблицу умножения.
Создание практически полезной «серьёзной» БД в равной степени зависит как от «фундаментальности» знаний разработчика в области концепций и технологий СУБД, так и от степени понимания им сегодняшних и будущих прикладных задач пользователя. Не только от адекватности применения тех или иных типовых или оригинальных решений, но и от качества представления (описания) этих решений, с той или иной степенью успешности позволяющих использовать, сопровождать и развивать систему после разработчика.
Кроме того, возможности накапливать и оперативно обрабатывать большие объемы информации, характеризующие деятельность предприятий за достаточно длительные периоды и в различных аспектах, дали новый импульс к развитию аналитических систем. Такого рода системы поддержки принятия решений обычно используются для оценки и выбора альтернативных решений, прогнозирования, идентификации объектов и состояний и т.д. Поскольку в этих случаях для получения необходимых данных нужно использовать сложные SQL-запросы или специализированные процедуры, и при этом обрабатывать большие объёмы записей, то уже это может приводить к сознательному отказу от классических нормализованных схем, т.к. чем выше степень нормализации, тем больше число операций соединения отношений и, соответственно, больше времени необходимо для получения конечного результата.
[1] Правильнее было бы говорить, что данные создаются, но создаются не ради их самих, а для того, чтобы в дальнейшем они использовались в каком-то процессе.