Обобщенная архитектура субд. Общая архитектура субд

Детские товары 15.07.2019

Детские товары

Каждая система управления базой данных должна удовлетворять следующим требованиям:

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

В информационной системе с БД можно выделить несколько компонентов.

1. Пользователи - люди, которые используют информацию, находящуюся в БД. Принято выделять следующие группы пользователей: системные администраторы - отвечают за основные операции системы; администраторы базы данных - управляют работой СУБД и обеспечивают функционирование базы данных; проектировщики базы данных - разрабатывают структуру БД; системные аналитики - определяют основные функции системы базы данных и проектируют формы ввода данных, отчеты и процедуры, с помощью которых обеспечиваются доступ к данным и манипулирование ими (их добавление, изменение, удаление); программисты - создают программный код; непосредственные пользователи - используют прикладные программы для выполнения необходимых операций по автоматизации своей деятельности.
2. Приложения - программы пользователей, которым необходима информация из системы.
3. Система управления базой данных - ПО, управляющее доступом к данным и обеспечивающее указанные функциональные возможности ИС с БД.
4. Информация - обработанные данные (строки, хранящиеся в файлах).
5. Хост-система - компьютерная система, в которой хранятся файлы. Доступ к строкам данных осуществляется хост-системой. Роль СУБД состоит в том, чтобы генерировать запросы, позволяющие использовать функциональные возможности системы управления файлами хост- системы для обслуживания различных приложений. СУБД представляет собой дополнительный уровень ПО, надстроенный над программным обеспечением хост-системы.
6. Оборудование - все системные программные средства (универсальный компьютер, персональный компьютер, ноутбук, карманный компьютер).
7. Периферийные устройства - физические устройства, обеспечивающие ввод/вывод, а также электронные устройства для подключения дополнительных компьютеров и организации сети.

Графическая интерпретация ИС с БД в виде логической последовательности уровней представлена на рис. 3.1.

Рис. 3.1

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

Обычно современная СУБД содержит следующие компоненты:

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

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

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

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

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

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

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

В 1978 г. комитетом ANSI/SPARC (ANSI, American National Standard Institute - Национальный институт стандартизации США; SPARC,

Standard Planning and Requirements Committee - Комитет планирования стандартов и норм) официально зафиксировано различие между логическим и физическим представлением данных. В частности, была предложена обобщенная структура систем с базой данных. Эта структура получила название трехуровневой архитектуры, включающей внутренний, концептуальный и внешний уровни (рис. 3.2).

Рис. 3.2.

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

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

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

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

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

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

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

Исходя из различных схем БД в трехуровневой модели, следует, что СУБД должна устанавливать соответствие и следить за непротиворечивостью перечисленных схем.

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

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

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

Независимость бывает двух типов:

логическая - полная защищенность внешних схем от изменений, которые вносятся в концептуальную схему;
физическая - защищенность концептуальной схемы от изменений, которые вносятся во внутреннюю схему.

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

1. Архитектура СУБД

Три уровня архитектуры.

Архитектура ANSI/SPARC включает три уровня: внутренний, концептуальный и внешний. В общих чертах они представляют собой следующее:

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

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

Концептуальный уровень-это «промежуточный» уровень между двумя первыми.

Внешний уровень (индивидуальные представления пользователей).

Концептуальный уровень (обобщенное представление пользователей).

Внутренний уровень (представление в памяти).

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

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

У каждого пользователя есть свой язык общения.

Для прикладного программиста это либо один из распространенных языков программирования, такой как C, COBOL или PL/1, либо специальный язык рассматриваемой системы. Такие оригинальные языки называют (неформально!) языками четвертого поколения на том основании, что машинный код, язык ассемблера и такие языки, как COBOL, можно считать языками трех первых «поколений», а оригинальные языки модернизированы по сравнению с языками третьего поколения так же, как языки третьего поколения улучшены по сравнению с языком ассемблера.

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

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

Язык обработки данных состоит из таких выполняемых операторов PL/1, которые передают информацию в и из БД; опять же, возможно, включая, новые специальные операторы.

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

Концептуальный уровень.

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

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

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

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

Теперь?перейдем к более детальному исследованию трех уровней архитектуры.

Внутренний уровень.

Третьим уровнем архитектуры является внутренний уровень. Внутреннее представление - это представление нижнего уровня всей БД; оно состоит из многих экземпляров каждого типа внутренней записи. Термин «внутренняя запись» принадлежит терминологии ANSI/SPARC и означает конструкцию, называемую хранимой записью. Внутреннее представление так же, как внешнее и концептуальное, не связано с физическим уровнем, так как в нем не рассматриваются физические области устройства хранения, такие как цилиндры и дорожки. Другими словами, внутреннее представление предполагает бесконечное линейное адресное пространство; подробности того, как адресное пространство отображено на физическое устройство хранения, очень зависят от системы и умышленно не включены в общую архитектуру.

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

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

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

Базы данных и программные средства их создания и ведения (СУБД) имеют многоуровневую архитектуру.

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

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

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

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

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

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

Основные положения этой концепции:

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

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

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

Трехуровневая архитектура базы данных

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

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

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

внешний уровень, на котором пользователи воспринимают данные, где отдельные группы пользователей имеют свое представление (ПП) на базу данных;

внутренний уровень, на котором СУБД и операционная система воспринимают данные;

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

Данная архитектура СУБД вызревала не сразу, а постепенно, в течение ряда лет. Первые предложения поступили в 1971 году от рабочей группы CODASYL (Conference on Data Systems and Languages -- Конференция по языкам и системам данных), которая обосновала необходимость использования двухуровневого подхода, построенного на основе выделения системного представления и пользовательских представлений.

В 1975 году Комитет планирования стандартов и норм SPARC (Standards Planning and Requirements Committee) Американского национального института стандартов ANSI (American National Standards Institute) предложил обобщенную структуру систем баз данных, признав необходимость использования трехуровневой архитектуры, которая и была официально признана в 1978 году.

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

Рис. Трехуровневая архитектура СУБД

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

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

Внешний уровень

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

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

Какой бы язык высокого уровня не использовался (он в этом случае называется базовым), он должен включать в себя и подъязык для работы с данными. Система может поддерживать любое количество подъязыков данных, любое количество базовых языков. ]Но язык__Ј(ЗЬ поддерживается практически всеми системами. Он может использоваться и как встроенный в другие языки, и как отдельный самостоятельный язык запросов.

Концептуальный уровень

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

Концептуальная схема должна содержать:

объекты и их атрибуты;

связи между объектами;

ограничения, накладываемые на данные;

семантическую информацию о данных;

обеспечение безопасности и поддержки целостности данных.

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

Внутренний уровень

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

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

На внутреннем уровне хранится следующая информация:

распределение дискового пространства для хранения данных и индексов; П описание подробностей сохранения записей (с указанием реальных размеров сохраняемых элементов данных);

сведения о размещении записей;

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

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

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

Итак, подведем итоги.

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

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

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

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

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

2. Базы данных. Схема данных. Независимость уровней от данных

пользователь информационный запись

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

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

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

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

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

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

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

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

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

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

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

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

Таблицы и их атрибуты

Связи между таблицами

Ограничения, накладываемые на данные

Семантику данных

В концептуальной схеме данных должны быть учтены аспекты безопасности и целостности данных

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

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

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

Любая внутренняя схема данных обязательно хранит в себе:

То, как должно быть распределено дисковое пространство для хранения данных и индексы

Информацию о сохраненных записях

Сведения о уже имеющихся записях

Сведения о способах шифрования и сжатия данных

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

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

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

пользователь информационный хранимый запись

Размещено на Allbest.ru

Подобные документы

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

лекция , добавлен 19.08.2013

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

курсовая работа , добавлен 21.03.2015

Создание базы данных. Поиск, изменение и удаление записей. Обработка и обмен данными. Проектирование базы данных. Определение формул для вычисляемой части базы. Редактирование полей и записей. Формы представления информации, содержащейся в базе данных.

курсовая работа , добавлен 23.02.2009

Краткая история развития СУБД ORACLE, основные понятия и определения, архитектура. Принципы работы с СУБД ORACLE. Разработка баз данных, средства и технологии их реализации; возможности процедурного языка PL/SQL. Приемы администрирования СУБД ORACLE.

презентация , добавлен 14.02.2014

Принципы построения СУБД, их достоинства. Архитектура распределенной информационной системы. Разработка интернет-магазина рынка книг: построение физической модели данных на языке SQL, проектирование схемы базы данных с использованием веб-интерфейса.

курсовая работа , добавлен 01.11.2011

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

курсовая работа , добавлен 14.02.2011

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

реферат , добавлен 27.12.2013

Теоретические аспекты СУБД. Основные понятия. Функциональные возможности СУБД. Архитектура систем управления. Разработка базы данных. Крупные массивы данных размещают, как правило, отдельно от исполняемого программы, и организуют в виде базы данных.

курсовая работа , добавлен 23.02.2006

Архитектура "клиент-сервер". Параллельная обработка данных в многопроцессорных системах. Модернизация устаревших информационных систем. Характерные черты современных серверных СУБД. Наиболее популярные серверные СУБД. Распределенные запросы и транзакции.

курсовая работа , добавлен 11.11.2011

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

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

Рис. 1.11.

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

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

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

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

Клиент-серверные (двухзвенные) системы значительно снижают нагрузку на сеть, так как клиент общается с данными через специализированного посредника - сервер БД, который размещается на машине с базой данными. Сервер БД принимает запрос от клиента, отыскивает в данных нужную запись и передает ее клиенту. Таким образом, но сети передаются относительно короткий запрос и единственная нужная запись, даже если база данных содержит сотни тысяч записей. Как правило, запрос к серверу формируется на специальном языке запросов SQL, поэтому часто серверы БД называются SQL-серверами. Серверы БД представляют собой относительно сложные программы, разрабатываемые различными фирмами, например: Microsoft SQL Server (SQL Server) производства корпорации Microsoft, Sybase Adaptive Server корпорации Sybase, Oracle производства одноименной корпорации, DB2 корпорации IBM, InterBase корпорации Borland и т.д. Клиент-серверные СУБД обеспечивают функционирование, или масштабируются, до сотен и тысяч клиентских мест.

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

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

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

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

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

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

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

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

Архитектура СУБД

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

Внешний уровень

Внешний уровень - это индивидуальный уровень пользователя. У каждого пользователя есть свой язык общения.

Для прикладного программиста это либо один из распространенных языков программирования.

Концептуальный уровень

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

Внутренний уровень

Внутреннее представление - это представление нижнего уровня всей БД; оно состоит из многих экземпляров каждого типа внутренней записи.

Термин "внутренняя запись" принадлежит терминологии ANSI/SPARC и означает конструкцию, называемую хранимой записью. Внутреннее представление так же, как внешнее и концептуальное, не связано с физическим уровнем, так как в нем не рассматриваются физические области устройства хранения, такие как цилиндры и дорожки. Другими словами, внутреннее представление предполагает бесконечное линейное адресное пространство; подробности того, как адресное пространство отображено на физическое устройство хранения, очень зависят от системы и умышленно не включены в общую архитектуру.

Локальная архитектура.

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

Файл - серверная архитектура.

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

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

Клиент - серверная архитектура.

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

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

Распределенная архитектура.

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

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

Интернет-архитектура.

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

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

Обобщенная архитектура субд. Общая архитектура субд

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Подобные документы

Архитектура СУБД

Рекомендуем почитать

Поиск по сайту