Реферат: Московский физико-технический институт

МОСКОВСКИЙ ФИЗИКО-ТЕХНИЧЕСКИЙ ИНСТИТУТ

(ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ)


Кафедра/специализация

«Вычислительные модели технологических процессов»


АНОСОВ Андрей Александрович


ВЫБОР СУБД ДЛЯ ПОСТРОЕНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ


Дипломная работа/выпускная квалификационная работа

студента 4 курса


Направление: 511600 - «Прикладные математика и физика»


Специальность: 511656 - «Математические и информационные технологии»


Научный руководитель: к.ф.-м.н., с.н.с. Обухов И.А.


Москва - 2001

Аннотация.


Работа представляет собой обзор существующих подходов к вопросу выбора Системы Управления Базами Данных при построении информационных систем.

Вводится понятие Информационной Системы, рассматриваются вопросы специфики и организации таких систем, а также классификация архитектур информационных приложений. Дается обзор файл-серверных, клиент-серверных, Intranet-приложений и складов данных.

Вводится понятие СУБД, обсуждается необходимость ее использования в Информационных Системах. Освещаются вопросы типовой организации СУБД и основных подходов к построению моделей БД. Рассматриваются критерии, а также методология сравнения различных систем с целью выбора оптимального программного продукта в заданных условиях требований, к нему предъявляемых.


Ключевые слова: СУБД, ИС, SQL, OLAP, сервер, клиент, триггер, процедура, запрос, модель данных.


Оглавление:


1. Введение 4

2. Информационные системы 5

2.1. Общие сведения об информационных системах 5

2.1.1. Специфика информационных программных систем 5

2.1.2. Организация информационных систем 5

2.2. Общая классификация архитектур информационных приложений 6

2.2.1. Файл-серверные приложения 6

2.2.2. Клиент-серверные приложения 7

2.2.3. Intranet-приложения 9

2.2.4. Хранилища данных (Data Warehousing) и системы оперативной аналитической обработки данных 11

3. СУБД 13

3.1. Файловые системы 13

3.2. Потребности информационных систем 14

3.3. Функции СУБД. Типовая организация СУБД. 15

3.3.1. Основные функции СУБД 15

3.3.2. Типовая организация современной СУБД 17

3.4. Ранние подходы к организации БД. 18

3.4.1. Иерархические системы 19

3.4.2. Сетевые системы 20

3.4.3. Достоинства и недостатки ранних СУБД 21

3.5. Реляционный подход к СУБД. 22

3.5.1. Основные понятия 22

3.5.2. Фундаментальные свойства отношений 23

3.5.3. Реляционная модель данных 23

3.5.3.1. Общая характеристика 23

3.5.3.2. Целостность сущности и ссылок 24

3.5.3.3. Базисные средства манипулирования реляционными данными 24

3.5.3.4. Реляционная алгебра 25

3.5.3.5. Реляционное исчисление 26

3.6. Будущее развитие БД 27

3.7. Критерии сравнения СУБД. Методология выбора 28

4. Заключение 32

5. Словарь терминов 35

6. Список литературы и интернет-ресурсов 37



1. Введение

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

В большинстве случаев при создании собственной информационной системы невозможно обойтись без использования баз данных. Чем отличается "база данных" от какого бы то ни было склада данных, поддерживаемого в файлах операционной системы? Основное отличие состоит в том, что набором данных, входящих в состав базы данных управляет специальная системная программа, обычно называемая "системой управления базами данных (СУБД)", которая обладает знаниями по поводу связи между разнородными данными. Например, в случае складской системы, СУБД, управляющая соответствующей базой данных, должна знать, что для всех единиц любого товара, перечисленных в общей складской ведомости, должно быть проставлено правильное число в документе, регулирующем поступление товаров на склад. Такого типа свойства называются целостностью базы данных. При создании базы данных информационной системы разработчик сообщает СУБД, какого рода ограничения целостности система должна поддерживать в базе данных, а далее ответственность берет на себя СУБД, без требования вмешательства прикладной программы.

Второй важной особенностью СУБД является обеспечение выполнения так называемых "незапланированных" запросов к базе данных. Представим себе, что при проектировании информационной системы, предназначенной для автоматизации управления складом, было запланировано выполнение запросов о наличии на складе товаров, операций модификации данных при отпуске товаров со склада и их получении, а впоследствии понадобилась информация об общем объеме поставок от данного поставщика. При отсутствии СУБД понадобилась бы переделка информационной системы. Однако СУБД, обладая достаточными знаниями о предметной области (например, о структуре и смысле данных складской информационной системы), может обеспечить универсальный язык запросов (например, язык SQL), позволяющий сформулировать произвольный запрос на выборку информации из соответствующей базы данных. Такой запрос может быть в любой момент подан с терминала или встроен в одну из прикладных программ, входящих в информационную систему.

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

^ 2. Информационные системы 2.1. Общие сведения об информационных системах 2.1.1. Специфика информационных программных систем
В зависимости от конкретной области применения информационные системы могут очень сильно различаться по своим функциям, архитектуре, реализации. Однако можно выделить, по крайней мере, два свойства, которые являются общими для всех информационных систем. Во-первых, любая информационная система предназначена для сбора, хранения и обработки информации. Поэтому в основе любой информационной системы лежит среда хранения и доступа к данным. Среда должна обеспечивать уровень надежности хранения и эффективность доступа, которые соответствуют области применения информационной системы.

Во-вторых, информационные системы ориентируются на конечного пользователя, например, банковского клерка. Такие пользователи могут быть очень далеки от мира компьютеров. Для них терминал, персональный компьютер или рабочая станция представляют собой всего лишь орудие их собственной профессиональной деятельности. Поэтому информационная система обязана обладать простым, удобным, легко осваиваемым интерфейсом, который должен предоставить конечному пользователю все необходимые для его работы функции, но в то же время не дать ему возможность выполнять какие-либо лишние действия [5].
^ 2.1.2. Организация информационных систем
В корпоративных информационных системах часто возникает потребность в распределенном хранении общей базы данных. Например, разумно хранить некоторую часть информации как можно ближе к тем рабочим местам, в которых она чаще всего используется. При однородном построении распределенной базы данных (на основе однотипных серверов баз данных) эту задачу обычно удается решить на уровне СУБД (большинство производителей развитых СУБД поддерживает средства управления распределенными базами данных). Если же система разнородна (т.е. для управления отдельными частями распределенной базы данных используются разные серверы), то приходится прибегать к использованию вспомогательных инструментальных средств интеграции разнородных баз данных.

Традиционным методом организации информационных систем является двухзвенная архитектура "клиент-сервер" (рисунок 2.1 [5]).




Рис. 2.1. Традиционная двухзвенная архитектура "клиент-сервер"


В этом случае вся прикладная часть информационной системы выполняется на рабочих станциях системы, а на стороне сервера(ов) осуществляется только доступ к базе данных. Каждая рабочая станция должна обладать достаточным набором ресурсов, чтобы быть в состоянии произвести прикладную обработку данных, поступающих от пользователя и/или из базы данных. Для того, чтобы уменьшить требования к ресурсам клиента, а зачастую и для повышения общей эффективности системы, все чаще применяются трехзвенные архитектуры "клиент-сервер" (рисунок 2.2 [5]). В этой архитектуре, кроме клиентской части системы и сервера(ов) базы данных, вводится промежуточный сервер приложений. На стороне клиента выполняются только интерфейсные действия, а вся логика обработки информации поддерживается в сервере приложений.




Рис. 2.2. Трехзвенная архитектура "клиент-сервер" с выделенным сервером приложений


Как правило, в основу информационной системы закладывается реляционная база данных. Несмотря на очевидную привлекательность объектно-ориентированных (ObjectStore, Objectivity, O2, Jasmin и т.д.) и объектно-реляционных (Illustra, UniSQL) СУБД, в ближайшие годы придется работать с хорошо отлаженными, развитыми, сопровождаемыми системами, поддерживающими стандарт SQL-92 (например, Oracle, Informix, CA-OpenIngres, Sybase, DB2). Просто потому, что должно пройти время, чтобы эти системы устоялись, обрели необходимую надежность, начали опираться на какие-либо стандарты и т.д. [5].

^ 2.2. Общая классификация архитектур информационных приложений

Все подходы к организации информационных систем базируются на общей архитектуре "клиент-сервер". Различие состоит только в том, что делают клиенты и серверы. Тем не менее, широко применяется более узкое разделение на “файл-сервер”, непосредственно “клиент-сервер”, “Intranet”.

Следует заметить, что, как и любая классификация, рассматриваемая ниже классификация архитектур информационных систем, не является абсолютно жесткой. В архитектуре любой конкретной информационной системы часто можно найти влияния нескольких общих архитектурных решений.
^ 2.2.1. Файл-серверные приложения
Организация информационных систем на основе использования выделенных файл-серверов все еще является наиболее распространенной в связи с наличием большого количества персональных компьютеров разного уровня развитости и сравнительной дешевизны связывания PC в локальные сети. Такая организация привлекательна тем, что при опоре на файл-серверные архитектуры сохраняется автономность прикладного (и большей части системного) программного обеспечения, работающего на каждом компьютере сети. Фактически, компоненты информационной системы, выполняемые на разных компьютерах, взаимодействуют только за счет наличия общего хранилища файлов, которое располагается на файл-сервере. В классическом случае в каждом компьютере дублируются не только прикладные программы, но и средства управления базами данных. Файл-сервер представляет собой разделяемое всеми компьютерами комплекса расширение дисковой памяти (рисунок 2.3 [5]).




Рис. 2.3. Классическое представление информационной системы в архитектуре "файл-сервер"


Основным достоинством файл-серверной архитектуры является простота организации, к тому же имеются удобные и развитые средства разработки графического пользовательского интерфейса, простые в использовании средства разработки систем баз данных и/или СУБД. В качестве примера системы, соблюдающей выполнение этих условий, но основанной на файл-серверной архитектуре, можно привести популярный в прошлом "сервер баз данных" Informix SE.

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

В целом, в файл-серверной архитектуре мы имеем "толстого" клиента и очень "тонкий" сервер в том смысле, что почти вся работа выполняется на стороне клиента, а от сервера требуется только достаточная емкость дисковой памяти (рисунок 2.4 [5]).




Рис. 2.4. "Толстый" клиент и "тонкий" сервер в файл-серверной архитектуре


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

^ 2.2.2. Клиент-серверные приложения
Под клиент-серверным приложением мы будем понимать информационную систему, работающую по следующей схеме (Рис. 2.5) [5]:

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

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




Рис. 2.5. Общее представление информационной системы в архитектуре "клиент-сервер"


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

Поскольку вся работа с БД (выборка, добавление, выполнение триггеров и процедур) происходит на стороне сервера, то в клиент-серверной организации клиенты могут являться достаточно "тонкими", а сервер должен быть "толстым" настолько, чтобы быть в состоянии удовлетворить потребности всех клиентов (рисунок 2.6 [5]).




Рис. 2.6. "Тонкий" клиент и "толстый" сервер в клиент-серверной архитектуре


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

Фактически, концепция локального кэширования базы данных является частным случаем концепции реплицированных (или, как иногда их называют, тиражированных) баз данных. Как и в общем случае, для поддержки локального кэша базы данных программное обеспечение рабочих станций должно содержать компонент управления базами данных - упрощенный вариант сервера баз данных, который, например, может не обеспечивать многопользовательский режим доступа. Отдельной проблемой является обеспечение согласованности кэшей и общей базы данных. Здесь возможны различные решения - от автоматической поддержки согласованности за счет средств базового программного обеспечения управления базами данных до полного перекладывания этой задачи на прикладной уровень. В любом случае, клиенты становятся более толстыми притом, что сервер тоньше не делается (рисунок 2.7 [5]).




Рис. 2.7. "Потолстевший" клиент и "толстый" сервер в клиент-серверной архитектуре с поддержкой локального кэша на стороне клиентов


Архитектура "клиент-сервер" на первый взгляд кажется гораздо более дорогой, чем архитектура "файл-сервер". Требуется более мощная аппаратура (по крайней мере, для сервера) и существенно более развитые средства управления базами данных. Однако, это верно лишь частично. Громадным преимуществом клиент-серверной архитектуры является ее масштабируемость и вообще способность к развитию, поскольку увеличение масштабов информационной системы не порождает принципиальных проблем. Даже при замене аппаратуры сервера практически не затрагивается прикладная часть информационной системы [5].
2.2.3. Intranet-приложения
Возникновение и внедрение в широкую практику высокоуровневых служб Всемирной Сети Internet (e-mail, http, ftp, telnet, WWW и т.д.) естественным образом повлияли на технологию создания корпоративных информационных систем, породив направление, известное теперь под названием Intranet. По сути дела, информационная Intranet-система - это корпоративная система, в которой используются методы и средства Internet.

Хотя в общем случае в Intranet-системе могут использоваться все возможные службы Internet, наибольшее внимание привлекает гипертекстовая служба WWW (World Wide Web - Всемирная Паутина). Видимо, для этого имеются две основные причины. Во-первых, с использованием языка гипертекстовой разметки документов HTML можно сравнительно просто разработать удобную для использования информационную структуру, которая в дальнейшем будет обслуживаться одним из готовых Web-серверов. Во-вторых, наличие нескольких готовых к использованию клиентских частей - браузеров избавляет от необходимости создавать собственные интерфейсы с пользователями, предоставляя им удобные и развитые механизмы доступа к информации. В ряде случаев такая организация корпоративной информационной системы (рисунок 2.8 [5]) оказывается достаточной для удовлетворения потребностей компании.

Однако, при всех своих преимуществах (простота организации, удобство использования, стандартность интерфейсов и т.д.) эта схема обладает сильными ограничениями. Прежде всего, как видно из рисунка 2.8, в информационной системе отсутствует прикладная обработка данных. Все, что может пользователь, это только просмотреть информацию, поддерживаемую Web-сервером. Далее, гипертекстовые структуры трудно модифицируются. Для того, чтобы изменить наполнение Web-сервера, необходимо приостановить работу системы, внести изменения в HTML-код и только затем продолжить нормальное функционирование. Наконец, далеко не всегда достаточен поиск информации в стиле просмотра гипертекста. Базы данных и соответствующие средства выборки данных по-прежнему часто необходимы.




Рис. 2.8. Простая организация Intranet-системы с использованием средств WWW


Аналогичная техника широко используется для обеспечения унифицированного доступа к базам данных в Intranet-системах. Язык HTML позволяет вставлять в гипертекстовые документы формы. Когда браузер натыкается на форму, он предлагает пользователю заполнить ее, а затем посылает серверу сообщение, содержащее введенные параметры. Как правило, к форме приписывается некоторая внешняя процедура сервера. При получении сообщения от клиента сервер вызывает эту внешнюю процедуру с передачей параметров пользователя. Понятно, что такая внешняя процедура может, в частности, играть роль шлюза между Web-сервером и сервером баз данных. В этом случае параметры должны специфицировать запрос пользователя к базе данных. В результате получается конфигурация информационной системы, схематически изображенная на рисунке 2.9 [5].




Рис. 2.9. Доступ к базе данных в Intranet-системе


На принципах использования внешних процедур основывается также возможность модификации документов, поддерживаемых Web-сервером, и создание временных "виртуальных" HTML-страниц.

Даже начальное введение в Intranet было бы неполным, если не упомянуть про возможности языка Java. Java - это интерпретируемый объектно-ориентированный язык программирования, созданный на основе языка Си++. Мобильные коды (апплеты), полученные в результате компиляции Java-программы, могут быть привязаны в HTML-документу. В этом случае они поступают на сторону клиента вместе с документом и выполняются либо автоматически, либо по явному указанию. Апплет может быть, в частности, специализирован как шлюз к серверу баз данных (или к какому-либо другому серверу). При применении подобной техники доступа к базам данных схема организации Intranet-системы становится такой как на рисунке 2.10 [5].




Рис. 2.10. Доступ к базе данных на стороне клиента Intranet-системы


Краткие выводы: Intranet является удобным и мощным средством разработки и использования информационных систем. Как было отмечено выше, единственным относительным недостатком подхода можно считать постоянное изменение механизмов и естественное отсутствие стандартов. С другой стороны, если информационная система будет создана с использованием текущего уровня технологии и окажется удовлетворяющей потребностям корпорации, то никто не будет обязан что-либо менять в системе по причине появления более совершенных механизмов.
^ 2.2.4. Хранилища данных (Data Warehousing) и системы оперативной аналитической обработки данных
До сих пор мы рассматривали способы и возможные архитектуры информационных систем, предназначенных для оперативной обработки данных, т.е. для получения текущей информации, позволяющей решать повседневные проблемы корпорации. Однако у аналитических отделов корпорации и у высшего звена управляющего состава имеются и другие задачи: проанализировав поведение корпорации на рынке с учетом сопутствующих внешних факторов и спрогнозировав хотя бы ближайшее будущее, выработать тактику, а возможно, и стратегию корпорации. Понятно, что для решения таких задач требуются данные и прикладные программы, отличные от тех, которые используются в оперативных информационных системах. В последние несколько лет все более популярным становится подход, основанный на концепциях хранилища данных и системы оперативной аналитической обработки данных.

Рассмотрим основные черты и отличия оперативных и аналитических информационных приложений с точки зрения обеспечения требуемых данных. Речь идет о так называемых OLAP-системах (от On-Line Analitical Processing), т.е. аналитических системах, помогающих принимать бизнес-решения за счет производимых анализа, моделирования и/или прогнозирования данных [5].

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

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

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

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




Рис. 2.11. Схематическое представление архитектуры аналитической информационной системы


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

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

С учетом приведенных замечаний общая архитектура хранилища данных и системы аналитической обработки данных может выглядеть так, как показано на рисунке 2.11 [5].

Вообще говоря, подход хранилищ данных еще слишком молод, чтобы вокруг него сложился круг общепринятых понятий, терминов, технологических приемов. Тем не менее, он кажется настолько важным и перспективным, что многие компании (в том числе и ведущие производители СУБД) ведут активную работу, чтобы быть в авангарде этого направления [5].

3. СУБД
C самого начала развития вычислительной техники образовались два основных направления ее использования. Первое направление - применение вычислительной техники для выполнения численных расчетов, которые слишком долго или вообще невозможно производить вручную. Становление этого направления способствовало интенсификации методов численного решения сложных математических задач, развитию класса языков программирования, ориентированных на удобную запись численных алгоритмов, становлению обратной связи с разработчиками новых архитектур ЭВМ.

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

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

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

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

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

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

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

Но это еще не все, что обычно требуют от СУБД. Как уже указывалось выше, файловые системы имеют жесткий и весьма ограниченный набор запросов, “зашитый” в управляющую программу. Современные СУБД способны реализовывать произвольно сформулированные запросы на близком пользователю языке. Такие языки называются языками запросов к базам данных. На данный момент самым распространенным языком запросов является SQL.

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

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