Архитектура банка данных

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

• инфологический уровень;
• концептуальный уровень;
• внешний уровень;
• внутренний уровень.

На каждом уровне присутствует модель данных информации, которая специфицируется с помощью языка описания данного уровня. Модель каждого уровня, представленную на языке описания, принято называть СХЕМОЙ. Перевод моделей (описаний моделей) из одного уровня в другой осуществляется с помощью трансляции или интерпретации.

B зависимости от вида представления информации различают следующие типы схем:

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

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

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

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

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

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

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

Стандарт ANSI/SPARC

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

Рис. 1. Архитектура банка данных

Описание архитектуры

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

Архитектура представлена тремя уровнями: внутренним, концептуальным и внешним.

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

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

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

Банк данных создается для удовлетворения информационных потребностей пользователя.

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

Для прикладного программиста это обычный язык программирования, например: Паскаль, Си, PL/1. Для пользователя-непрофессионала – это специальный язык, разработанный с учетом его потребностей, т.е. это может быть специальное меню, реализованное с помощью языка типа SQL (Structured Query Language – структурированный язык запросов) или QBE (Query-By-Exemple – запросы на основе примеров) и т.п.

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

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

Внешняя модель состоит из различных экземпляров различных типов внешних записей (логических), причем такие записи могут не совпадать с хранимыми записями. Пользователь через рабочую область оперирует с базой данных на уровне внешних записей, например, по оператору SELECT [30] языка манипулирования данными будет происходить выборка внешней записи, а не экземпляра хранимой записи. Каждая внешняя модель задается (описывается) посредством внешней схемы, которая в основном состоит из описаний всех типов внешних записей этой внешней модели, например: запись о студенте. Помимо этого описания, должно быть определено отображение, связывающее внешнюю схему с концептуальной схемой.

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

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

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

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

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

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

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

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

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

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

Языковые средства взаимодействия с СУБД

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

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

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

Если СУБД располагает средством связи программы, написанной на каком-либо языке, с БД, то такой язык называется включающим языком (Кобол, С, Паскаль, Clipper и т.п.). Языковыми средствами связи с БД являются языки описания внешних схем и ЯМД.

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

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

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

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

Укрупненно процесс взаимодействия СУБД и прикладной программы состоит из следующих шагов:
1. Прикладная программа обращается к СУБД с запросом на чтение описания внешней модели данных (ВМД);
2. СУБД определяет, из каких записей состоит ВМД и на основе концептуальной модели данных выбирает в рабочую область необходимые записи из хранимой базы;
3. ОС с помощью своих методов доступа считывает информацию в буферы СУБД.
4. На основе описания ВМД и описания соответствующих отображений формируется запись для данной программы пользователя.
5. Сформированная запись из буфера СУБД пересылается в рабочую область прикладной программы и обрабатывается прикладной программой.

При выполнении основных из этих функций СУБД должна использовать различные описания данных [17, 25], которые чаще всего зафиксированы в так называемом словаре данных.

Как отмечалось, инфологическая модель отображает фрагмент предметной области (часть реального мира) в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель "сущность-связь" и т.д. [4]. Наиболее известной из них оказалась модель "сущность-связь", которая рассмотрена в [31]. Распространенность этого подхода объясняется тем, что он изначально ориентировался на СУБД, концептуальная модель которых совпадала с реляционной моделью данных.

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

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

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

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

Следующая глава охватывает основные вопросы теории нормализации, которая является теоретической основой метода проектирования реляционных моделей баз данных. Подчеркнем, что излагаемый материал опирается на так называемую расширенную реляционную модель данных, называемую RMT/T и рассмотренную в работе Кодда [19], (основоположника реляционного подхода), c учетом последних достижений в этой области аккумулированных в работах [3, 5, 18].

Основное отличие обычной реляционной модели от RMT/T заключается во введении внешнего ключа для обеспечения целостности по ссылкам и разделение отношений по различным категориям. При этом распределение отношений по категориям зависит от того, что именно представляется этими отношениями – типы сущностей или типы связей. Категории, в свою очередь, различаются по существованию, ассоциации и стержневым сущностям. Если реализация типа сущности зависит от реализации других типов, то такой тип сущности получает название характеристической [4].

Подобное расширение модели скорее относится к инфологическому этапу формирования модели, но важно, что оно косвенно прописывается (отражается) в описании схемы отношения (в концептуальной модели), в виде явного указания первичных (PRIMARY KEY) и внешних (FOREIGN KEY) ключей отношений, на которых должна контролироваться ссылочная целостность (REFERENCES). Кроме того, явно указываются правила поведения системы при операциях модификации данных (DELETE, UPDATE) [30].

На рис. 2 приведена команда создания отношения из учебного пособия [30] для RM/T модели данных.

CREATE TABLE [dbo].[Ведомость_Оплаты ]
[Ид_Сотр CHAR (5) NOT NULL,
Ид_Отд CHAR (4) NOT NULL,
Период VARCHAR (8) NOT NULL,
Сумма DECIMAL (8,2) NOT NULL,
PRIMARY KEY (Ид_Сотр, Ид_Отд),
FOREIGN KEY (Ид_Сотр) REFERENCES Сотрудник,
ON DELETE CASCADE,
ON UPDATE CASCADE,
FOREIGN KEY (Ид_Отд) REFERENCES Отдел,
ON DELETE CASCADE,
ON UPDATE CASCADE);

Рис. 2. CREATE TABLE для таблицы ВЕДОМОСТЬ_ОПЛАТЫ (рис.3)

Другими словами, если у какого-то сотрудника изменится его Ид_Сотр в базовой таблице СОТРУДНИК, то система автоматически должна отследить это изменение и в отношении ВЕДОМОСТЬ_ОПЛАТЫ (опция ON UPDATE CASCADE).

Ид_Сотр	Ид_Отд	Период	Сумма
		Март
		Март
		Март
		Апрель

Рис. 3. Состояние отношения ВЕДОМОСТЬ_ОПЛАТЫ.

Примечение. В дальнейшем состояние какого-либо отношения R в некоторый момент времени будет обозначаться R_i.

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