Лекции по "Информатике"

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

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

• операторы определения данных;
• операторы манипуляции данными (Insert, Select, Update, Delete);
• операторы определения доступа к данным.

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

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

 
Рис. 2.3.  Основные компоненты СУБД

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 
Рис. 2.4.  Классификационная система координат

Идея хранилищ данных оказалось  востребованной, так как во многих видах государственной, деловой, научной, социальной деятельности необходимы тематически  объединенные и исторически очищенные  совокупности данных, при этом постоянно возрастала потребность:

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

К концу 1980-х годов, когда была в  полной мере осознана необходимость интеграции корпоративной информации и надлежащего управления этой информацией, появились технические возможности для создания соответствующих систем, которые первоначально были названы "хранилищами информации" (Information Warehouse - IW). И лишь в 1990-е годы, с выходом книги Уильяма (Билла) Инмона, хранилища получили свое нынешнее наименование "хранилища данных" (Data Warehouse - DW) [Inmon W.H. Building the Data Warehouse, QED/Wiley, 1991, 312 р.].

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

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

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

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

Таблица 2.3.
Предметная ориентированность	Все данные о некоторой сущности (бизнес-объекте, бизнес-процессе и  т. д.) из некоторой предметной области  собираются из множества различных источников, очищаются, согласовываются, дополняются, агрегируются и представляются в единой, удобной для их использования в бизнес-анализе форме
Интегрированность	Все данные о различных бизнес-объектах взаимно согласованы и хранятся в едином общекорпоративном хранилище
Поддержка хронологии	Данные хронологически структурированы  и отражают историю за период времени, достаточный для выполнения задач  бизнес-анализа, прогнозирования и  подготовки принятия решения
Неизменяемость	Исходные (исторические) данные, после того как они были согласованы, верифицированы и внесены в общекорпоративное хранилище, остаются неизменными и используются исключительно в режиме чтения

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

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

 
Рис. 2.5.  Схема организации данных в хранилище

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

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

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

К недостаткам можно отнести  большие затраты по реализации, высокую  ресурсоемкость в масштабе всего  предприятия, потребность в сложных  сервисных системах, рискованный  сценарий развития, когда все данные и метаданные находятся в одном репозитории и в неблагоприятном случае могут быть потеряны. Кроме того, при фильтрации, агрегировании и рафинировании "сырых" данных для такого хранилища обычно теряется очень много информации, которая может быть чрезвычайно полезной при бизнес-анализе. В связи с этим возникло понимание того, что хранилище, помимо механизмов размещения и извлечения данных (On Line Transactional Processing - OLTP), репозитория и витрин, должно иметь соответствующее пространство для организации "сырых" данных и их многомерного анализа в режиме реального времени (On Line Analytical Processing - OLAP).

Развитие инструментальных средств  обработки информации

Без преувеличения можно сказать, что период между последней третью XIX и концом ХХ веков был "колыбелью" многих больших и малых революций (рис. 2.6). Промышленная революция конца ХIХ - начала ХХ века и Первая мировая война породили волну социальных революций, которые если не перевернули, то основательно потрясли мировые устои.

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

 
Рис. 2.6.  Последовательность революций ХХ века

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

Предыстория ЭВМ

Древнейшим счетным инструментом, который сама природа предоставила в распоряжение человека, была его  собственная рука. Понятие числа и фигуры взято не откуда-то, а из действительного мира. "Десять пальцев, на которых люди учились считать (производить первую арифметическую операцию), представляют собой все что угодно, только не продукт свободного творческого разума" [http://www.junior.ru/wwwexam/history/frame.htm].

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

От пальцевого счета берет начало пятеричная система счисления (одна рука), десятеричная (две руки), двадцатеричная (пальцы рук и ног). У многих народов пальцы рук остаются инструментом счета и на более высоких ступенях развития.

Хорошо был известен пальцевый  счет в Риме. По свидетельству древнеримского историка Плиния-старшего, на главной римской площади Форуме была воздвигнута гигантская фигура двуликого бога Януса. Пальцами правой руки он изображал число 300, пальцами левой - 55. Вместе это составляло число дней в году в римском календаре.

 

В средневековой Европе полное описание пальцевого счета составил ирландец Беда Достопочтенный. Пальцевый счет сохранился кое-где и поныне. Историк и математик Л. Карпинский в книге "История арифметики" сообщает, что на крупнейшей мировой хлебной бирже в Чикаго предложения и запросы, как и цены, объявлялись маклерами на пальцах без единого слова.

Издревле употребляется еще  один вид инструментального  счета - с помощью деревянных палочек с зарубками (бирок). В средние века бирками пользовались для учета и сбора налогов. Бирка разрезалась на две продольные части, одна оставалась у крестьянина, другая - у сборщика налогов. По зарубкам на обеих частях и велся счет уплаты налога, который проверяли складыванием частей бирки. В Англии, например, этот способ записи налогов существовал до конца XVII столетия. Другие народы - китайцы, персы, индийцы, перуанцы - использовали для представления чисел и счета ремни или веревки с узелками.