Remkomplekty.ru

IT Новости из мира ПК
18 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Функции приложения бд при локальной архитектуре

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

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

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

Основной функцией компилятора языка БД является компиляция операторов языка БД в некоторую выполняемую программу.

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

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

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

Местоположение Ядра БД и баз данных зависит от используемой архитектуры. Имеется четыре разновидности архитектур баз данных:

* локальные базы данных; ‘ архитектура «файл-сервер»;

* многозвенная (трехзвенная N-tier или multi-tier) архитектура.

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

Локальные базы данных и архитектура «файл-сервер»

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

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

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

Кардинальных различий с точки зрения архитектуры между одно-пользовательской архитектурой и архитектурой «файл-сервер» нет. И в том. и в ином случае в качестве СУБД применяются так называемые «персональные» (или «локальные») СУБД. такие как Paradox, dBase и пр. Сама база данных в этом случае представляет собой набор таблиц, индексных файлов, файлов полей комментариев (мемо-полей) и пр., хранящихся в одном каталоге на диске в виде отдельных файлов.[4].

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

3.3. Технология «клиент – сервер»

Использование технологии » клиент – сервер » предполагает наличие некоторого количества компьютеров, объединенных в сеть , один из которых выполняет особые управляющие функции (является сервером сети).

Так, архитектура » клиент – сервер » разделяет функции приложения пользователя (называемого клиентом) и сервера. Приложение -клиент формирует запрос к серверу, на котором расположена БД , на структурном языке запросов SQL (Structured Query Language ), являющемся промышленным стандартом в мире реляционных БД . Удаленный сервер принимает запрос и переадресует его SQL -серверу БД . SQL — сервер – специальная программа , управляющая удаленной базой данных. SQL — сервер обеспечивает интерпретацию запроса, его выполнение в базе данных, формирование результата выполнения запроса и выдачу его приложению-клиенту. При этом ресурсы клиентского компьютера не участвуют в физическом выполнении запроса; клиентский компьютер лишь отсылает запрос к серверной БД и получает результат, после чего интерпретирует его необходимым образом и представляет пользователю. Так как клиентскому приложению посылается результат выполнения запроса, по сети «путешествуют» только те данные, которые необходимы клиенту. В итоге снижается нагрузка на сеть . Поскольку выполнение запроса происходит там же, где хранятся данные (на сервере), нет необходимости в пересылке больших пакетов данных. Кроме того, SQL — сервер , если это возможно, оптимизирует полученный запрос таким образом, чтобы он был выполнен в минимальное время с наименьшими накладными расходами [ [ 3.2 ] , [ 3.3 ] ]. Архитектура системы представлена на рис. 3.3.

Все это повышает быстродействие системы и снижает время ожидания результата запроса. При выполнении запросов сервером существенно повышается степень безопасности данных, поскольку правила целостности данных определяются в базе данных на сервере и являются едиными для всех приложений, использующих эту БД . Таким образом, исключается возможность определения противоречивых правил поддержания целостности. Мощный аппарат транзакций, поддерживаемый SQL -серверами, позволяет исключить одновременное изменение одних и тех же данных различными пользователями и предоставляет возможность откатов к первоначальным значениям при внесении в БД изменений, закончившихся аварийно [ [ 3.2 ] , [ 3.3 ] ].

Итак, в результате работа построена следующим образом:

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

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

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

    В архитектуре » клиент – сервер » работают так называемые «промышленные» СУБД . Промышленными они называются из-за того, что именно СУБД этого класса могут обеспечить работу информационных систем масштаба среднего и крупного предприятия, организации, банка. К разряду промышленных СУБД принадлежат MS SQL Server , Oracle , Gupta, Informix , Sybase , DB2 , InterBase и ряд других [ [ 3.2 ] ].

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

    Рассмотрим основные достоинства данной архитектуры по сравнению с архитектурой » файл — сервер «:

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

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

    3.4. Трехзвенная (многозвенная) архитектура «клиент – сервер».

    Трехзвенная (в некоторых случаях многозвенная ) архитектура (N- tier или multi- tier ). представляет собой дальнейшее совершенствование технологии » клиент – сервер «. Рассмотрев архитектуру » клиент – сервер «, можно заключить, что она является 2-звенной: первое звено – клиентское приложение , второе звено – сервер БД + сама БД . В трехзвенной архитектуре вся бизнес-логика (деловая логика), ранее входившая в клиентские приложения, выделяется в отдельное звено, называемое сервером приложений. При этом клиентским приложениям остается лишь пользовательский интерфейс . Так, в качестве клиентского приложения в описанном выше примере выступает Web-браузер.

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

    Итак, в результате работа построена следующим образом:

    Архитектура базы данных: понятие, определение, уровни

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

    Что это?

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

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

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

    Виды БД

    Архитектура систем управления базами данных будет различной в зависимости от разновидности последних. На сегодня выделяется два вида БД:

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

    Централизованные базы данных

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

    Распределенные базы данных

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

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

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

    Типы БД по способу доступа к ним

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

    • Доступ локальный.
    • Доступ удаленный (сетевой).

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

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

    БД «файл-сервер»

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

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

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

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

    БД «клиент-сервер»

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

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

    Что предполагает архитектура клиент-серверных баз данных? Клиентское приложение здесь оформляет и отправляет запрос удаленному компьютеру-серверу, где расположено централизованное хранилище информации. Он (запрос) составлен на специальном языке SQL — стандарте доступа к серверу при использовании реляционных БД.

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

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

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

    Архитектура баз данных подразделяется на три основных уровня — три степени описания элементов БД:

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

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

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

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

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

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

    Не стоит полагать, что ненужные для пользователя атрибуты, сущности и связи не существуют в базе данных. Они есть, но «юзер» чаще всего не подозревает об их существовании.

    Если обратиться к терминологии ANSI/SPARC (Американского национального института стандартов), то представление каждого отдельного пользователя здесь будет называться внешним. В него будет входить содержимое БД — такое, каким его видит конкретный «юзер». Каждое такое внешнее представление определяется посредством внешней системы. Она же состоит из определения записи каждого типа, присутствующего во внешнем представлении.

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

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

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

    Элементы концептуального уровня

    Перечислим компоненты, представленных на концептуальном уровне архитектуры:

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

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

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

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

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

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

    Элементы внутреннего уровня

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

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

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

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

    Введение в базы данных. Базы данных, системы управления базами данных, банки данных. Организация баз данных: иерархическая, сетевая, реляционная и объектная.

    База данных – это некоторый набор перманентных (постоянных) данных, используемых прикладными системами какого-либо предприятия [Ошибка! Источник ссылки не найден.].

    База данных – это средство для рационального и эффективного хранения информации [Ошибка! Источник ссылки не найден.].

    База данных – это самодокументированное собрание интегрированных записей [Ошибка! Источник ссылки не найден.]. База данных является самодокументированной, так как она содержит в дополнение к исходным данным пользователя, описание собственной структуры.

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

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

    · пользователь формирует запрос на доступ к данным, применяя определенный язык манипулирования данными (обычно это SQL);

    · СУБД получает этот запрос и анализирует его;

    · СУБД выполняет необходимые операции в хранимой базе данных;

    · СУБД возвращает приложению данные, удовлетворяющие поставленному запросу.

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

    По характеру использования СУБД разделяют на:

    Персональная СУБД обеспечивает возможность создания локальных БД, работающих на одном компьютере. К персональным СУБД относятся Рагаdох, dBase, FохРго, Ассеss (ранних версий) и др.

    Многопользовательские СУБД позволяют создавать информационные системы, функционирующие в архитектуре «клиент-сервер». К многопользовательским СУБД относятся Огас1е, Informiх, SyBase, Мiсгоsoft SQL Server, InterBasе и другие.

    В состав языковых средств современных СУБД входят:

    · язык описания данных, предназначенный для описания логической структуры данных (DDL Data Definition Language);

    · язык манипулирования данными, обеспечивающий выполнение основных операций над данными – ввод, модификацию и выборку (DML Data Manipulation Language);

    · язык структурированных запросов (SQL Structured Query Language), обеспечивающий управление структурой БД и манипулирование данными, а также являющийся стандартным средством доступа к удаленным БД;

    · язык запросов по образцу (QВЕ – Query Ву Ехаmp1е), обеспечивающий визуальное конструирование запросов к БД.

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

    · манипулирование данными (хранение, извлечение и обновление);

    · сервис (поддержание целостности, справочные функции, восстановление базы).

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

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

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

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

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

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

    В сетевой модели данные организуются в виде произвольного графа (рис.3.3). Недостатком сетевой модели является жесткость структуры и высокая сложность организации.

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

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

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

    Архитектура СУБД. Архитектура баз данных. Логическая структура СУБД. Описание данных в базе данных. Базы данных схема данных

    • 08.12.2012
    • Базы данных
    • 2 комментария

    Здравствуйте, уважаемые посетители моего скромного блога для начинающих вебразработчиков и web мастеров ZametkiNaPolyah.ru. Продолжаем рубрику Заметки о MySQL, в которой уже были публикации: Нормальные формы и транзитивная зависимость, избыточность данных в базе данных, типы и виды баз данных, настройка MySQL сервера и файл my.ini, MySQL сервер, установка и настройка. Сегодня мы поговорим о логической структуре СУБД и архитектуре баз данных. Как всегда, я постараюсь описать архитектуру СУБД на простом и понятном языке, без всяких сложных и умных слов.

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

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

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

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

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

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

    Для наглядности можете посмотреть на рисунок, на нем продемонстрирована структура трехуровневой СУБД:

    Структура базы данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    1. Таблицы и их атрибуты
    2. Связи между таблицами
    3. Ограничения, накладываемые на данные
    4. Семантику данных
    5. В концептуальной схеме данных должны быть учтены аспекты безопасности и целостности данных

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

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

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

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

    • То, как должно быть распределено дисковое пространство для хранения данных и индексы
    • Информацию о сохраненных записях
    • Сведения о уже имеющихся записях
    • Сведения о способах шифрования и сжатия данных

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

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

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

    Читать еще:  Дана архитектура глобальной сети
Ссылка на основную публикацию
ВсеИнструменты
Adblock
detector
×
×