БД и СУБД

Основные понятия

В словаре школьной информатики А.П. Ершова дано следующее определение: “База данных — организованная совокупность данных, предназначенная для длительного хранения (обычно во внешней памяти ЭВМ) и постоянного применения”. Обратим внимание на то, что хранение данных — лишь одна из функций БД. На практике больше внимания приходится уделять “постоянному применению”, ради которого разрабатываются как различные модели представления данных, так и алгоритмы их обработки.

В этом же словаре уточняется понятие “данные”, которые определяются, как “факты или идеи, выраженные средствами формальной системы, обеспечивающей возможность их хранения, обработки или передачи”. Такую формальную систему называют языком представления данных.

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

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

Выше уже было отмечено, что основное назначение БД — “постоянное применение”. Говоря о применении БД, необходимо упомянуть о понятии информационная система (ИС), которая представляет собой комплекс программных, аппаратных, организационных и иных средств, обеспечивающих обработку (понимаемую в широком смысле) данных. Ядром, “сердцем” ИС как раз и является БД. Разумеется, ИС бывают достаточно сложными, в том числе и построенными на нескольких базах данных, но сути это не меняет — БД в принципе можно представить себе как нечто автономное, но невозможно представить ИС, не основанную на БД.

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

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

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

Классификации БД по моделям данных

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

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

Первые производственные СУБД использовали иерархическую модель данных, которая может быть представлена в виде дерева. Самой известной СУБД, использующей модель данных этого типа, является система IMS (Information Management System), разработанная фирмой IBM для поддержки лунного проекта “Аполлон”. Эта СУБД создавалась для управления огромным количеством деталей, иерархически связанных между собой, — из деталей собирались узлы, которые входили в еще более крупные модули, и т.д. Подобные конструкции легко и естественно описываются именно иерархической моделью — тут нет необходимости приводить в пример “Аполлон”, достаточно обычного велосипеда.

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

Одной из первых практических реализаций сетевых СУБД стала Integrated Data Store (IDS), созданная компанией General Electric. Архитектура этой СУБД легла в основу деятельности группы Database Task Group, которой конференция по языкам систем данных (Conference on Data Systems Languages — CODASYL) в конце 60-х годов поручила разработать стандарты систем управления базами данных. Этот документ и по сей день используется разработчиками сетевых СУБД, количество которых, по правде говоря… ничтожно. Сетевые СУБД весьма сложны в реализации, не слишком прозрачны не только для проектировщиков и программистов, но и для пользователей. Вследствие этого они оказались на периферии развития технологий после того, как в 1970 г. доктор Э.Ф. Кодд, математик и научный сотрудник фирмы IBM, предложил реляционную модель, основанную на представлении данных в виде таблиц. Одним из основных преимуществ реляционной модели является ее однородность. Все данные хранятся в плоских таблицах и только в них. В настоящее время практически все производственные СУБД различных масштабов используют реляционную модель. Поэтому ей не только посвящена отдельная статья “Реляционные БД 2, но и в статьях “Описание данных” 2, “Обработка данных”2 и “Проектирование БД” 2 речь идет именно о реляционных БД.

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

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

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

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

При разработке реляционной модели Кодд ввел два языка: описания данных и их обработки. В настоящее время для этой цели фактически используется один язык SQL (Structured Query Language). Использование общего языка стало одним из решающих конкурентных преимуществ реляционных СУБД. Фактически разработчики различных систем могут соревноваться в производительности, надежности, удобстве обслуживания и т.д., но пользователи чувствуют себя уверенно, зная, что грамотно организованные и описанные данные могут быть быстро экспортированы/импортированы из системы в систему.

Последней из рассматриваемых станет сравнительно новая технология объектно-ориентированных баз данных. Первый стандарт объектно-ориентированных баз данных ODMG-93 (Object Database Management Group) был принят в 1993 г. В нем, в частности, определены два языка — ODL (Object Data Language) для определения данных (объектов) и OQL (Object Query Language) для манипулирования данными. Язык OQL основан на языке SQL. Одним из принципиальных отличий объектных баз данных от реляционных является возможность создания и использования новых типов данных. При этом новые типы порождаются посредством наследования от базовых. В объектных базах данных также различаются операции над всеми данными типа или над конкретным экземпляром.

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

Вместе с тем отметим, что реляционная и объектно-ориентированная модели не являются взаимно-исключающими. Уже довольно давно разрабатываются объектно-реляционные СУБД. Самым известным примером в этой области, возможно, является система Postgres: именно на ее основе функционируют федеральные порталы Министерства образования. Эта же СУБД используется в системе сайтов Rambler.

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

Методические рекомендации

Введение в базы данных — не самая удобная тема базового курса информатики. У учителя всегда возникает естественное желание побыстрее закончить с “общими местами” и перейти к чему-нибудь конкретному. Тем не менее именно на этом этапе необходимо познакомить учащихся с понятиями “база данных” и “система управления базами данных”. Здесь важно обозначить как взаимосвязь, так и различие этих понятий.

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

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

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

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

Об объектно-ориентированных СУБД в базовом курсе можно лишь упомянуть.