В предыдущем параграфе отмечено, что для обеспечения независимости прикладных программ от данных необходимо освободить ПП от сведений о способах и деталях хранимого представления данных и методов доступа к ним, т.е. необходимо ввести модель данных (МД), которая будет отражать информационное содержание БД, однако подробности организации физического хранения данных в ней будут отсутствовать. Модель будет иметь схему, отражающую структуру ее данных, имена записей, имена и форматы полей. Запросы к данным из базы должны выражаться в ПП пользователей с помощью ЯОД и ЯМД и терминов принятой МД. Следовательно, ПП работает с записями модели, которые создаются на момент, когда они затребованы ПП (при чтении данных из базы), либо формируются в ней, а затем данные из этих записей переносятся в БД в хранимые записи (при вводе данных в базу).
Очевидно, что для образования записи модели СУБД должна располагать информацией о том, как эти записи и их поля строятся из хранимых в базе записей и полей (и аналогично обратные преобразования при вводе данных в базу). Эта информация задается АБД в виде специального описания необходимого отображения хранимых в базе данных в данные модели, т.е. на СУБД возлагается задача реализации отображения (прямого и обратного):
Модель «Хранимая БД.
В описании отображения кроме указания соответствий между полями записей модели и полями хранимых записей указываются все необходимые сведения о хранимых данных: в каком коде они представлены, как упорядочены, какие существуют индексы, где расположены те или иные данные, с какими данными они связаны, какие методы доступа необходимо использовать для манипулирования хранимыми данными и т.п.
|
|
Поскольку СУБД функционирует в среде развитых ЭВМ с мощными ОС, целесообразно часть задач обработки данных возложить на ОС. Обычно при проектировании СУБД не разрабатываются программы манипулирования данными на физическом уровне, а используются программы методов доступа ОС. Такой подход обеспечивает возможность относительной независимости операций хранения данных от используемых технических средств. Поэтому вводится в рассмотрение модель представления хранимых данных, или, как ее называют, внутренняя модель БД (ВнМД):
Модель «ВнМД «ФБД.
При проектировании СУБД разрабатываются собственные методы доступа к хранимым записям (к записям ВнМД), базирующиеся на методах доступа к ОС. Во внутренней модели БД может быть представлена в виде совокупности хранимых файлов, для которых известна структура хранимых записей, определены служебные поля, реализующие необходимые связи между записями, известны методы доступа СУБД к этим записям и т.д. В состав СУБД включаются средства преобразования хранимых записей к виду физического представления на машинном носителе и обратно. На рис. 1.2 представлена двухуровневая архитектура БнД.
Пользователи составляют свои прикладные программы, используя только термины МД. СУБД, получив запрос из ПП (например, на чтение данных из базы), организует запрос к ОС на считывание из физической БД (ФБД) необходимой порции данных с машинного носителя в свою буферную область памяти. Таким образом, в буферной памяти СУБД окажутся хранимые записи, имеющие структуру в соответствии со схемой ВнМД. После этого выполняется требуемое отображение хранимых записей в записи модели, а уже затем затребованные записи модели передаются СУБД в рабочую область (РО) ввода–вывода ПП, затребовавшей эти данные.
|
|
Рассмотренная схема решает вопрос обеспечения независимости прикладных программ от данных, позволяет реализовывать определенную независимость системы от используемых технических средств. Однако такая схема, имеющая в своем составе МД, являющуюся глобальным логическим представлением информационного содержимого БД, требует, чтобы пользователь ознакомился с информационным содержимым всей БД. Такая ситуация во многих случаях неприемлема. Во-первых, потому, что каждый отдельный пользователь в большинстве случаев имеет отношение лишь к небольшой, вполне определенной части данных, хранимых в базе, и у него нет никакой необходимости (да и желания) знакомиться со всем ее информационным содержимым. Во-вторых, необходимое пользователю логическое представление требуемой части хранимых данных может отличаться от их логического представления, принятого в МД. Например, его не интересуют многие информационные связи между данными, представленные в модели, но эти связи могут интересовать других пользователей. В-третьих, необходимо обеспечить защиту данных, не имеющих отношения к конкретному пользователю, от его некомпетентных действий.
Модель данных, являясь глобальным логическим представлением информационного содержимого БД, не решает этих вопросов. Поэтому необходимо ввести в рассмотрение еще один уровень логического представления данных – для каждого конкретного пользователя. Такое представление можно обеспечить введением модели для каждого конкретного внешнего представления. Они получили название внешних моделей данных (ВМД). Рассмотренная в предыдущей схеме МД, в связи с тем, что в ней реализуется полнота охвата всего содержимого БД и принятое в ней логическое представление, являясь как бы основной, «синхронизирующей» для конкретного БнД, получила название концептуальной модели (КМД).
|
|
Между ВМД и КМД также должно быть реализовано необходимое отображение. Описание отображения может быть выполнено АБД и введено в систему. ВМД имеет свою схему (иногда ее называют «подсхемой», оставляя термин «схема» для КМД), поскольку ВнМД по существу отражает некоторую часть КМД. На рис. 1.3 представлена трехуровневая архитектура БД, в котором СУБД реализует следующие отображения:
ВМД «КМД «ВнМД «ФБД.
Система управления базой данных реализует обмен данными между РО ввода–вывода прикладных программ и БД. Любой запрос прикладной программы, сформулированный на языке манипулирования данными, поступает в СУБД. Имея соответствующие описания моделей и описания отображений между моделями, СУБД обращается к ОС для выполнения операций на физическом уровне.
Рассмотрим последовательность действий СУБД при формировании записи ВМД для ПП. Примерный алгоритм выполнения операции чтения данных состоит из следующих шагов.
1. Прикладная программа обращается к СУБД с запросом на чтение записи ВМД.
2. Система управления базой данных, используя схему ВМД, схему КМД и описание отображения ВМД на КМД, определяет, какие записи КМД необходимы для формирования записи ВМД,
3. Используя схему КМД, схему ВнМД и описание отображения КМД на ВнМД, СУБД определяет, какие хранимые записи необходимы для построения затребованных записей КМД, и соответственно определяет совокупность физических записей, которые необходимо для этого считать с машинного носителя.
4. Система управления базой данных выдает ОС запрос на считывание в свою буферную область памяти необходимых записей из ФБД.
5. ОС с помощью своих методов доступа считывает из физической памяти (с машинных носителей) затребованные СУБД физические записи и помещает их в системные буфера СУБД. (Сообщения ОС о выполнении этого пункта добавляются к сообщениям СУБД.)
6. На основании имеющихся схем моделей и описаний соответствующих отображений СУБД формирует в буферной памяти запись ВМД в том виде, какой требуется прикладной программе.
7. Система управления базой данных выполняет пересылку сформированной записи ВМД в РО.
8. ОС передает в ПП свои сообщения и сообщения СУБД о результатах выполнения запроса.
9. Прикладная программа выполняет обработку записи, поступившей в ее рабочую область ввода–вывода.
Таким образом, для БД имеются одна ВнС, описывающая ВнМД, одна КС, описывающая КМД, и столько внешних схем (ВС), сколько требуется, чтобы описать различные ВМД, подлежащие реализации.
Описания отображений между МД необязательно должны выполняться АБД. Если формализовать ситуации, возникающие при обмене данными между моделями, то СУБД сможет выполнять необходимые преобразования данных на основании имеющихся схем МД.
Наличие в БнД процессов обмена информацией между пользователями и системой, между АБД и системой, а также между МД различных уровней ставит вопрос об унификации этих процессов, т.е. о разработке соответствующих интерфейсов – языков описания и манипулирования данными на соответствующих уровнях. Интерфейс пользователя представляет собой язык внешнего уровня, с которым работает пользователь при подготовке исходных текстов ПП или формулировке запросов. После трансляции (или интерпретации) ПП (или запроса) операторы языка внешнего уровня поступают на вход СУБД в объектных кодах. Система управления базой данных имеет внутрисистемные интерфейсы для реализации обмена между МД. Для написания и коррекции схем МД АБД также обеспечивается соответствующими языками.
Отметим, что в действительности реальные СУБД имеют большее количество интерфейсов, необходимых для обеспечения различных внутрисистемных операций, для работы обслуживающего персонала, системных программистов и т.д.
Рассмотрим упрощенный вариант одной из возможных схем функционирования БнД в составе АС. Основу СУБД составляют программы, реализующие все необходимые преобразования данных в соответствии с имеющимися в системе интерфейсами. Это преобразователи внутренней (Пр_ВнС), концептуальной (Пр_КС) и внешних (Пр_ВС) схем; преобразователи данных, реализующие отображения «внешний–концептуальный» (Пр_В-К), «концептуальный–внутренний» (Пр_К-Вн), «внутренний–память» (Пр_Вн-П). Таким образом, СУБД можно рассматривать как систему:
СУБД = {Пр_ВнС, Пр_КС, Пр_ВС, Пр_В-К, Пр_К-Вн, Пр_Вн-П}.
Словарь данных (СД) включает в свой состав в минимальном варианте лишь описания схем данных по ПО:
СД = {ВнС, КС, {ВС i, i = 1, n }}.
Администратор базы данных по внешним приложениям формирует в СД системы требуемые ВС и отвечает за то, чтобы эти схемы были согласованы с КС. Администратор базы данных по ПО БнД формирует КС, отвечает за ее состояние, следит за тем, чтобы она соответствовала ПО и поддерживала все внешние приложения, и при необходимости выполняла требуемые коррекции. Администратор базы данных по внутренней модели отвечает за ее сответствие КС, за рациональную организацию данных в памяти системы, а также за обеспечение требуемой производительности. В соответствии с выбранным вариантом организации БД в памяти системы он формирует ВнС и отвечает за ее согласование с КС. Если АБД выполняет реорганизацию БД, то одновременно он выполняет и все соответствующие коррекции ВнС.
Интерфейс пользователя обеспечивается соответствующими трансляторами для входных языков, на которых формируются запросы или составляются ПП. После трансляции процедуры реализации запросов (ПРЗ) или ПП в объектных кодах обращаются к СУБД с требованием на выполнение необходимого обмена данными с базой, указывая при этом имя ВС, в соответствии с которой должен быть выполнен обмен. СУБД обращается к словарю данных, считывает ВнС, КС и соответствующую ВС и настраивается на выполнение необходимых преобразователей данных; затем она считывает требуемые данные из базы и, выполнив все преобразования, передает их в ПП.
Программист, выполнив отладку ПП, передает их в библиотеку функциональных ПП автоматизированной системы для последующей эксплуатации при решении функциональных задач АС. Напомним, что как сами ПП, так и СУБД функционируют под управлением ОС.
Рассмотренный трехуровневый подход к построению БнД, включающий внешний, концептуальный и внутренний уровни, получил наибольшее распространение и признание. При таком подходе на внешнем уровне поддерживаются ограниченные модели ПО, видимые отдельными приложениями (пользователями). На концептуальном уровне поддерживается модель ПО для всех приложений. Хранимые данные также представляют модель ПО для всех приложений, но они выделены в отдельный, внутренний уровень. При такой архитектуре БнД обладает высокой способностью адаптации к возможным изменениям как в ПП, так и в самих данных: любые изменения ВС и ВнС изолированы друг от друга и от КС и могут выполняться независимо. Эта независимость реализуется именно благодаря существованию стабильной КС и соответствующих отображений. Концептуальная схема должна обеспечить стабильную и долговременную работу всей системы. Необходимостью введения внутреннего уровня является обеспечение требований производительности, экономичное использование ресурсов вычислительной системы, обеспечение относительной независимости системы от используемых технических средств.
Объекты в ВМД (внешние записи) создаются при реализации приложений и перестают существовать, когда отпадает необходимость в этих объектах. Объекты ВнМД (внутренние записи) содержат хранимые данные, использующиеся для формирования записей КМД и ВМД. Отметим, что проект КС может содержать описания объектов (концептуальных записей), которые еще не представлены ВнМД. В этом проявляется поэтапность ввода в эксплуатацию такой сложной системы, как БнД.
Может существовать диапазон реализаций функций отображения между моделями и функций манипулирования данными при разработке конкретных СУБД. Этот диапазон определяется компромиссным решением между производительностью системы и ее функциональной гибкостью. На одном ее конце может быть решение, при котором каждой концептуальной записи соответствует внутренняя запись, а каждой внешней записи – концептуальная запись. В этом случае внешняя запись реализуется непосредственно и взаимно однозначно из внутренней записи. Такой вариант обладает высокой производительностью при обработке приложений и наибольшей избыточностью (дублированием) данных со всеми вытекающими отсюда последствиями. На другом конце диапазона находятся системы, в которых сразу на основании схем создается (компилируется) программа для реализации требуемого отображения и с ее помощью выполняется непосредственное формирование внешней записи из внутренних.
На практике чаще встречаются СУБД, реализующие промежуточный вариант, когда вначале из различных внутренних записей формируются концептуальные, из которых затем извлекаются необходимые данные и формируется внешняя запись.
Кроме трех названных уровней абстрагирования в БнД существует еще один уровень, им предшествующий. Модель данных этого уровня должна выражать информацию о ПО в виде, пригодном для использования в различных БнД. С этой моделью ПО работает АБД, а также пользователи системы. Модель должна опираться на их знания и использование естественного языка. Это естественный информационный уровень абстрагирования, связанный с фиксацией и описанием выделенных сведений о ПО. Модель этого уровня называется инфологической моделью ПО.
Переход от одного уровня абстрагирования к другому и составляет в общем случае процесс проектирования БД, представляющий собой сложный процесс проектирования отображения:
Описание ПО ↔ ВнС БД.
Этот процесс представляется последовательностью более простых, обычно итеративных, процессов проектирования менее сложных отображений между промежуточными МД, т.е. процесс проектирования БД представляется последовательностью проектирования МД соответствующих уровней абстрагирования и отображений между этими моделями.
Основные уровни абстрагирования в БнД: внешний, концептуальный, внутренний и предшествующий им информационный. В процессе проектирования БД разрабатываются схемы моделей названных уровней, проверяется возможность отображения объектов одной модели объектами другой модели.
Основные этапы проектирования БД: инфологическое и датологическое проектирования, причем последнее подразделяют на логическое и физическое проектирования.
В зависимости от этапа различают инфологическую и датологическую КМД (последнюю обычно называют просто концептуальной), инфологическую и датологическую ВМД.
Задачей инфологического этапа проектирования БД является получение семантических (смысловых) МД, отражающих информационное содержание конкретной ПО. На этом этапе выполняются восприятие реальной действительности, абстрагирование, изучение и описание ПО. Вначале из воспринимаемой реальности выделяется требуемая часть ПО, устанавливаются ее границы, происходит абстрагирование от несущественных частей для данного конкретного применения БнД. В результате этих действий определяются объекты, их свойства и связи, которые будут существенны для будущих пользователей системы. После этого происходит процесс изучения ПО, накопление знаний о ней и представление их в какой-либо языковой системе. Обычно это неформализованное описание с использованием естественного языка, математических формул, диаграмм связей и т.д.
Выполняется структуризация знаний ПО – выделяются и классифицируются множества составляющих ПО, стандартизируется терминология. Затем осуществляется композиция инфологической КМД, в процессе которой основную роль играют потребности пользователей, а также описание информации, требуемой каждому конкретному пользователю (т.е. описание запросов к БД). Каждый запрос соотносится с определенным фрагментом ПО. Далее формируются описания инфологических ВМД, их взаимная увязка с инфологической КМД. Полученные описания инфологических моделей отражают составляющие ПО, связи между ними, но они не должны зависеть от методов представления данных в конкретной СУБД.
Концептуальная инфологическая модель призвана обеспечить прочную и долговременную работу всей системы. Эта модель должна выдерживать замену одной используемой СУБД на другую.
Задачей логического этапа проектирования является организация данных, выделенных на предыдущем этапе проектирования, в такую форму, которая принята в выбранной СУБД. Иными словами, требуется разработать схему КМД и схемы ВМД, пользуясь только теми типами моделей и их особенностями, которые поддерживаются выбранной СУБД. На этом этапе проектирования обычно не прорабатываются вопросы, связанные с организацией доступа к данным, однако целесообразно получить вполне определенные рекомендации по выбору методов доступа.
Задачей физического этапа проектирования является выбор рациональной структуры хранения данных и методов доступа к ним, исходя из того арсенала методов и средств, который предоставляется разработчику используемой СУБД.