явление сделало ненужным дорогостоящее программирование на таких языках, как COBOL и FORTRAN, популярных в то время.

В СУБД IMS, применяемой до сих пор, реализована иерархическаяель данных, в которой существуем ственный путь от корня иерархии к каждой записи. Такая модель стала основой для систем управления данными, она же дала толчок к последующим изобретениям из-за своей ограниченности. Полная история IMS была опубликована в 1998 г. {ijw.research.ibm.c(m/jmmal/sj/374/black7nan.htrnl).

В 1971 г. состоялась конференция по языкам обработки данных (Conference on Data Systems Languages ASYL), в задачу которой входила разработка стандартов баз данных. Ранее эта конференция уже стандартизировала язык COBOL. Новый стандарт был расширен на иерархическую модель данных, применяемую в IMS. Результатом стало появление сетевой моделиданных.

В сетевой модели любая запись может участвовать в нескольких отношениях предок/потомок. Это позволяло обходить целый ряд ограничений иерархической модели. Разработкой сетевой модели занимался Чарльз чман (Charles man), в то время руководитель проекта IDS (Integrated Data System - интегрированная система обработки данных) в компании General Electric. Он же изобрел диаграммы Бейчма-на , описывающие сетевые базы данных. За свой труд в 1973 г. Бейчман получил награду Тьюринга.

Тем временем научный сотрудник компании IBM доктор Эдгар Кодд (Edgar Codd) работал над эпохальным документом для Ассоциации производителей вычислительной техники (Association for Computing Machinery, ACM). В июне 1970 г. этот документ был опубликован в названием Реляционная модель для больших банков совместно используемых данных ( A Relational Model of Data for Large Shared Data Banks ). Этот документ в корне изменил теорию баз данных и принес доктору награду Тьюринга в 1981 году.

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

В результате появились две СУБД: System R компании IBM и Ingres Калифорнийского университета в Беркли. В обеих был реализован реляционный модуль и язык запросов. Последний в СУБД System R первоначально назывался SEQUEL (Structured English Query Language - структурированный английский язык запросов). Позднее появилось название SQL (Structured Query Language). г. организация ANSI опубликовала официальный стандарт языка SQL.

Терминология

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

Такова логическая модель данных. На жестком диске вся база данныхможет находиться в одном файле. В MySQL для каждой базы данных создается отдельный ката-

СУБД 51

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

Строки таблиц могут быть связаны друг с другом одним из трех способов. Простейшее отношение - один к одному . В этом случае строка первой таблицы соответствует одной-единственной строке второй таблицы. На диаграммах такое отношение выражается записью 1:1.

Отношение один ко многим означает ситуацию, когда строка одной таблицы соответствует нескольким строкам другой таблицы. Это наиболее распространенный тип отношений. На диаграммах он выражается записью 1:N.

Наконец, при отношении многие ко многим строки первой таблицы могут быть связаны с произвольным числом строк во второй таблице. Такое отношение записывается как N:M.

СУБД

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

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

Язык четвертого поколения позволяет создавать схемы- точные определения данных и отношений между ними. Схема хранится как часть базы Данных и может быть изменена без ущерба для данных.

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

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

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

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

Системы управления файлами

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

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

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

По мере увеличения числа приложений растет сложность управления базой данных. Изменения схемы данных приводят к необходимости изменения каждого программного компонента, для которого это актуально. Формирование новых запросов занимает столько времени, что зачастую теряет всякий смысл.

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

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

Иерархические базы данных

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