Какая информация может содержаться в базе данных

3.3. Хранение информации. Базы и хранилища данных

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

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

База данных, БД (Data Base) — структурированный организованный набор данных, объединенных в соответствии с некоторой выбранной моделью и описывающих характеристики какой-либо физической или виртуальной системы (
рис.
3.2).

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

Система управления базами данных, СУБД (Data Base Management System) — специализированная программа или комплекс программ, предназначенные для манипулирования базой данных. Для создания информационной системы и управления ею СУБД необходима в той же степени, как для разработки программы на алгоритмическом языке необходим транслятор.

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

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

Организация структуры БД формируется, исходя из следующих соображений:

• адекватность описываемому объекту/системе — на уровне концептуальной и логической модели;
• удобство использования для ведения учёта и анализа данных — на уровне так называемой физической модели.

Виды концептуальных и логических моделей БД:

• картотеки;
• сетевые;
• иерархические;
• реляционные;
• дедуктивные;
• объектно-ориентированные;
• многомерные.

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

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

Реляционная база данных — база данных, основанная на реляционной модели. Слово «реляционный» происходит от английского «relation» (отношение).

Теория реляционных баз данных была разработана доктором Коддом из компании IBM в 1970 году. В реляционных базах данных все данные представлены в виде простых таблиц, разбитых на строки и столбцы, на пересечении которых расположены данные. Запросы к таким таблицам возвращают как отдельные данные, так и таблицы, которые сами могут становиться предметом дальнейших запросов. Каждая база данных может включать несколько таблиц.

Кратко особенности реляционной базы данных можно сформулировать следующим образом:

• данные хранятся в таблицах, состоящих из столбцов («атрибутов») и строк («записей»);
• на пересечении каждого столбца и строчки стоит в точности одно значение;
• у каждого столбца есть своё имя, которое служит его названием, и все значения в одном столбце имеют один тип;
• запросы к базе данных возвращают результат в виде таблиц, которые тоже могут выступать как объект запросов;
• строки в реляционной базе данных неупорядочены, упорядочивание производится в момент формирования ответа на запрос.

Общепринятым стандартом языка работы с реляционными базами данных в настоящее время является язык структурированных запросов (Structured Query Language — SQL). Это универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных базах данных. Вопреки существующим заблуждениям, SQL является информационно-логическим языком, а не языком программирования.

SQL основывается на реляционной алгебре. Язык SQL делится на три части:

• операторы определения данных;
• операторы манипуляции данными (insert, select, update, delete);
• операторы определения доступа к данным.

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

• управление данными во внешней памяти (на различных носителях);
• управление данными в оперативной памяти;
• журналирование изменений и восстановление базы данных после сбоев;
• поддержка языков БД (язык определения данных, язык манипулирования данными, язык определения доступа к данным).

Обычно современная СУБД содержит следующие компоненты (
рис.
3.3):

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

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

По архитектуре организации хранения данных:

• локальные СУБД (все части локальной СУБД размещаются на одном компьютере);
• распределенные СУБД (части СУБД могут размещаться на двух и более компьютерах).

Классификация СУБД по способу доступа к БД:

• файл-серверные;
• клиент-серверные;
• трехзвенные;
• встраиваемые.

Файл-серверные СУБД. Архитектура «файл-сервер» не имеет сетевого разделения компонентов диалога и использует компьютер для функции отображения, что облегчает построение графического интерфейса. «Файл-сервер» только извлекает данные из файлов, так что дополнительные пользователи добавляют лишь незначительную нагрузку на центральный процессор, и каждый новый клиент добавляет вычислительную мощность сети. Минус — высокая загрузка сети. На данный момент файл-серверные СУБД считаются устаревшими. Примеры: Microsoft Access, MySQL (до версии 5.0).

Клиент-серверные СУБД. Такие СУБД состоят из клиентской части (которая входит в состав прикладной программы) и сервера. Клиент-серверные СУБД, в отличие от файл-серверных, обеспечивают разграничение доступа между пользователями и меньше загружают сеть и клиентские машины. Сервер является внешней по отношению к клиенту программой, и по надобности его можно заменить другим. Недостаток клиент-серверных СУБД в самом факте существования сервера (что плохо для локальных программ — в них удобнее встраиваемые СУБД) и больших вычислительных ресурсах, потребляемых сервером. Примеры: Firebird, In-terbase, MS SQL Server, Oracle, DB2, PostgreSQL, MySQL (старше версии 5.0).

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

Встраиваемая СУБД — это, как правило, «библиотека», которая позволяет унифицированным образом хранить большие объёмы данных на локальной машине. Доступ к данным может происходить через SQL либо через особые функции СУБД. Встраиваемые СУБД быстрее обычных клиент-серверных и не требуют установки сервера, поэтому востребованы в локальном ПО, которое имеет дело с большими объёмами данных — например, геоинформационные системы (Geographic Informational System — GIS). Примеры: SQLite, BerkeleyDB, один из вариантов Firebird, один из вариантов MySQL.

В общем случае СУБД могут быть классифицированы в системе координат {Неоднородность — Автономность — Распределенность} (
рис.
3.4).

Таким образом, распределенная обработка данных в обязательном порядке предполагает наличие банков и баз данных. Но база данных — это не просто место, куда складывают данные, ими нужно пользоваться, актуализировать, изменять форматы и связи, совершать множество других действий. Если бессистемно наполнять базу данных информацией, то через некоторое время ее невозможно будет использовать — времени на поиск нужных данных будет уходить всё больше и больше, физическое пространство базы переполнится. Чтобы этого избежать, данные необходимо «очищать» и структурировать, а для эффективной работы с ними необходимы системы управления работой баз данных.

Индустрия создания баз данных и СУБД берет свое начало в 60-х годах прошлого века и к настоящему времени достаточно развита, однако понятие «хранилище данных» в современном понимании его появилось относительно недавно. Идея хранилищ данных оказалось востребованной, так как во многих видах государственной, деловой, научной, социальной деятельности необходимы тематически объединенные и исторически очищенные совокупности данных, при этом постоянно возрастала потребность:

• в более дешевых данных;
• в точных и структурированных данных;
• в большей оперативности получения и обработки данных;
• в интегрированных данных.

К концу 80-х годов, когда была в полной мере осознана необходимость интеграции корпоративной информации и надлежащего управления этой информацией, появились технические возможности для создания соответствующих систем, которые первоначально были названы «хранилищами информации» (Information Warehouse — IW). И лишь в 90-е годы, с выходом книги Билла Инмона, хранилища получили свое нынешнее наименование «хранилища данных» (Data Warehouse — DW) [25].

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

В основе концепции хранилищ данных лежат следующие основополагающие идеи:

• интеграция ранее разъединенных детализированных данных (исторические архивы, данные из традиционных систем обработки документов, разрозненных баз данных, данные из внешних источников) в едином хранилище данных;
• тематическое и временнОе структурирование, согласование и агрегирование;
• разделение наборов данных, используемых для операционной (производственной) обработки, и наборов данных, используемых для решения задач анализа.

Данные, помещаемые в хранилище, должны отвечать определенным требованиям — предметной ориентированности, интегрированности, поддержки хронологии и неизменяемости (табл. 3.3 (3.3.1)).

Хранилище данных выполняет множество функций, но его основное предназначение — предоставление точных данных и информации в кратчайшие сроки и с минимумом затрат.

Понятие хранилище данных в первоначальном понимании было основано на понятии распределенной витрины данных (Distributed Data Mart — DDM). Поэтому в классическом исполнении хранилище данных было, прежде всего, репозиторием (сквозной базой данных) данных и информации предприятия.

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

С точки зрения архитектурного решения такое хранилище данных реализует свои функции через подмножество зависимых витрин данных (
рис.
3.5).

Достоинствами архитектуры классического хранилища данных являются:

• общая семантика;
• централизованная, управляемая среда;
• согласованный набор процессов извлечения и бизнес-логики использования;
• непротиворечивость содержащейся информации;
• легко создаваемые по шаблонам и наполняемые витрины данных;
• единый репозиторий метаданных;
• многообразие механизмов обработки и представления данных.

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

В связи с этим возникло понимание того, что хранилище, помимо механизмов размещения и извлечения данных (On Line Trans-actional Processing — OLTP), репозитория и витрин, должно иметь соответствующее пространство для организации «сырых» данных и их многомерного анализа в режиме реального времени (On Line Analytical Processing — OLAP).