Игровой сервер

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

Хью Робинсон

Контекст:
В этом фрагменте, одном из двух взятых из статьи этого автора, даны основы технологии баз данных, обсуждаются модели - или архитектуры - структур баз данных.

Источник:
Robinson, Hugh. "Database Architectures." In Relational database systems, Introduction to database technology. Milton Keynes: Open University, pp. 20-31.

Копирайт:
Воспроизведено с разрешения.

2.3 Архитектуры

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

2.3.1 Архитектура схемы

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

Прежде всего, заметьте, что различные сплошные линии на рис. 2.10 показывают, что определенные компоненты в данной архитектуре связаны друг с другом способом, который будет вкратце рассмотрен далее. В частности, обратите внимание, что эти линии не предназначены для того, чтобы указывать поток обработки данных. Как можно видеть, наше упрощение одной схемы заменено тремя видами схем: логической схемой, схемой хранения и схемой пользователей (userschema). Позже мы объясним, чем вызвана эта замена. В верхнюю часть диаграммы мы также включили различные пользовательские процессы. Термин "пользовательский процесс" (user process) вводится для того, чтобы разрешить доступ к системе базы данных с помощью любого вида программного обеспечения от имени пользователя. А теперь мы более подробно исследуем эти концепции.

  • Логическая схема (logical schema) - это одиночное, центральное описание логических свойств данных в конкретной базе данных. Логическая схема больше описывает какими являются данные, чем то, как их можно хранить и как получить к ним доступ. Для любой данной системы баз данных имеется одна логическая схема. Она является описанием свойств типов данных, которые затем определяют свойства экземпляров данных в базе данных. Она описывается формальным языком, который может быть обработан компьютером. Этот язык иногда называют языком описания данных логической схемы (logical schema data definition language или logical schema DDL).

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

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

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

    На рис. 2.11 дан пример реляционной схемы пользователей с показом некоторых экземпляров данных.

    Студенты и консультанты (StudentsWithCounsellors)
    Идентификационный номер студента (StudentId)Имя (Name)Время регистрации (Registered)Имя консультанта (CounsellorName)Регион (Region)
    s01Akeroyd1988Jennings3
    s02Thompson1993Heathcote4
    s05Ellis1992Heathcote4
    s07Gillies1991Jennings3
    s09Reeves1993Heathcote4
    s10Urbach1992Heathcote4

    Рисунок 2.11 Реляционная схема пользователей

    Схема пользователей, которая состоит только из одной таблицы с названием Студенты и консультанты (StudentsWithCounsellors), удовлетворяет нужды (гипотетической) группы пользователей, которым необходимы данные о студентах, но которых больше интересует имя консультанта студента, а не его кадровый номер. Поэтому таблицу (схему пользователей) Студенты и консультанты (StudentsWithCounsellors) выводят из двух базовых таблиц (схем) Студент (Student) и Персонал (Staff). Поскольку Студенты и консультанты (StudentsWithCounsellors) - это таблица, ее выведение из таблиц Студент (Student) и Персонал (Staff) - составление схемы распределения - можно описывать в терминах утверждений (операторов) в реляционном DML (языке управления данными)13. DBMS не будет хранить данные, определенные в такой таблице, как Студенты и консультанты (StudentsWithCounsellors), а выведет требуемые данные путем составления схемы распределения14.

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

  • Схема хранения - это определение того, как хранить и получать доступ к данным, определенным в логической схеме. Определение происходит с помощью языка, который иногда называют языком описания данных схемы хранения (storage schema data definition language (или storage schema DDL). Для наших целей существует одна схема хранения для данной системы базы данных, точно так же как существует одна логическая схема. Подробное рассмотрение структур, определенных в схеме хранения, не входит в задачи данного курса15, но вы должны представлять себе хранение файлов, структуры файлов и методы доступа. Данные в каждой таблице, описанные в логической схеме, необходимо как-то физически хранить. Это осуществляется путем размещения данных каждой таблицы в запоминающем файле (stored file), который управляется операционной системой компьютера. Каждый хранимый файл хранится в соответствии со структурой (организацией) файла (file organization) (упорядоченной, индексной или хэшированной), поддерживающей метод доступа (access method), с помощью которого хранимые записи (stored records), составляющие данных файл, могут быть сохранены и извлечены. Таким образом, схема хранения применяет методы из технологии массовой памяти (запоминающего устройства большой емкости), используемой в вычислительных системах.

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

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

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

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

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

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

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

Вопрос 2.6

  1. a. К скольким схемам пользователей может обращаться пользовательский процесс?
  2. b. Сколько пользовательских процессов может обращаться к одной схеме пользователей?

Ответ

  • Пользовательский процесс обращается только к одной схеме пользователей.
  • Много пользовательских процессов может обращаться к одной и той же схеме пользователей.

Вопрос 2.7 Какой компонент играет основную роль в архитектуре схемы?

Ответ Логическая схема. Как схему пользователей, так и схему хранения получают из логической схемы.

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

Совместное использование данных приложениями. Компонент архитектуры схемы пользователей обеспечивает каждое приложение представлением соответствующих данных, в то время как ассоциированная схема распределения между схемой пользователей и логической схемой определяет как это представление постоянных данных, ориентированное на приложение, связано с данными, описанными логической схемой. Более того, может быть введена управляемая избыточность. На реляционной схеме пользователей, приведенной на рис. 2.11, повторяется имя консультанта (в виде значения Имя консультанта (CounsellorName)) для каждого студента этого консультанта. Однако, эта избыточность контролируется в том смысле, что каждое повторение значения Имя консультанта является повтором значения Имя (Name), которое хранится только один раз в основной таблице Персонал(Staff) (логической схемы), как это показано на рис. 2.8. При условии, что на любое изменение имени консультанта оказывает влияние изменение значения Имя (Name) в основной таблице Персонал (Staff), схема распределения гарантирует, что это изменение будет передано всем копиям.

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

Возможность реагировать на изменения. Теперь оценим, как можно минимизировать влияние изменений пользовательского процесса на структуру данных. В разделе 2.1.2 мы описали состояние дел при файловом подходе, когда изменение в структуре данных требует изменения в программном коде приложения. Эта ситуация известна под названием зависимость от данных(data dependence), когда сведения о полной логической структуре данных, их физического хранения и доступа к ним встраиваются в логику или код программ-приложений. И наоборот, архитектура схемы показывает, что DBMS может обеспечить независимость данных (data independence) двумя путями: физическую независимость данных и логическую независимость данных.

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

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

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

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

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

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

2.3.2 Архитектура обработки

Перед тем, как описывать архитектуру обработки (данных), необходимо ввести понятие системы контроля базами данных (database control system) (или DBCS). Система управления базами данных является частью DBMS (DBMS), которая предоставляет и контролирует доступ к базе данных. Многие функции, которые мы привели в разделе 2.2.1 обеспечиваются дополнительными компонентами DBMS, которая в свою очередь использует DBCS. DBCS получает все запросы о доступе или манипулирует данными в базе данных. Более детальную оценку природы и роли DBCS можно получить из рассмотрения архитектуры обработки.

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

Первый этап охватывает определение базы данных, исходя из требований к данным, что показано на рис. 2.12. Этот этап начинается со спецификации (на соответствующем языке DDL) различных схем и соответствующих схем распределения. Определения схемы, то есть исходная схема, затем должна быть обработана модулем DBMS, который создает хранимую форму схемы. Модуль обеспечивает функцию определения данных DBMS и его называют процессором схемы (schema processor). Процессор схемы контролирует синтаксис и непротиворечивость определений и, если они являются приемлемыми, создает кодированную форму, которая называется объектной схемой (object schema). Объектная схема необходима для постоянного использования, так что процессор схемы использует DBCS для хранения этой формы схемы. Схема объекта, которая хранится, состоит из схемы пользователей, логической схемы, схемы хранения и соответствующих схем распределения.

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

Вообще, может быть любое количество прикладных программ, которые могут иметь доступ к частной базе данных, каждая для конкретной цели. Нас не интересуют подробности написания этих программ; достаточно знать, что встроенными внутрь каждой программы являются запросы на доступ к некоторой части базы данных, определенных схемой пользователей. Эти запросы выражены с помощью языка манипулирования данными (DML), и если он применяется с целью обработки модели, то его называют встроенным языком (embedded language). Операторы DML встраиваются в операторы, написанные на языке программирования, используемого для данной прикладной программы. Говорят, что язык программирования выполняет роль ведущего узла (host) относительно DML. Когда выполняется оператор встроенного языка прикладной программы, то DBCS запускается на выполнение необходимого доступа к базе данных. Для наших целей мы можем отметить три фактора, касающиеся этого метода обработки. Первый: пользователь прикладной программы не выдает запросы DBCS. Пользователь только предоставляет данные, до некоторой степени удовлетворяющие нужды пользователя, а запросы к DBCS выдает прикладная программа, исходя из данных, введенных пользователем. Второй: пользователь не получает данные непосредственно от DBCS. Скорее пользователь получает данные, в некоторой степени, удовлетворяющие его нужды, от прикладной программы (которая, конечно же, получает их от DBCS). Третий фактор: каждая прикладная программа создается для конкретной цели.

Альтернативным способом получения доступа к базе данных, как показано на рис. 2.13, является использование языка запросов (query language). Несмотря на подтекст в названии, языки запросов можно использовать для поиска или обновления базы данных. Пользователи могут использовать язык запросов через процессор запросов (query processor)16 - программы, которая взаимодействует с пользователями, чтобы обработать их операторы запросов, запрашивающих доступ к базе данных. Операторы запросов выражены в терминах DML и выдаются непосредственно пользователем. Пользователь языка запросов может направить любой оператор запроса процессору запросов и оператор будет выполнен вызванной DBCS, чтобы дать требуемый доступ к базе данных с ответом, который вернется прямо к пользователю. Процессор запросов пишется для использования с конкретной DBMS, но он является универсальной программой, которую можно использовать для доступа к определенной базе данных, используя DDL для этой DBMS (в отличие от прикладной программы, которая написана для доступа к конкретной базе данных с помощью заданного метода).

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

Упражнение 2.2

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

Упражнение 2.3

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

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

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

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

2.3.3 Архитектура для хранения

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

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

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

НФПК © 2004