Автоматизированные банки данных в системах управления водным транспортом. Учебное пособие

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

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

< Внешняя модель концептуальная модель внутренняя модель физическая база данных >

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

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

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

1.ПП обращается в СУБД с запросом на чтение записи ВМД;

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

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

4.СУБД выдает ОС запрос на считывание в свою буферную область памяти необходимых записей из ФБД;

Рис.8. Последовательность действий СУБД при обработке запросов

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

7.СУБД пересылает сформулированную запись ВМД в РО вводавывода прикладной программы;

8.СУБД передает в ПП свои сообщения и сообщения ОС о результатах выполнения запроса;

9.ПП обрабатывает запись, поступившую в ее РО ввода-вывода. Таким образом для БД имеется одна внутренняя схема,

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

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

Интерфейсы администратора банка данных (И6, И7, И8) представляют собой соответствующие языки, предназначенные для написания и коррекции схем моделей системы.

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

Рассмотрим упрощенный вариант одной из схем функционирования банка данных (рис. 10) в составе АС.

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

(Пр“Вн-П”).

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

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

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

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

Среда хранения

Рис.10. Схема функционирования банка данных в составе АС

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

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

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

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

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

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

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

Могут существовать варианты реализации функций отображения между моделями и функций манипулирования данными при разработке

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

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

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

Переход от одного уровня абстракции в представлении данных к другому и составляет в общем случае процесс проектирования БД.

4.Процессы обработки данных в автоматизированных системах

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

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

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