II. Архитектура системы баз данных
Современная архитектура системы БД характеризуется многоуровневым представлением предметной области.
Предметная область– часть реального мира, которая описывается или моделируется с помощью баз данных и использующих их приложений. Это может быть целиком предприятие, некоторая его функциональная часть, процесс, система.
Предметная область– часть информационного пространства, отображающая потребности некоторого ограниченного круга пользователей базы данных.
Предметная область – это обобщающее понятие по отношению к экономическим объектам разного уровня, оно охватывает также и любые крупномасштабные объекты в науке и технике.
В качестве предметной области могут рассматриваться:
Библиографическая информация, архив в библиотеке;
В БД института могут быть сведения о студентах, преподавателях и учебных планах;
В БД предприятия содержится информация о выпускаемых изделиях, используемых деталях, поставщиках.
Архитектура СУБД разделена на три основных уровня: внутренний, концептуальный, внешний.
Внешний уровеньпредставляет некоторую часть предметной области в той форме, как она воспринимается приложением или группой приложений.
Концептуальный уровеньпредставляет соответственно предметную область. Подробность представления предметной области на концептуальном уровне зависит от специфики конкретной разработки.
Внутренний уровеньвключает данные о предметной области с учетом требований хранения и доступа.
Выделенным уровням соответствуют модели данных и описывающие эти модели схемы.
Модели данных– это определенным образом структурированные данные.
Схема является описанием модели, предназначенным для использования СУБД.
Все уровни являются реальными, то есть отражают определенные взгляды на данные соответственно с позиции приложений, предметной области и вычислительной машины.
Введение концептуального уровня обеспечивает важные свойства систем БД:
Независимость данных;
Целостность;
Разграничение доступа.
Все изменения затрагивают соответствующие отображения и не касаются соответствующих приложений.
Внешняя модельявляется совокупностью объектов, которые представляют часть предметной области, входящую в круг интересов некоторого приложения или группы приложений, со степенью подробности и в форме, необходимой для этих приложений. Каждому приложению может соответствовать определенная внешняя модель. Различные внешние модели пересекаются. Объекты внешней модели материализуются по требованию приложений и прекращают существовать после их использования.
Концептуальная модель– это совокупность объектов, представляющих предметную область. В то время как возможно использование множества внешних моделей, существует лишь одна концептуальная модель. Любые данные могут быть использованы, только если они отражены в концептуальной модели. Объекты концептуальной модели не обязательно должны быть материализованы. Она – есть представление полного информационного содержания БД в абстрактной форме в целом по сравнению со способом хранения данных.
Внутренняя модельпредставляет собой совокупность объектов, содержащих хранимые данные. Во внутренней модели отражены используемые СУБД технологии хранения и пути доступа к данным. В отличие от предыдущих двух моделей, объекты во внутренней модели фактически существуют и продолжают существовать до тех пор, пока не будут удалены из системы.
Вывод:для каждой базы данных составляются одна внутренняя схема, описывающая внутреннюю модель, одна логическая, описывающая концептуальную модель и некоторое число внешних схем для описания различных внешних моделей.
Соотношение моделей:
Внешняя модель БД совместима с концептуальной моделью и выводится из нее. Внешние модели могут также выводиться из других внешних моделей. Внутренняя модель БД также совместима с концептуальной моделью.
Связь между моделями устанавливается при помощи соответствующего отображения. Наличие отображения не означает, однако, взаимно однозначного соответствия между объектами моделей разных уровней.
Например, отдельные объекты внешней модели могут быть материализованы из различных объектов внутренней модели.
Внешний уровень
Концептуальный уровень
Внутренний уровень
Пользователь А Пользователь В
Пользователь С ПользовательD
Рис.Архитектура базы данных.
Различают централизованныеи распределенныеБД.
Централизованная БД хранится в памяти одной вычислительной системы. Если эта вычислительная система является компонентом сети ЭВМ, возможен распределенный доступ к такой БД, то есть доступ к ней пользователей различных ЭВМ данной сети.
Появление сетей ЭВМ позволило наряду с централизованными создать и распределенные БД.
Распределенная БДсостоит из нескольких, возможно пересекающихся или даже дублирующих друг друга частей, хранимых в различных ЭВМ вычислительной сети. Однако, пользователь распределенной БД не обязан знать каким образом её компоненты размещаются в узлах сети и представляет себе эту БД как единое целое. Работа с такой БД осуществляется с помощью распределенной СУБД.
Части распределенной БД, размещенные на отдельных ЭВМ сети, управляются собственными (локальными) СУБД и могут использоваться одновременно как самостоятельные локальные БД. Локальные СУБД не обязательно должны быть одинаковыми в разных узлах сети.
Проектирование БД– одна из наиболее ответственных и трудных задач, связанных с созданием ИС. В результате её решения должны быть определены:
Содержание БД;
Эффективный способ её организации;
Инструментальные средства управления данными, которые будут применяться в создаваемой системе.
В настоящее время создан ряд систем автоматизации проектирования БД.
Например, НИКА (встроенная система АПРБД, иерархическая модель), KOMOD-G(реляционная КМ наSQL), СИНТЕЗ-Т,OMEGA(ПБД средствами БЗ) ,MASTER(ПиД КМ с помощью модели «сущность-связь»). Однако они не стали пока таким же массовым инструментом разработчика ИС, как СУБД. Проектирование БД до сих пор осуществляется главным образом вручную, и качество проекта определяется интуицией и опытом проектировщика.
Вывод:при разработке ИС проектировщики обычно стремятся, чтобы БД была интегрированной. Это означает, прежде всего, что критерий оценки возможных вариантов построения БД носит «социальный» характер и направлен на интегральную эффективность системы, а не на удовлетворение интересов отдельных её пользователей.
При этом могут учитываться приоритеты и частота решения отдельных задач, их требования к вычислительным ресурсам, используемые части БД. К сожалению, на практике учет таких критериев оказывается сложной задачей. Разработчики и персонал администрации системы чаще всего вынуждены ограничиваться интуитивными соображениями. Однако в ответственных случаях для решения этой проблемы используют методы оптимизации, проводят эксперименты для получения нужных оценок.
Одним из важных необходимых элементов интегрированного подхода к разработкам БД является минимизация избыточности данных. Наличие избыточных данных создает предпосылки для нарушения непротиворечивости БД, создает трудности при её ведении. Для решения возникающих здесь проблем в случае Реляционных систем БД разработана теория нормализации.