Архитектура системы БД.
Было дано определение БД: База данных – совокупность специальным образом организованных данных, хранимых в памяти вычислительной системы и отображающих состояние объектов и их взаимосвязей в рассматриваемой предметной области.
Если посмотреть на БД с точки зрения ее использования, т.е. с практической точки зрения, то можно сказать, что:
БД – совместно используемый несколькими пользователями набор логически связанных данных (и описание этих данных), предназначенный для удовлетворения информационных потребностей организации.
БД – это единое большое хранилище данных, которое однократно определяется, а затем используется совместно многими пользователями.
Совместное использование одной БД многими пользователями позволяет хранить данные с минимальной избыточностью (пример).
БД хранит не только сами данные, но и их описания (словарь данных) следовательно появляется независимость между программами и данными.
Данные логически связаны. При анализе информационных потребностей организации необходимо выделить сущности, атрибуты и связи.
Сущность – отдельный тип объекта организации (человек, место, вещь, событие, понятие), который нужно представить в БД.
Атрибут – свойство, которое описывает некоторую характеристику описываемого объекта.
Связь – это то, что объединяет несколько сущностей.
Пример. Рассмотрим пример промышленной компании. В этом случае желательно хранить информацию о: проектах, деталях (для этих проектов), поставщиках (деталей), складах (где хранятся эти детали), служащих… все перечисленное представляет собой сущности.
Между этими объектами существуют связи или отношения (показаны стрелками). На приведенной схеме большинство связей объединяют два типа объекта, но это не всегда так. Например стрелка может объединять три типа объекта (поставщики – детали – проекты). Это отражает тот факт, что определенные поставщики поставляют определенные детали для определенных проектов. Вообще говоря это не тоже самое, что комбинация двух связей: поставщики – детали и детали – проекты. Информация о том, что «поставщик П3, поставляет деталь Д2 для проекта Пр6» говорит больше чем комбинация «поставщик П3 поставляет деталь Д2» и «деталь Д2 используется в проекте Пр6». Получение из второй и третьей связи первой, является вообще говоря ложным, это иногда называют «ловушкой при соединении».
Связь может охватывать и один тип объекта (детали). Она отражает то, что некоторые детали могут являться компонентами других деталей.
В общем случае одни и те же объекты могут быть соединены произвольным числом связей (проекты – служащие две связи: одна из них «работает над», другая «руководит проектом»).
Таким образом, подобная БД представляет собой сущности, атрибуты и связи, иначе говоря, содержит логически связанные данные.
Основная цель СУБД в том, чтобы предложить пользователю абстрактное представление данных, скрыв от него особенности хранения и управление ими. Следовательно, отправной точкой при проектировании БД должно быть абстрактное и общее описание информационных потребностей организации, которое должно найти свое отражение в создаваемой БД.
Более того, поскольку БД является общим ресурсом, то каждому пользователю может потребоваться свое, отличное от других представление о характеристиках информации, сохраняемой в БД.
Для удовлетворения этих потребностей архитектура большинства современных коммерческих СУБД в той или иной степени строится на базе трехуровневой архитектуры, предложенной американским комитетом по стандартизации ANSI.
Цель трехуровневой архитектуры в отделении пользовательского представления БД от ее физического представления.
Причины, по которым желательно выполнять такое разделение:
· каждый пользователь должен иметь возможность обращаться к одним и тем же данным, используя свое представление о них. Каждый пользователь должен иметь возможность изменить свое представление о данных, причем это изменение не должно касаться других пользователей.
· Пользователь не должен иметь дело с подробностями физического хранения данных, иначе говоря, взаимодействие пользователя с БД не должно зависеть от способа хранения данных в ней.
· Администратор БД (АБД) должен иметь возможность изменить структуру хранения данных в базе, не оказывая влияние на пользовательские представления.
· Внутренняя структура БД не должна зависеть от таких изменений аспектов хранения как переход на другое устройство хранения.
 |
Внешний уровень.
Внешний уровень – представление БД с точки зрения пользователей. Этот уровень описывает ту часть БД, которая относится к каждому пользователю.
Внешний уровень состоит из нескольких различных внешних представлений БД. Каждый пользователь имеет дело с представлениями «реального мира», выраженными в наиболее удобной для него форме. Поэтому его внешнее представление содержит только те сущности, атрибуты и связи, которые ему интересны. Другие объекты могут быть представлены в БД, но о них он может и не знать. (Например, пользователь из отдела кадров может рассматривать БД как совокупность записей об отделах и совокупность записей о служащих и ничего не знать о существовании записей о поставщиках и деталях.)
Различные представления могут по-разному отображать одни и те же данные. Например, один пользователь рассматривает даты в формате день-месяц-год, а другой – в формате год-месяц-день. Некоторые представления могут включать производные (вычислимые) данные, которые не хранятся в БД, а вычисляются по мере надобности (например возраст, если хранится дата рождения).
Концептуальный уровень.
Концептуальный уровень – обобщающее представление БД. Этот уровень описывает то, какие данные хранятся в БД, а также связи, существующие между ними.
Концептуальный уровень определяет обобщенное представление пользователей. Может быть много «внешних представлений», каждое из которых состоит из представления некоторой части БД, и может быть единственное «концептуальное представление», состоящее из представления БД в целом. Концептуальный уровень можно назвать обобщенной моделью предметной области, для которой создавалась БД. Как любая модель она отражает только существенные, с точки зрения обработки, особенности объектов реального мира.
Этот уровень содержит логическую структуру всей БД (с точки зрения АБД). Это полное представление требований к данным со стороны организации, которое не зависит от любых соображений относительно способа их хранения.
На концептуальном уровне представлены следующие компоненты:
· все сущности, их атрибуты и связи
· ограничения, накладываемые на данные
· семантическая информация о данных
· информация о мерах безопасности и поддержки целостности.
Концептуальный уровень поддерживает внешние представления в том смысле, что любые доступные пользователю данные должны содержаться (или могут быть вычислены) на этом уровне. Но этот уровень не содержит сведений о методах хранения данных. Например описание сущности должно содержать сведения о типах данных атрибутов (целые, действительные, текстовые…) и их длине, но не должно включать сведения об организации хранения, например объеме занятого пространства в байтах.
Внутренний уровень.
Внутренний уровень – физическое представление БД в компьютере. Этот уровень описывает как информация хранится в БД.
Внутренний уровень описывает физическую реализацию БД и предназначен для достижения оптимальной производительности и обеспечения экономии дискового пространства. Он содержит описание структур данных и организацию отдельных файлов, используемых для хранения данных в ЗУ. На этом уровне осуществляется взаимодействие СУБД с методами доступа ОС (функциями хранения и извлечения записей) с целью размещения данных на ЗУ, создания индексов, извлечения данных…
На внутреннем уровне хранится информация:
· распределение дискового пространства для хранения данных и индексов.
· Описание подробностей сохранения записей (с указанием реальных размеров сохраняемых элементов данных)
· Сведения о размещении записей.
· Сведения о сжатии и шифровке данных
Ниже внутреннего уровня находится физический уровень, который контролируется ОС, но под руководством СУБД. Но функции ОС и СУБД здесь не четко разделены и могут варьироваться от системы к системе.
Схемы и отображения.
Общее описание БД называется схемой БД. Существует три различных типа схем БД, которые определяются в соответствии с уровнями трехуровневой архитектуры.
На самом верхнем уровне находятся несколько внешних схем, которые соответствуют разным представлениям данных.
На концептуальном уровне описание БД называют концептуальной схемой. Концептуальная схема (КС) описывает все элементы данных и связи между ними, с указанием необходимых ограничений поддержки целостности БД. Для каждой БД имеется единственная КС.
На самом нижнем уровне - внутренняя схема. Внутренняя схема является полным описанием внутренней модели данных. Она содержит определения хранимых записей, методы представления, описания полей данных, сведения об индексах. Для любой БД имеется единственная внутренняя схема.
СУБД отвечает за установления связи между этими тремя типами схем и за проверку их непротиворечивости. Иначе говоря, СУБД должна убедиться, что любую внешнюю схему можно вывести на основе КС. Внешние схемы связаны с КС посредством «внешне концептуального отображения». Для установления соответствия между любыми внешними схемами и внутренней схемой СУБД должна использовать информацию из КС.
КС связана с внутренней схемой посредством «концептуально внутреннего отображения». Оно позволяет найти физическую запись или набор записей на ЗУ, которые образуют логическую запись в КС, с учетом любых ограничений, установленных для выполняемых над данной логической записью операций.
Пример.
|
| |||||
 |
Два внешних представления информации о персонале. Эти внешние представления сливаются воедино в одном концептуальном. Особенности данного процесса в том, что поле «возраст» преобразуется в поле «дата рождения». Поле «номер» из первого внешнего представления отображается в «личный номер» в записи концептуального представления (в процессе внешне концептуального отображения).
Затем концептуальный уровень отображается на внутренний, который содержит физическое описание структуры записи концептуального представления. На этом уровне определение структуры формулируется на языке высокого уровня. Эта структура содержит указатель (Next), который позволяет физически связать все записи о сотрудниках в единую цепочку. Порядок полей на внутреннем уровне отличается от порядка атрибутов, принятых на концептуальном уровне.
Важно различать описание БД и саму БД. Описанием БД является схема БД. Схема создается в процессе проектирования, причем изменяется она редко. В отличии от содержащейся в БД информации. Совокупность информации, хранящейся в БД в определенный момент времени называются состоянием БД.
Независимость от данных.
Основным назначением трехуровневой архитектуры является обеспечение независимости от данных, которая означает, что изменения на нижних уровнях никак не влияют на верхние уровни. Два типа независимости:
Логическая – означает полную защищенность внешних схем от изменений, вносимых в КС.
Такие изменения КС как добавление или изменение сущностей, атрибутов и связей должно осуществляться без изменения существующих внешних схем или прикладных программ. (пример) Ясно, что пользователи, для которых предназначались эти изменения должны о них знать, но очень важно, чтобы эти изменения не касались других пользователей.
Физическая независимость означает защищенность КС от изменений, вносимых во внутреннюю схему.
Такие изменения внутренней схемы как использование различных файловых систем или структур хранения, разных ЗУ должны осуществляться без изменения в КС.
Языки БД.
Внутренний язык СУБД для работы с данными состоит из двух частей: языка определения данных (DDL) и языка управления данными (DML).
Язык DDL используется для определения схемы базы данных. DML – для чтения и обновления данных, хранимых в БД.
Язык DDL.
Язык DDL – описательный язык, который позволяет АБД или пользователю описать и поименовать сущности, необходимые для работы некоторого приложения, а так же связи, имеющиеся между различными сущностями.
Схема данных состоит из набора определений, выраженных на языке DDL. Язык DDL используется как для определения новой схемы, так и для модификации существующей. Но этот язык не используется для управления данными.
На языке DDL описываются метаданные (данные, которые описывают объекты БД), т.е. создается словарь данных или системный каталог.
Язык DML.
Язык DML - язык, содержащий набор операторов для поддержки основных операций манипулирования содержащимися в БД данными.
К операциям относятся:
· вставка в БД новых сведений.
· Модификация сведений.
· Извлечение данных из БД.
· Удаление данных.
Понятие манипулирования данными применимо ко всем уровням архитектуры. Однако на внутреннем уровне для этого необходимо определить очень сложные процедуры низкого уровня, позволяющие выполнить доступ к данным очень эффективно. На более высоких уровнях акцент переносится в сторону большей простоты и основные усилия направлены на обеспечение эффективного взаимодействия пользователя с системой.
Языки DML различаются базовыми конструкциями извлечения данных.
Типы языков DML: процедурные и непроцедурные.
Процедурные языки позволяют сообщить системе о том, какие данные необходимы и указать как их можно извлечь.
С помощью процедурного языка программист указывает на то, какие данные ему необходимы и как их можно получить, т.е. программист (пользователь) должен определить все операции доступа к данным (посредством вызова соответствующих процедур), которые должны быть выполнены для получения требуемой информации.
Языки DML сетевых и иерархических СУБД обычно являются процедурными.
Непроцедурные языки DML.
Непроцедурный язык позволяет указать лишь то, какие данные требуются, но не то как их получить.
С помощью непроцедурного языка пользователь указывает какие данные он хочет получить. СУБД транслирует выражения языка в процедуру (или набор процедур), которая обеспечивает манипулирование затребованным набором записей. Данный подход освобождает пользователя от необходимости знать детали внутренней реализации структур данных и алгоритмов извлечения данных. Непроцедурные языки часто называют декларативными.
Реляционные СУБД обычно включают поддержку непроцедурных языков DML – чаще это язык структурированных запросов SQL или язык запросов по образцу QBE.
Часть непроцедурного языка DML, которая отвечает за извлечение данных, называется языком запросов. Язык запросов – высокоуровневый узкоспециализированный язык, предназначенный для удовлетворения различных требований по выборке информации из БД.