Исследовательской группой ANSI-SPARC (ANSI - American National Standard Institute и SPARC - Standards Planning and Requirements Committee) были предложены три уровня абстракции для организации структуры базы данных. Это внешний , концептуальный и внутренний уровни описания данных.
Именно на основе архитектуры ANSI-SPARC базируется архитектура большинства современных СУБД.
Определение Внешний уровень - это уровень, на котором данные воспринимаются пользователем или уровень пользователя. Он состоит из ряда различных внешних пользовательских представлений базы данных. При этом различные представления могут по-разному отображать дни и те же данные.
Определение Концептуальный уровень _ это общее представление БД, описывающее все данные, которые хранятся в ней. Этот уровень содержит логическую структуру всей базы данных. Именно на этом уровне представлены следующие компоненты:
Важно отметить, что представление данных на концептуальном уровне не зависит от способа их хранения, но на этом уровне поддерживается любое внешнее представление.
Определение Внутренний уровень - это физическое представление информации в компьютере. Этот уровень содержит описание структур данных и организации отдельных файлов для хранения данных на физических устройствах.
Определение Схемой базы данных называется ее описание. В соответствии с уровнями абстракции определяются и типы схем базы данных: совокупность внешних схем (соответствующих отдельным представлениям данных), концептуальная и внутренняя схемы. Именно концептуальная схема описывает все сущности, атрибуты и связи между ними. Наконец, внутренняя схема есть полное описание физической структуры данных.
СУБД отвечает за взаимное соответствие перечисленных схем и за проверку их непротиворечивости. В рамках СУБД реализованы так называемые концептуально внутреннее и концептуально-внешнее отображения . Первое связывает концептуальную схему с внутренней и позволяет находить в памяти компьютера фактические записи, отвечающие логическим записям в концептуальной схеме. Второе позволяет СУБД отображать пользовательские представления на соответствующие части концептуальной схемы.
Подчеркнем, что изменения, вносимые на нижних уровнях абстракции, не влияют на верхние уровни. Так, внешние схемы защищены от изменений, производимых на концептуальном уровне, а концептуальная схема защищена от изменений, вносимых во внутреннюю схему. Таким образом трехуровневая архитектура определения данных обеспечивает независимость программ от данных .
Как называется совокупность основных структурных, функциональных компонентов различных БД, Этот комплекс в информационной науке принято называть архитектурой Предлагаем вам досконально разобрать это понятие, типы подобных комплексов, их трехуровневое разбиение.
Архитектура базы данных - комплекс структурных компонентов БД, а также средств, обеспечивающих их взаимодействие как друг с другом, так и с конечным пользователем, системным персоналом.
Данное определение отражает одну из важнейших функций хранилищ информации - обеспечение возможности абстракции сведений БД. Она и формирует сложившийся в наши дни подход к архитектуре данных.
Отсюда возникает новый вопрос: в чем суть, предназначение абстракции данных? Предоставляемые системой, они (абстракции) будут основным средством поддержки независимости ведения хранилищ информации (другими словами, БД) разными группами конечных пользователей. По-иному это называется независимостью данных системы.
Управления базами данных будет различной в зависимости от разновидности последних. На сегодня выделяется два вида БД:
С особенностями каждой из разновидностей мы предлагаем читателю ознакомиться далее.
Главное отличие этих БД: они хранятся в памяти одной вычислительной системы. Но если база, в свою очередь, будет компонентом сетей ЭВМ, то становится возможным распределенный доступ к базам данных. То есть БД будет открытой для пользователей электронно-вычислительных машин, подключенных к данной сети. Подобное использование характерно для локальных систем ЭВМ, создаваемых на базе организаций, компаний.
Что важно знать об архитектуре распределенных баз данных? Такие БД состоят из нескольких частей, хранящихся в различных ЭВМ одной сети. Возможно, информация тут будет дублироваться, пересекаться. Что удобно, пользователю распределенной базы данных не нужно знать, каким образом элементы хранилища информации размещены в узлах подобной сети. Чаще всего он воспринимает этот комплекс сведений как единое целое.
Как осуществляется работа с подобной БД? С помощью системы управления распределенными базами данных (СУРБД). Ее системный справочник будет описывать информацию, содержащуюся в хранилище данных, основы ее размещения в сети. В свою очередь, сам справочник может быть декомпозирован, размещен в различных узлах общей сети.
Составные части распределенной БД размещаются на отдельных подключенных к ней ЭВМ. Ими управляют уже собственные (локальные) СУБД электронно-вычислительных устройств. Что важно отметить, подобные локальные системы управления хранилищами информации необязательно должны быть одинаковыми в различных узлах общей сети. Однако объединение таковых различных локальных баз данных в единую систему - весьма сложная научно-техническая задача. Для ее успешного решения потребовался целый комплекс экспериментальных мероприятий, теоретических разработок.
Архитектура базы данных также будет различаться по способу доступа к находящейся в хранилище информации:
Последний тип доступа предполагает разделение архитектуры подобных систем еще на две вариации:
Снова предлагаем читателю разобраться с представленными разновидностями подробнее.
Подобная архитектура комплексов баз данных предполагает выделение одного из устройств сети ЭВМ в качестве центрального. Оно будет считаться сервером файлов. На главной машине хранится совместно используемая централизованная база данных. Другие же устройства сети выступают рабочими станциями, которые поддерживают пользовательский доступ к основной БД.
В системе "файл-сервер" каждый пользователь имеет возможность запускать приложение, находящееся на главной машине. Притом на его устройстве будет открываться только копия данной программы.
По пользовательским запросам файлы центральной базы данных (находящейся на сервере) передаются на компьютеры - рабочие станции. Там и происходит обработка информации. У пользователей, работающих с общей БД, на компьютерах появляется локальная ее копия. Последняя периодически обновляется по мере наполнения основного хранилища на сервере свежей информацией.
Подобная архитектура систем БД более всего характерна для сетей, к которым подключено небольшое число пользователей. Для ее реализации типично использование персональных СУБД (к примеру, Paradox, DBase). Недостатком архитектуры является критически низкая производительность системы при одновременном доступе нескольких пользователей к одним и тем же данным.
Здесь также предполагается наличие машины в сети, которая будет являться главной. Однако архитектура базы данных "клиент-сервер" имеет и собственную особенность. Главный компьютер не только хранит централизованную БД, но и обеспечивает основную часть обработки требуемых пользователю данных.
Технология разделяет систему на две части: серверную и клиентскую. Последняя будет обеспечивать интерактивный сервис, а серверная - разделение информации, управление данными, безопасность и администрирование.
Что предполагает архитектура клиент-серверных баз данных? Клиентское приложение здесь оформляет и отправляет запрос удаленному компьютеру-серверу, где расположено централизованное хранилище информации. Он (запрос) составлен на специальном языке SQL - стандарте доступа к серверу при использовании реляционных БД.
После получения запроса перенаправляет его SQL-серверу. Так называется программа, ответственная за управление удаленной базой данных. Она обеспечивает выполнение запроса, предоставляет клиенту требуемые результаты по нему.
Таким образом, вся обработка запросов здесь будет проходить на удаленном сервере. Чтобы реализовать подобную архитектуру, необходимо задействовать многоуровневые СУБД. Второе их название - промышленные. Такие СУБД способны организовать масштабную инфосистему, состоящую из большого числа пользователей.
Архитектура баз данных подразделяется на три основных уровня - три степени описания элементов БД:
Предлагаем читателю более подробно познакомиться с каждой из вышепредставленных степеней.
Внешний уровень архитектуры систем баз данных - это предоставление информации с позиции людей-пользователей.
Что из этого следует? Уровень описывает пользовательскую часть баз данных (относящихся к каждому пользователю). В свою очередь, она будет состоять из нескольких внешних представлений хранилищ информации, БД.
Что удобно, каждый пользователь здесь имеет дело с таким образом "реального мира", который более всего адаптирован под него. Внешнее представление будет содержать в себе только те сущности, связи и атрибуты, что интересны и полезны конкретному "юзеру".
Не стоит полагать, что ненужные для пользователя атрибуты, сущности и связи не существуют в базе данных. Они есть, но "юзер" чаще всего не подозревает об их существовании.
Если обратиться к терминологии ANSI/SPARC (Американского национального института стандартов), то представление каждого отдельного пользователя здесь будет называться внешним. В него будет входить содержимое БД - такое, каким его видит конкретный "юзер". Каждое такое внешнее представление определяется посредством внешней системы. Она же состоит из определения записи каждого типа, присутствующего во внешнем представлении.
Продолжаем разбирать архитектуру сервера, баз данных. Следующий ее уровень - концептуальный. Он включает в себя обобщающее представление о хранилище информации. Будет описывать, какие именно сведения хранятся в базе данных, а также каковы связи, их объединяющие.
С точки зрения администратора, хранилище содержит в себе логическую структуру БД. Данный уровень архитектуры базы данных - это фактически полное представление требований информации со стороны компании, предприятия, которое не будет зависеть от любых соображений относительно способа, методики ее (информации) хранения.
Перечислим компоненты, представленных на концептуальном уровне архитектуры:
Концептуальный уровень призван поддерживать каждое из внешних представлений. Любая доступная пользователю информация из БД должна содержаться (или может быть вычислена) именно на данном уровне. Однако следует помнить, что информация о методах хранения данных в системе здесь не хранится.
И последняя ступень трехуровневой архитектуры базы данных. Тут находится физическое представление в компьютере БД. Что это значит? Уровень предназначен для описания физической реализации базы данных. Кроме того, с его помощью достигается оптимальная производительность, обеспечивается экономное использование дискового пространства компьютерной системы.
Содержит в себе описание структур данных, организации конкретных файлов, которые используются для реализации хранения информации на дисковых пространствах, запоминающих устройствах. Здесь, на внутреннем уровне, СУБД взаимодействует с методами, способами доступа операционных систем, вспомогательным функционалом хранения и извлечения записей сведений. Цель всего перечисленного: размещать информацию на запоминающих устройствах, извлекать данные, создавать индексы и проч.
Ниже данного будет находиться физический уровень. Его контролирует уже операционная система, однако все же под контролем СУБД.
Внутренний уровень базы данных хранит в себе следующую информацию:
Вы познакомились с распространенными типами, видами архитектур систем баз данных. Также мы представили уровни архитектуры СУБД - внешний, внутренний и концептуальный, их характеристики и элементы.
По своей архитектуре СУБД делятся на одно-, двух- и трехзвенные [ 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 и т.д. Клиент-серверные СУБД обеспечивают функционирование, или масштабируются, до сотен и тысяч клиентских мест.
Распределенные СУБД могут содержать несколько десятков и сотен серверов БД. Количество клиентских мест в них может достигать десятков и сотен тысяч. Обычно такие СУБД обеспечивают работу организаций государственного масштаба (например, Центральной избирательной комиссии РФ), отдельные подразделения которых рассредоточены на значительной территории. В распределенных СУБД некоторые серверы могут дублировать друг друга с целью достижения предельно малой вероятности отказов и сбоев, которые могут исказить жизненно важную информацию.
Актуальность распределенных СУБД возросла в связи со стремительным развитием Интернета. Опираясь на возможности Интернета, распределенные системы строят не только организации государственного масштаба, но и относительно небольшие коммерческие предприятия, обеспечивая своим сотрудникам работу с корпоративными данными на дому и в командировках.
Одним из важнейших аспектов развития СУБД является идея отделения логической структуры БД и манипуляций данными, необходимыми пользователям, от физического представления, требуемого компьютерным оборудованием.
Одна и та же БД в зависимости от точки зрения может иметь различные уровни описания. По числу уровней описания данных, поддерживаемых СУБД, различают одно-, двух- и трехуровневые системы. В настоящее время чаще всего поддерживается трехуровневая архитектура описания БД (рис. 2.1), с тремя уровнями абстракции, на которых можно рассматривать базу данных.
Такая архитектура включает:
· внешний уровень, на котором пользователи воспринимают данные, где отдельные группы пользователей имеют свое представление (ПП) на базу данных;
· внутренний уровень, на котором СУБД и операционная система воспринимают данные;
· концептуальный уровень представления данных, предназначенный для отображения внешнего уровня на внутренний уровень, а также для обеспечения необходимой их независимости друг от друга; он связан с обобщенным представлением пользователей.
Описание структуры данных на любом уровне называется схемой. Существует три различных типа схем базы данных, которые определяются в соответствии с уровнями абстракции трехуровневой архитектуры. На самом высоком уровне имеется несколько внешних схем или подсхем, которые соответствуют разным представлениям данных. На концептуальном уровне описание базы данных называют концептуальной схемой, а на самом низком уровне абстракции - внутренней схемой.
Основным назначением трехуровневой архитектуры является обеспечение независимости от данных. Суть этой независимости заключается в том, что изменения на нижних уровнях никак не влияют на верхние уровни. Различают два типа независимости от данных: логическую и физическую.
Логическая независимость от данных означает полную защищенность внешних схем от изменений, вносимых в концептуальную схему. Такие изменения концептуальной схемы, как добавление или удаление новых сущностей, атрибутов или связей, должны осуществляться 15 без необходимости внесения изменений в уже существующие внешние схемы для других групп пользователей.
Физическая независимость от данных означает защищенность концептуальной схемы от изменений, вносимых во внутреннюю схему. Такие изменения внутренней схемы, как использование различных файловых систем или структур хранения, разных устройств хранения, модификация индексов или хеширование, должны осуществляться без необходимости внесения изменений в концептуальную или внешнюю схемы.
Внешний уровень - это пользовательский уровень. Пользователем может быть программист, или конечный пользователь, или администратор базы данных. Представление базы данных с точки зрения пользователей называется внешним представлением. Каждая группа пользователей выделяет в моделируемой предметной области, общей для всей организации, те сущности, атрибуты и связи, которые ей интересны. Эти частичные или переопределенные описания БД для отдельных групп пользователей или ориентированные на отдельные аспекты предметной области называют подсхемой.
Концептуальный уровень является промежуточным уровнем в трехуровневой архитектуре и обеспечивает представление всей информации базы данных в абстрактной форме. Описание базы данных на этом уровне называется концептуальной схемой, которая является результатом концептуального проектирования.
Концептуальное проектирование базы данных включает анализ информационных потребностей пользователей и определение нужных им элементов данных. Таким образом, концептуальная схема - это единое логическое описание всех элементов данных и отношений между ними, логическая структура всей базы данных. Для каждой базы данных имеется только одна концептуальная схема.
Концептуальная схема должна содержать:
· сущности и их атрибуты;
· связи между сущностями;
· ограничения, накладываемые на данные;
· семантическую информацию о данных;
· обеспечение безопасности и поддержки целостности данных.
Внутренний уровень является третьим уровнем архитектуры БД. Внутреннее представление не связано с физическим уровнем, так как физический уровень хранения информации обладает значительной индивидуальностью для каждой системы.
На нижнем уровне находится внутренняя схема, которая является полным описанием внутренней модели данных. Для каждой базы данных существует только одна внутренняя схема.
Внутренняя схема описывает физическую реализацию базы данных и предназначена для достижения оптимальной производительности и обеспечения экономного использования дискового пространства. На внутреннем уровне хранится следующая информация:
· распределение дискового пространства для хранения данных и индексов;
· описание подробностей сохранения записей (с указанием реальных размеров сохраняемых элементов данных);
· сведения о размещении записей;
· сведения о сжатии данных и выбранных методах их шифрования.
СУБД отвечает за установление соответствия между всеми тремя типами схем разных уровней, а также за проверку их непротиворечивости.
Ниже внутреннего уровня находится физический уровень, который контролируется операционной системой, но под руководством СУБД. Физический уровень учитывает, каким образом данные будут представлены в машине. Он обеспечивает физический взгляд на базу данных: дисководы, физические адреса, индексы, указатели и т. д. За этот уровень отвечают проектировщики физической базы данных, которые работают только с известными операционной системе элементами. Область их интересов: указатели, реализация последовательного распределения, способы хранения полей внутренних записей на диске. Однако функции СУБД и операционной системы на физическом уровне не вполне четко разделены и могут варьироваться от системы к системе.
Функции СУБД
Рис. 1.3. Архитектура СУБД
Архитектура СУБД.
В современных системах БД выделяют 3 уровня представления данных: внешний, концептуальный и внутренний (рис. 1.3). Внешний уровень отражает представление пользователей на БД. Внутренний уровень отражает представление, на котором СУБД и ОС воспринимают данные. Концептуальный (логический) уровень – связан с обобщенным представлением всех пользователей БД (это взгляд администратора БД).
Этот подход является общепризнанным и существует уже более 30 лет. Первые предложения по многоуровневой архитектуре были выдвинуты рабочей группой CODACYL в 1971 г. В 1975 г. Комитет планирования стандартов и норм SPARC (Standarts Planning and Requirements Committee) Американского национального института стандартов FNSI (American National Stsndsrt Institute) предложил обобщенную 3-х уровневую структуру СУБД, которая была официально признана в 1978 г и получила название ANSI SPARC.
Первая попытка создания стандартной терминологии и общей архитектуры СУБД была предпринята в 1971 году группой DBTG, признавшей необходимость использования двухуровневого подхода, построенного на основе использования системного представления, т.е. схемы, и пользовательских представлений, т.е. подсхем. Сходные терминология и архитектура были предложены в 1975 году Комитетом планирования стандартов и норм SPARC. Комитет ANSI/SPARC признал необходимость использования трехуровневого подхода. Хотя модель ANSI/SPARC не стала стандартом, тем не менее она все еще представляет собой основу для понимания некоторых функциональных особенностей СУБД.
В данном случае наиболее важным моментом в этих и последующих разработках является идентификация трех уровней абстракции, т.е. трех различных уровней описания элементов данных. Эти уровни формируют трехуровневую архитектуру, которая охватывает внешний, концептуальный и внутренний уровни. Цель трехуровневой архитектуры заключается в отделении пользовательского представления базы данных от ее физического представления. Ниже перечислено несколько причин, по которым желательно выполнять такое разделение.
· Каждый пользователь должен иметь возможность обращаться к одним и тем же данным, используя свое собственное представление о них. Каждый пользователь должен иметь возможность изменять свое представление о данных, причем это изменение не должно оказывать влияния на других пользователей.
· Пользователи не должны непосредственно иметь дело с подробностями физического хранения данных в базе
· Администратор базы данных должен иметь возможность изменять структуру хранения данных в базе, не оказывая влияния на пользовательские представления.
· Внутренняя структура базы данных не должна зависеть от таких изменений физических аспектов хранения информации, как переход на новое устройство хранения.
· АБД должен иметь возможность изменять концептуальную или глобальную структуру базы данных без какого-либо влияния на всех пользователей.
Уровень, на котором воспринимают данные пользователи, называется внешним уровнем (external level), тогда как СУБД и операционная система воспринимают данные на внутреннем уровне (internal level). Именно на внутреннем уровне данные реально сохраняются с использованием всех тех структур и файловой организации. Концептуальный уровень (conceptual level) представления данных предназначен для отображения внешнего уровня на внутренний и обеспечения необходимой независимости друг от друга.
Основным назначением такой архитектуры является обеспечение независимости данных, суть которого заключается в том, что изменения на нижних уровнях архитектуры не влияют на верхние уровни.
Внешний уровень – это пользовательский уровень. Пользователем может быть программист, конечный пользователь или администратор БД. Представление с точки зрения пользователя называется внешним представлением. Оно отражает представление пользователя о данных в БД в удобной для него форме (например, для бухгалтерии - это данные о студентах, которым начисляется стипендия, при этом не важно, какие у них оценки. Для деканата данные о тех же студентах будут содержать сведения об их оценках в сессию и т.п.) . Эти частичные представления пользователей о БД называют подсхемой БД. При этом каждый пользователь может использовать свои языковые и программные средства для работы с БД.
Концептуальный уровень является промежуточным уровнем и обеспечивает представление всей БД в абстрактной форме. Описание БД на этом уровне называют концептуальной схемой, которая является результатом концептуального проектирования. Концептуальная схема отражает интересы всех пользователей и представляет собой единое логическое описание всех элементов данных и отношений между ними, образуя логическую структуру всей БД.
Концептуальная схема должна содержать:
· объекты и атрибуты предметной области;
· связи между объектами;
· ограничения, накладываемые на данные;
· семантическую информацию о данных;
· обеспечение безопасности данных;
· поддержку целостности данных.
Концептуальный уровень поддерживает каждое внешнее представление, в том смысле, что любые доступные пользователю данные должны содержаться (или могут быть вычислены) на этом уровне. Однако на этом уровне не содержаться сведения о методах хранения данных.
Внутренний уровень характеризует внутреннее представление. Оно не связано с физическим уровнем, т.к. физический уровень хранения информации обладает существенной индивидуальностью для каждой системы. На внутреннем уровне все эти особенности не учитываются, а вся область хранения представляется как бесконечное линейное адресное пространство. На нижнем уровне находится внутренняя схема, которая является полным описанием внутренней модели данных. Для каждой БД она только одна. Внутренняя схема описывает физическую реализацию и предназначена для достижения оптимальной производительности и обеспечения экономного использования дискового пространства. На внутреннем уровне хранится следующая информация:
· распределение дискового пространства для хранения данных и индексов;
· описание подробностей сохранения записей (типы, размеры элементов данных и др.);
· сведение о размещении записей;
· сведения о сжатии записей и выбранных методах шифрования.
СУБД отвечает за установление соответствия между всеми тремя уровнями и поддержку их непротиворечивости.
СУБД является сложным программным продуктом и должна обеспечивать выполнение всех определенных ранее функций. Следует отметить, что некоторые функции могут выполняться ОС. Поэтому при проектировании СУБД следует учитывать особенности интерфейса СУБД с ОС.
В структуре СУБД выделяют ядро СУБД (рис. 1.4), которое включает транслятор с языка БД (ЯОД И ЯМД), подсистему поддержки времени выполнения (управление данными во внешней памяти, управление собственными буферами оперативной памяти, управление журнализацией), подсистему управления транзакциями. Кроме того в состав СУБД входит набор утилит, который существенно зависит от выбранной СУБД. В некоторых СУБД эти части явно не выделены, но логически присутствуют всегда.
Ядро СУБД отвечает за управление данными во внешней памяти, управление буферами ОП, управление транзакциями и ведение журналов. Каждая функция реализуется в виде соответствующего менеджера (менеджер транзакций, менеджер буферов и т.д.). Эти функции взаимосвязаны и должны работать под управлением четко проверенных протоколов. Ядро СУБД обладает собственным интерфейсом, недоступным пользователю напрямую и является резидентной частью СУБД. При использовании архитектуры «клиент-сервер» оно является основной составляющей серверной части. Поэтому программа, обеспечивающая выполнение функций СУБД называется машина БД.
В структуре программного комплекса СУБД можно выделить:
Процессор запросов – преобразует запросы в последовательность низкоуровневых инструкций для контроллера БД.
Транслятор с ЯОД – преобразует его команды в набор таблиц, содержащих метаданные. Эта информация хранится в системном каталоге, а управляющая информация – в заголовке файлов.
Транслятор с ЯМД – преобразует внедренные в прикладные программы операторы в вызовы стандартных функций базового языка. Взаимодействует с процессором запросов.
