рефераты конспекты курсовые дипломные лекции шпоры

Реферат Курсовая Конспект

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

Архитектура банка данных. - раздел Информатика, Организация Баз Данных Для Обеспечения Независимости Прикладных Программ От Данных Необходимо Ввести...

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

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

"Модель<->физическая база данных".

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

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

"Модель<->внутренняя модель<->физическая база данных".

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

 

 

 


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

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

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

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

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

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

 

 

Пользователи П1 П2   Пn

 
 

 

 


Рис. 1.8. Трехуровневая архитектура банка данных.

 

1) прикладная программа обращается к СУБД с запросом на чтение записи внешней модели данных;

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

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

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

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

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

7) СУБД пересылает сформированную запись внешней модели данных в рабочую область ввода-вывода прикладной программы;

8) СУБД передает в прикладную программу свои сообщения и сообщения операционной системы о результатах выполнения запроса;

9) прикладная программа обрабатывает запись, поступившую в ее рабочую область ввода-вывода.

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

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

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

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

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

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

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

 

 

– Конец работы –

Эта тема принадлежит разделу:

Организация Баз Данных

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

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

Что будем делать с полученным материалом:

Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:

Все темы данного раздела:

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

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

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

Банк данных как автоматизированная система.
  Банк данных включает следующие основные компоненты: базу данных (БД); систему управления базой данных (СУБД); администратора базы данных (АБД); словарь данных; вычислительную систем

ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ.
Процесс проектирования базы данных представляет собой сложный процесс проектирования отображения: "Описание предметной области"<-->"схема внутренней модели базы данных

ИНФОЛОГИЧЕСКИЙ ПОДХОД К ПРОЕКТИРОВАНИЮ ИНФОРМАЦИОННЫХ СИСТЕМ.
База данных - это некоторая целевая модель предметной области, т.е. в базе данных находят отражение только те факты о предметной области, которые необходимы для функционирования АС, в состав которо

МОДЕЛИРОВАНИЕ ЛОКАЛЬНЫХ ПРЕДСТАВЛЕНИЙ
  Моделирование локальных проектных представлений завершается построением модели локального представления. Выбор локального представления зависит от масштабов предметной области. Для

ОБЪЕДИНЕНИЕ МОДЕЛЕЙ ЛОКАЛЬНЫХ ПРЕДСТАВЛЕНИЙ
  При объединении моделей локальных представлений проектировщик может формировать конструкции, являющиеся производными по отношению к понятиям, использованным в локальных представлени

ЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ
  Под базой данных будем понимать совокупность взаимосвязанных данных, хранящихся вместе при наличии такой минимальной избыточности, которая допускает их использование оптимальным обр

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

Полная функциональная зависимость
Атрибут (или набор атрибутов) В из отношения R называется полностью зависимым от другого набора атрибутов А отношения R, если В функционально зависит от всего множества А, но не зависит от ни от ка

Транзитивная зависимость.
Пусть А,В и С – три атрибута или три набора атрибутов отношения R. Если С зависит от В, а В - от А, то С зависит от А. Если при этом обратное соответствие неоднозначно (т.е. А не зависит от В или В

Хотите получать на электронную почту самые свежие новости?
Education Insider Sample
Подпишитесь на Нашу рассылку
Наша политика приватности обеспечивает 100% безопасность и анонимность Ваших E-Mail
Реклама
Соответствующий теме материал
  • Похожее
  • Популярное
  • Облако тегов
  • Здесь
  • Временно
  • Пусто
Теги