Глава 2. Архитектура банка данных
2.1. Уровни представления баз данных
2.1.1. Основная терминология
СУБД подразделяют:
- по типу поддерживаемых моделей: на сетевые, иерархические, реляционные, объектно-ориентированные, объектно-реляционные [3, 5, 16];
- по типу взаимодействия с обрабатывающей программой: автономные и с включающим языком программирования;
- по уровню централизации обработки информации: централизованные, децентрализованные, равноправные и смешанные.
B настоящее время принята четырехуровневая архитектура СУБД, использующая четыре уровня восприятия и отображения информации предметной области в моделях баз данных:
- инфологический уровень;
- концептуальный уровень;
- внешний уровень;
- внутренний уровень.
На каждом уровне присутствует модель данных, которая специфицируется с помощью языка описания соответствующего уровня. Модель каждого уровня, представленную на языке описания, принято называть СХЕМОЙ. Перевод моделей (описаний моделей) из одного уровня в другой осуществляется с помощью трансляции или интерпретации.
B зависимости от вида представления информации различают следующие типы схем:
- инфологическая схема, дающая общее информационно-логическое представление об информации предметной области;
- концептуальная схема, описывающая информацию о предметной области в терминах конкретной СУБД;
- внешняя схема, дающая представление информации о предметной области для прикладных программ и пользователей системы. С помощью концептуальной и внешней схемы СУБД дает возможность программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных. Нужные данные отыскиваются СУБД на внешних запоминающих устройствах по описанию внутренней схемы;
- внутренняя схема, характеризующая физический уровень представления информации в конкретной СУБД. Как и в любой другой схеме, ей соответствует своя модель, которая должна быть описана на языке описания данных этой СУБД.
Отметим, что жизнеспособность промышленных СУБД определяется, прежде всего, концептуальным уровнем, так как именно концептуальный уровень связывает между собой внутренний и внешний уровни и обеспечивает их независимость, т.е. изменение модели внутреннего уровня (например, вследствие необходимости увеличения скорости ответа на какой-либо запрос к системе) не приводит к переделке других прикладных программ, использующих этот же информационный фонд.
Проблема независимости данных является центральной, так как возможность ее решения во многом определяет устойчивость разработанного проекта к изменениям, происходящим в предметной области. Методы и способы, обеспечивающие принцип независимости данных, должны учитывать многие факторы, возникающие на всех этапах проектирования моделей баз данных.
Например, задачи, решаемые как на этапе инфологического отображения предметной области, так и задачи сетевого (или многозадачного) варианта функционирования системы (в том числе и задачи связанные с клиентской и серверной обработкой данных), так или иначе, связаны с проблемой независимости данных. Обеспечение независимости хранимых данных от использующих их программ позволяет при необходимости переписать хранимые данные на другие носители информации и (или) реорганизовать их физическую структуру, изменив лишь физическую модель данных. К системе можно подключить любое число новых пользователей (новых приложений), изменив, если надо, концептуальную модель. Указанные изменения должны быть "прозрачными" для существующих пользователей системы и их приложений. Теоретически, независимость данных призвана обеспечивать возможность развития системы баз данных без разрушения существующих приложений.
Следует отметить, что недопонимание необходимости и важности инфологического этапа проектирования базы данных, приводит к серьезным проблемам при эксплуатации информационной системы. На инфологическом этапе происходит объединение частных представлений о содержимом базы данных, получаемых в результате опроса пользователей, и представлений о данных, которые могут потребоваться в будущих приложениях. Таким образом, создается обобщенное неформальное описание фрагмента предметной области для разрабатываемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и диаграмм, и называют инфологической моделью данных.
Инфологическая модель независима от физических параметров среды хранения данных, но важно уяснить, что, в конце концов, она должна быть основой для построения концептуальной модели данных, которая, также как и внешняя и внутренняя, является машинно-ориентированной. Поэтому инфологическая модель не должна изменяться до тех пор, пока какие-то правила в реальном мире не изменятся. И самое главное, когда такое изменение произойдет (а это неизбежно), то необходимо внести в нее соответствующие изменения, чтобы она продолжала адекватно отражать предметную область.
Любое понятие предметной области, зафиксированное в инфологической модели, в принципе, должно быть отображено с помощью средств концептуального уровня той СУБД, в которой реализуется проект информационной системы. Например, для реляционных СУБД одним из таких средств концептуального уровня является математическое понятие отношения.
Современные авторы часто употребляют термины "банк данных" и "база данных" как синонимы, однако в общеотраслевых руководящих материалах по созданию банков данных Государственного комитета по науке и технике (ГКНТ), изданных в 1982 г., эти понятия различаются. Там приводятся следующие определения банка данных, базы данных и СУБД:
Банк данных (БнД) — это система специальным образом организованных данных — баз данных, программных, технических, языковых, организационно-методических средств, предназначенных для обеспечения централизованного накопления и коллективного многоцелевого использования данных.
База данных (БД) — именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области.
Система управления базами данных (СУБД) — совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями.
Модель данных - это средство абстракции, которое интерпретирует информационное содержание данных предметной области, частично представляя семантику данных предметной области, т.е. средство, передающее некоторые знания о реальном мире (предметной области)
Модель данных характеризуется тремя компонентами:
-
Структура данных, предназначенная для представления точки зрения пользователя на БД.
-
Множество допустимых операций, выполняемых в структуре данных, составляющее основу языка данных модели.
-
Ограничения для контроля целостности.
Программы, с помощью которых пользователи работают с БД, называются приложениями. В общем случае с одной БД могут работать множество различных приложений. Например, если БД моделирует некоторое предприятие, то для работы с ней может быть создано приложение, которое обслуживает подсистему учета кадров, другое приложение может быть посвящено работе подсистемы расчета заработной платы сотрудников, третье приложение работает как подсистемы складского учета и т.д. При рассмотрении приложений, работающих с одной БД, предполагается, что они могут работать параллельно и независимо друг от друга, и именно СУБД призвана обеспечить работу множества приложений с единой базой данных таким образом, чтобы каждое из них выполнялось корректно, но учитывало все изменения в БД, вносимые другими приложениями.
В следующей теме на структурном и функциональном уровне раскрывается поняние архитектуры базы данных, как комплекса взаимосвязанных моделей различных уровней представления информации в банках данных.
2.1.2. Архитектура базы данных
Стандарт ANSI/SPARC
Используемые в промышленности СУБД имеют много различий, но практически все они опираются на концепцию архитектуры ANSI/SPARC - американского института стандартов по проектированию баз данных. Согласно предложениям ANSI/SPARC, к анализу (исследованию) разнотипных БД можно подходить с единых позиций, если придерживаться следующей архитектуры банка данных (рис. 2.1).
Рис. 2.1. Архитектура банка данных
Описание архитектуры
Представленная на рис. 2.1 архитектура банка данных является обобщенной, т.е. с ее помощью можно с единых позиций рассмотреть как общие принципы проектирования баз данных, так и выявить особенности структур конкретных систем. Важной особенностью предложенной архитектуры является то, что она согласуется со стандартом ANSI / SPARC.
Архитектура представлена тремя уровнями: внутренним, концептуальным и внешним.
Внутренний уровень наиболее близок к физическим структурам хранимой информации. Именно внутренний уровень учитывает методы доступа операционной системы для манипулирования данными на физическом уровне, что в некоторой степени снижает независимость операций обработки данных от технических средств.
Внешний уровень является уровнем пользователей СУБД, так как он является уровнем восприятия каждого пользователя. В принципе для каждого пользователя может существовать свой внешний уровень. Типичным воплощением внешнего уровня является использование представлений (VIEW) в языке SQL (см. пункт 6.2, книга 2).
Концептуальный уровень является обобщением локальных представлений пользователей, т.е. является общим глобальным описанием предметной области в терминах (концептах) конкретной СУБД. Важно отметить, что концептуальный уровень исполняет роль некоторого стандарта пользователей, согласуя их представление о предметной области в единое целое.
Банк данных создается для удовлетворения информационных потребностей пользователя.
Пользователи подразделяются на прикладных программистов и пользователей непрофессионалов. Для каждого пользователя используется свой язык общения с базой данных.
Для прикладного программиста это обычный язык программирования, например: Паскаль, Си, PL/1. Для пользователя непрофессионала – это специальный язык, разработанный с учетом его потребностей, т.е. это может быть какое-то меню, реализованное с помощью языка типа SQL (Structured Query Language – структурированный язык запросов) или QBE (Query-By-Example – запросы на основе примеров) и т.п.
Но для взаимодействия с СУБД важно понимать, что связь с базой осуществляется с помощью специального языка - языка манипулирования данными (ЯМД). Пользователь - программист использует ЯМД как обычные подпрограммы, а пользователь непрофессионал, как некоторую совокупность правил взаимодействия с базой.
Передача информации между базой данных (БД) и пользователями осуществляется через рабочую область (см. рис. 2.1). Для пользователей программистов такой рабочей областью является область ввода-вывода, для непрофессионала эта область состоит из рабочей памяти выделенной терминалу. Поскольку отдельного пользователя, как правило, интересует только некоторая часть всей базы данных, то он взаимодействует с банком данных на уровне внешней модели (которая может не являться точной копией хранимой (физической) базы). Таким образом, внешняя модель является информационным содержанием базы данных в том виде, в каком его представляет конкретный пользователь (т.е. для этого пользователя внешняя модель есть собственно база данных, например: база данных отдела кадров).
ВНЕШНЯЯ МОДЕЛЬ состоит из различных экземпляров различных типов внешних записей (логических), причем такие записи могут не совпадать с хранимыми записями. Пользователь через рабочую область оперирует с базой данных на уровне внешних записей, например, по оператору SELECT (см. книгу 2) языка манипулирования данными будет происходить выборка внешней записи, а не экземпляра хранимой записи. Каждая внешняя модель задается (описывается) посредством внешней схемы, которая в основном состоит из описаний всех типов внешних записей этой внешней модели, например: запись о студенте. Помимо этого описания, должно быть определено отображение, связывающее внешнюю схему с концептуальной схемой.
Концептуальный уровень (и соответствующая этому уровню концептуальная модель или просто модель) есть уровень глобального информационного содержания базы данных в достаточно абстрактной форме по сравнению со способом физического хранения данных. Концептуальная модель состоит из множества экземпляров различных типов концептуальных записей, разрешенных к использованию в конкретной СУБД. Этот уровень наиболее близок к инфологическому уровню, поэтому обычно экземпляр записи концептуальной модели представляет собой объект или связь между объектами инфологического уровня.
Концептуальная запись может не соответствовать внешней или хранимой записи. Концептуальная модель определяется посредством концептуальной схемы, которая включает определения каждого типа концептуальных записей. Для достижения независимости данных эти определения не должны учитывать структуру хранения или стратегию доступа, они должны быть определениями только информационного содержания, т.е. они не должны содержать какие-либо особенности физического отображения (хеш адресацию, индексирование и т.д. (см. главу 4).
Если концептуальная схема действительно обеспечивает независимость данных, то внешние схемы, которые определены в терминах концептуальной схемы, будут также независимы от данных.
В настоящее время нет систем, которые бы полностью соответствовали принципам концептуальной модели и поддерживали бы все требования концепции независимости данных. Концептуальное проектирование модели базы данных включает анализ информационных потребностей пользователей и определение нужных им элементов данных. Результатом концептуального проектирования является концептуальная схема, единое логическое описание всех элементов данных и отношений между ними (см. рис. 1.3). Именно в этой схеме указываются необходимые ограничения, присущие, как каждому элементу данных, так и отношениям (таблицам) присутствующим в схеме.
Низшим уровнем архитектуры банка данных является внутренний уровень или уровень ХРАНИМЫХ записей. Внутренняя модель описывается посредством ВНУТРЕННЕЙ СХЕМЫ, которая не только определяет различные типы хранимых записей, но и указывает, каким образом эти хранимые записи организованы (последовательно, с использованием хеш-функций, B-деревьев и т.п.), какие добавочные индексы используются, какие используются методы кодирования и т.п.
Основная функция СУБД – организация обмена информацией между пользователями и базами данных с соответствующими процедурами контроля полномочий и проверки целостности данных, хранимых в базах данных. Среди пользователей СУБД выделяется лицо (или группа лиц), на которое обычно возлагаются следующие функции:
- определение информационного содержания базы данных (идентификация объектов и связей, представляющих интерес для данного предприятия и конкретного пользователя, создание на этой основе концептуальной схемы с помощью специального языка);
- определение структуры хранения и стратегии доступа;
- взаимодействие с пользователем (подготовка и написание внешних схем);
- определение стратегии дублирования и восстановления;
- управление эффективностью ответа на запросы пользователей;
- создание словаря данных.
Такое лицо получает статус администратора базы данных (АБД).
Для обычного пользователя перечисленные выше функции либо недоступны, либо они ему не нужны. В этом проявляется еще один аспект независимости данных. СУБД должна предоставлять доступ к данным, не требуя от пользователя знаний о таких тонкостях как:
-
физическое размещение в памяти данных и их описаний;
-
управление данными во внешней памяти и управление буферами оперативной памяти;
-
механизмы поиска запрашиваемых данных;
-
проблемы, возникающие при одновременном запросе одних и тех же данных многими пользователями (как для прикладных, так и системных программ);
-
способы обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа и множество других функций СУБД, таких, например, как управление транзакциями или ведение журнала событий и восстановления баз данных после всевозможных сбоев.
Языковые средства взаимодействия с СУБД
На взаимодействие с СУБД существенное влияние оказывают языковые факторы, как самой СУБД, так и операционной системы, в среде которой работает СУБД.
Кроме языка описания данных (ЯОД) для описания концептуальной схемы необходимы следующие языки: языки определения данных внешних схем, включающие языки, язык управления внешней памятью, язык манипулирования данными (ЯМД) и язык управления заданиями (или другой язык ОС).
Разработчик прикладной программы описывает процесс обработки данных на каком-либо из процедурных языков программирования, выбор которого определяется наличием соответствующего транслятора или интерпретатора, удобством описания обработки и т.д.
Если СУБД располагает средством связи программы, написанной на каком-либо языке, с БД, то такой язык называется включающим (Кобол, С, Паскаль, Clipper и т.п.). Языковыми средствами связи с БД являются языки описания внешних схем и ЯМД.
Язык управления заданиями является средством связи пользователя с ОС. На этом языке пользователь излагает сведения, которые необходимы ОС для принятия его задания к выполнению, организации процесса выполнения, выдачи результатов и т.д. Язык управления заданием является составной частью ОС.
Задача пользователя является объектом обслуживания, как для ОС, так и для СУБД. OC выделяет для задачи область памяти, которая в свою очередь разбивается на рабочие области. СУБД осуществляет передачу данных из рабочей области в БД и наоборот.
Язык управления внешней памятью (ЯУП обычно включается как составная часть ЯОД), предназначен для определения взаимно-однозначного соответствия между страницами концептуальной схемы и физическими элементами хранения страниц. Администратор данных с помощью ЯУП ставит в соответствие страницам схемы соответствующие страницы наборов данных (например, дискового пространства). С наборами данных (файлами) работает ОС, различая их по именам. Администратор назначает машинные носители для наборов данных, пользуясь языком управления заданиями (ЯУЗ) или любым другим языком операционной системы (ОС), позволяющим связать имя набора с реальным физическим файлом, хранящимся на физическом носителе.
Чтобы упростить процесс взаимодействия пользователя с хранимой информацией, все указанные языки сгруппированы в оболочке СУБД (где они носят название языков описания схем и манипулирования данными), которая через свои визуальные средства позволяет делать их практически невидимыми для пользователя.
Укрупненно процесс взаимодействия СУБД и прикладной программы состоит из следующих шагов:
1. Прикладная программа обращается к СУБД с запросом на чтение описания внешней модели данных (ВМД).
2. СУБД определяет, из каких записей состоит ВМД и на основе концептуальной модели данных выбирает в рабочую область необходимые записи из хранимой базы.
3. ОС с помощью своих методов доступа считывает информацию в буферы СУБД.
4. На основе описания ВМД и соответствующих отображений формируется запись для данной программы пользователя.
5. Сформированная запись из буфера СУБД пересылается в рабочую область прикладной программы и обрабатывается прикладной программой.
При выполнении основных из вышеуказанных функций СУБД должна использовать различные описания данных [17, 25], которые чаще всего зафиксированы в так называемом словаре данных.
Как отмечалось, инфологическая модель отображает фрагмент предметной области (часть реального мира) в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель "сущность-связь" и т.д. [4]. Наиболее распространенной из них оказалась модель "сущность-связь", которая рассмотрена в [31]. Распространенность этого подхода объясняется тем, что он изначально ориентировался на СУБД, концептуальная модель которых совпадала с реляционной моделью данных.
В процессе научных исследований, посвященных тому, как именно должна быть устроена СУБД, предлагались различные способы реализации. Самым жизнеспособным из них оказалась предложенная американским комитетом по стандартизации ANSI (American National Standards Institute) трехуровневая система организации БнД, изображенная на рис. 2.2.
Уровень внешних моделей — самый верхний уровень, где каждая модель имеет свое "видение" данных. Этот уровень определяет точку зрения на БД отдельных приложений. Каждое приложение видит и обрабатывает только те данные, которые необходимы именно этому приложению. Например, подсистема составления расписания занятий использует сведения о квалификации сотрудника и видов работ по конкретной дисциплине, но ее не интересуют сведения об окладе, домашнем адресе и телефоне сотрудника, и наоборот, именно эти сведения используются в подсистеме отдела кадров.
Рис. 2.2. Трехуровневая модель СУБД, предложенная ANSI\SPARC
Концептуальный уровень — центральное управляющее звено, здесь база данных представлена в наиболее общем виде, который объединяет данные, используемые всеми приложениями, работающими с данной базой данных. Фактически концептуальный уровень отражает обобщенную модель предметной области (объектов реального мира), для которой создавалась база данных. Как любая модель, концептуальная модель отражает только существенные, с точки зрения обработки, особенности объектов реального мира. В источниках по базам данных понятия схемы и подсхемы связываются с концептуальным и внешним уровнем соответственно.
Физический уровень — собственно данные, расположенные в файлах или в страничных структурах, расположенных на внешних носителях информации.
Эта архитектура позволяет обеспечить логическую (между уровнями 1 и 2) и физическую (между уровнями 2 и 3) независимость при работе с данными. Логическая независимость предполагает возможность изменения одного приложения без корректировки других приложений, работающих с этой же базой данных. Физическая независимость предполагает возможность переноса хранимой информации с одних носителей на другие при сохранении работоспособности всех приложений, работающих с данной базой данных. Реализация принципа независимости данных является центральным в теории и практике баз данных. Это именно то, чего не хватало при использовании файловых систем.
Выделение концептуального уровня позволило разработать аппарат централизованного управления базой данных.
На каждом уровне присутствует модель данных, которая специфицируется с помощью языка описания соответствующего уровня. Модель каждого уровня, представленную на языке описания, принято называть схемой. Внешнею модель иногда называют подсхемой.
Каждому уровню представления данных соответствует своя одноименная модель данных.
2.1.3. Процесс прохождения пользовательского запроса в СУБД
Рис. 2.3 иллюстрирует взаимодействие пользователя, СУБД и ОС при обработке запроса на получение данных. Под рабочей областью здесь понимается область оперативной памяти ЭВМ, доступная для пользовательского приложения.
Цифрами помечена последовательность взаимодействий.
Пользователь посылает СУБД запрос на получение данных из БД (стрелка 1).
Анализ прав пользователя и внешней модели данных, соответствующей данному пользователю, подтверждает или запрещает доступ данного пользователя к запрошенным данным.
В случае запрета на доступ к данным СУБД сообщает пользователю об этом (стрелка 12) и прекращает дальнейший процесс обработки данных, в противном случае СУБД определяет часть концептуальной модели, которая затрагивается запросом пользователя.
Рис. 2.3. Схема прохождения запроса к БД
СУБД запрашивают информацию о части концептуальной модели.
СУБД получает информацию о запрошенной части концептуальной модели.
СУБД запрашивает информацию о местоположении данных на физическом уровне (с учетом физической организации файлов базы данных).
В СУБД возвращается информация о местоположении данных в терминах операционной системы.
СУБД просит операционную систему предоставить необходимые данные, используя средства операционной системы.
ОС осуществляет перекачку информации из устройств хранения и пересылает ее в системный буфер.
ОС оповещает СУБД об окончании пересылки.
СУБД выбирает из доставленной информации, находящейся в системном буфере, только то, что нужно пользователю, и пересылает эти данные в рабочую область пользователя.
Любая ИС включает базу Метаданных (словарь данных – системные файлы СУБД), именно здесь и хранится вся информация об используемых структурах данных, логической организации данных, правах доступа пользователей и, наконец, физическом расположении данных. Для управления базой Метаданных каждый производитель СУБД предоставляет специальное программное обеспечение администрирования баз данных, которое предназначено для корректного использования единого информационного пространства многими пользователями.
Всегда ли запрос проходит полный цикл? Конечно, нет. СУБД обладает достаточно развитым интеллектом, который позволяет ей не повторять бессмысленных действий. И поэтому, например, если этот же пользователь повторно обратится к СУБД с новым запросом, то для него уже не будут проверяться внешняя модель и права доступа, а если дальнейший анализ запроса покажет, что данные могут находиться в системном буфере, то СУБД осуществит только 11 и 12 шаги в обработке запроса.
Механизм прохождения запроса в реальных СУБД гораздо сложнее, но и эта упрощенная схема показывает, насколько серьезными и сложными должны быть механизмы обработки запросов, поддерживаемые реальными СУБД.
|
