Лекция №2
Тема: «Среда базы данных»
Трехуровневая архитектура ANSI-SPARC
Цель трехуровневой архитектуры заключается в отделении пользовательского
представления базы данных от ее физического представления. Ниже перечислено
несколько причин, по которым желательно выполнить такое рйзделение.
• Каждый пользователь должен иметь возможность обращаться к одним и
тем же данным, реализуя свое собственное представление о них. Каждый
пользователь должен иметь возможность изменять свое представление о
данных, причем это изменение не должно оказывать влияния на других
пользователей.
• Пользователи не должны непосредственно иметь дело с такими подробно-
стями физического хранения данных в базе, как индексирование и хеши-
рование (приложение В). Иначе говоря, взаимодействие пользователя с ба-
зой не должно зависеть от особенностей хранения в ней данных.
• Администратор базы данных (АБД) должен иметь возможность изменять структуру хранения данных в базе, не оказывая влияния на пользовательские представления.
• Внутренняя структура базы данных не должна зависеть от таких изменений физических аспектов хранения информации, как переключение на новое устройство хранения.
• АБД должен иметь возможность изменять концептуальную структуру базы
данных без какого-либо влияния на всех пользователей.
Внешний уровень
Внешний уровень. Представление базы данных с точки зрения пользователей.
Этот уровень описывает ту часть базы данных, которая относится.к каждому пользователю.
Внешний уровень состоит из нескольких различных внешних представлений базы данных. Каждый пользователь имеет дело с представлением "реального мира", выраженным в наиболее удобной для него форме. Внешнее представление содержит только те сущности, атрибуты и связи "реального мира", которые интересны пользователю. Другие сущности, атрибуты или связи, которые ему неинтересны, также могут быть представлены в базе данных, но пользователь может даже не подозревать об их существовании.
Помимо этого, различные представления могут по-разному отображать одни и те же данные. Например, один пользователь может просматривать даты в формате (день, месяц, год), а другой — в формате (год, месяц, день). Некоторые представления могут включать производные или вычисляемые данные, которые не хранятся в базе данных как таковые, а создаются по мере надобности. Например, в проекте DreamHome можно было бы организовать просмотр данных о возрасте сотрудников. Однако вряд ли стоит хранить эти сведения в базе данных, поскольку в таком случае их пришлось бы ежедневно обновлять. Вместо этого в базе данных хранятся даты рождения сотрудников, а возраст вычисляется средствами СУБД при обнаружении соответствующей ссылки. Представления могут также включать комбинированные или производные данные из нескольких объектов.
Концептуальный уровень
Концептуальный уровень. Обобщающее представление; базы данных,1 Этот
уровень описывает то, какие данные хранятся в базе данных, а также связи, существующие между ними.
Промежуточным уровнем в трехуровневой архитектуре является концепту-
альный уровень. Этот уровень содержит логическую структуру всей базы данных(с точки зрения АБД). Фактически это полное представление требований к данным со стороны организации, которое не зависит от любых соображений относительно способа их хранения. На концептуальном уровне представлены следующие компоненты:
• все сущности, их атрибуты и связи;
• накладываемые на данные ограничения;
• семантическая информация о данных;
• информация о мерах обеспечения безопасности и поддержки целостности
данных.
Концептуальный уровень поддерживает каждое внешнее представление, в том смысле, что любые доступные пользователю данные должны содержаться (или могут быть вычислены) на этом уровне. Однако этот уровень не содержит никаких сведений о методах хранения данных. Например, описание сущности должно содержать сведения о типах данных атрибутов (целочисленный, действительный или символьный) и их длине (количестве значащих цифр или максимальном количестве символов), но не должно включать сведений об организации хранения данных, например об объеме занятого пространства в байтах.
Внутренний уровень
Внутренний уровень. Физическое представление базы данных в компьютере.
Этот уровень описывает, как информация хранится в базе данных.
Внутренний уровень описывает физическую реализацию базы данных и предназначен для достижения оптимальной производительности и обеспечения экономного использования дискового пространства. Он содержит описание структур данных и организации отдельных файлов, используемых для хранения данных на запоминающих устройствах. На этом уровне осуществляется взаимодействие СУБД с методами доступа операционной системы (вспомогательными функциями хранения и извлечения записей данных) с целью размещения данных на запоминающих устройствах, создания индексов, извлечения данных и т.д. На
внутреннем уровне хранится следующая информация:
• распределение дискового пространства для хранения данных и индексов;
• описание подробностей сохранения записей (с указанием реальных разме-
ров сохраняемых элементов данных);
• сведения о размещении записей;
• сведения о сжатии данных и выбранных методах их шифрования.
Ниже внутреннего уровня находится физический уровень (physical level), который контролируется операционной системой, но под управлением СУБД. Однако функции СУБД и операционной системы на физическом уровне не вполне четко разделены и могут варьироваться от системы к системе. В одних СУБД используются многие предусмотренные в данной операционной системе методы доступа, тогда как в других применяются только самые основные и реализована собственная файловая организация. Физический уровень доступа к данным ниже СУБД состоит только из известных операционной системе элементов (например, указателей на то, как реализовано последовательное распределение и хранятся ли поля внутренних записей на диске в виде непрерывной последовательности байтов).
Схемы, отображения и экземпляры
Общее описание базы данных называется схемой базы данных. Существуют
три различных типа схем базы данных, которые определяются в соответствии с уровнями абстракции трехуровневой архитектуры, как показано на рис. 2.1. На самом высоком уровне имеется несколько внешних схем или подсхем, которые соответствуют разным представлениям данных. На концептуальном уровне описание базы данных называют концептуальной схемой, а на самом низком уровне абстракции — внутренней схемой. Концептуальная схема описывает все сущности, атрибуты и связи между ними, с указанием необходимых ограничений поддержки целостности данных. На нижнем уровне находится внутренняя схема,которая является полным описанием внутренней модели данных. Она содержит определения хранимых записей и методов представления, 'описания полей данных, сведения об индексах и выбранных схемах хеширования. Для каждой базы данных существует только одна концептуальная и одна внутренняя схема.
Независимость от данных
Основным назначением трехуровневой архитектуры является обеспечение независимости от данных, которая означает, что изменения на нижних уровнях не влияют на верхние уровни. Различают два типа независимости от данных: логическую и физическую.
Логическая независимость от данных. Логическая независимость от данных означает полную защищенность внешних схем от изменений, вносимых в концептуальную схему.
Такие изменения концептуальной схемы, как добавление или удаление новых
сущностей, атрибутов или связей, должны осуществляться без необходимости внесения изменений в уже существующие внешние схемы или корректировки прикладных программ. Ясно, что пользователи, для которых эти изменения
предназначались, должны знать о них, но очень важно, чтобы другие пользователи даже не подозревали об этом.
Физическая независимость от данных. Физическая независимость от данных означает защищенность концептуальной схемы от изменений, вносимых во внутреннюю схему.
Языки баз данных
Внутренний язык СУБД для работы с данными состоит из двух ^частей: языка определения данных (Data Definition Language — DDL) и языка манипулирования данными (Data Manipulation Language — DML). Язык DDL используется для определения схемы базы данных, а язык DML — для чтения и обновления данных, хранимых в базе. Эти языки называются подъязыками данных, поскольку в них отсутствуют конструкции для выполнения всех вычислительных операций, обычно используемых в языках программирования высокого уровня, таких как условные операторы или операторы цикла. Во многих СУБД предусмотрена возможность внедрения операторов подъязыка данных в программы, написанные на таких языках программирования высокого уровня, как COBOL, Fortran, Pascal, Ada, С, C++, Java или Visual Basic. В этом случае язык высокого уровня принято называть базовым языком (host language). Перед компиляцией файла программы на базовом языке, содержащей внедренные операторы подъязыка данных, такие операторы удаляются и заменяются вызовами функций. Затем этот предварительно обработанный файл обычным образом компилируется с помещением результатов в объектный модуль, который компонуется с библиотекой, содержащей вызываемые в программе функции СУБД. После этого полученный прораммный текст готов к выполнению. Помимо механизма внедрения, для большинства подъязыков данных предоставляются также средства интерактивного выполнения операторов, вводимых пользователем непосредственно с терминала.
Язык определения данных — DDL
Язык DDL. Описательный язык, который позволяет АБД или пользователю описать и именовать сущности и атрибуты, необходимые для работы некоторого
приложения, а также связи, имеющиеся между различными сущностями, кроме того, указать ограничения целостности и защиты.
Схема базы данных состоит из набора определений, выраженных на специ-
альном языке определения данных — DDL. Язык DDL используется как для определения новой схемы, так и для модификации уже существующей. Этот язык нельзя использовать для управления данными.
Язык управления данными —DML
Язык DML. Язык, содержащий набор операторов для поддержки основных one-j
; раций манипулирования содержащимися в базе данными.
К операциям управления данными относятся:
• вставка в базу данных новых сведений;
• модификация сведений, хранимых в базе данных;
• извлечение сведений, содержащихся в базе данных;
• удаление сведений из базы данных.
Таким образом, одна из основных функций СУБД заключается в поддержке
языка манипулирования данными, с помощью которого пользователь может создавать выражения для выполнения перечисленных выше операций с данными.
Понятие манипулирования данными применимо как к внешнему и концепту-
альному уровням, так и к внутреннему уровню. Однако на внутреннем уровне для этого необходимо определить очень сложные процедуры низкого уровня, позволяющие выполнять доступ к данным весьма эффективно. На более высоких уровнях, наоборот, акцент переносится в сторону большей простоты использования, и основные усилия направляются на обеспечение эффективного взаимодействия пользователя с системой.
Процедурные языки DML
Процедурный язык DML. Язык, который позволяет сообщить системе о том, какие данные необходимы, и точно указать, каких можно извлечь.
С помощью процедурного языка DML пользователь, а точнее — программист,указывает на то, какие данные ему необходимы и как их можно получить. Это значит, что пользователь должен определить все операции доступа к данным(осуществляемые посредством вызова соответствующих процедур), которые должны быть выполнены для получения требуемой информации. Обычно такой процедурный язык DML позволяет извлечь запись, обработать ее и, в зависимости от полученных результатов, извлечь другую запись, которая должна быть подвергнута аналогичной обработке, и т.д. Подобный процесс извлечения данных продолжается до тех пор, пока не будут извлечены все запрашиваемые данные. Обычно операторы процедурного языка DML встраиваются в программу на языке программирования высокого уровня, которая содержит конструкции для обеспечения циклической обработки и перехода к другим участкам кода. Языки DML сетевых и иерархических СУБД обычно являются процедурными
Непроцедурные языки DML
Непроцедурный язык DML. Язык, который позволяет указать лишь то, какие данные требуются, но не то, как т следует извлекать.
Непроцедурные языки DML позволяют определить весь набор требуемых данных с помощью одного оператора выборки или обновления. С помощью непроцедурных языков DML пользователь указывает, какие данные ему нужны, без определения способа их получения. СУБД транслирует выражение на языке DML в процедуру (или набор процедур), которая обеспечивает манипулирование затребованным набором записей. Такой подход освобождает пользователя от необходимости знать подробности внутренней реализации структур данных и особенности алгоритмов, используемых для извлечения и возможного преобразования
данных. В результате работа пользователя становится в определенной степени независимой от данных. Непроцедурные языки часто также называют декларативными языками. Реляционные СУБД в той или иной форме обычно включают поддержку непроцедурных языков манипулирования данными — чаще всего это язык структурированных запросов SQL (Structured Query Language) или язык
запросов по образцу QBE (Query-by-Example). Непроцедурные языки обычно
проще понять и использовать, .чем процедурные языки DML, поскольку пользователем выполняется меньшая часть работы, а СУБД — большая.
Языки 4GL
Аббревиатура 4GL представляет собой сокращенный английский вариант на-
писания термина язык четвертого поколения (Fourth-Generation Language).
Четкого определения этого понятия не существует, хотя, по сути, речь идет о
некотором стенографическом варианте языка программирования. Если для организации некоторой операции с данными на языке третьего поколения (3GL) типа COBOL потребуется написать сотни строк кода, то для реализации этой же операции на языке четвертого поколения достаточно 10-20 строк.
Выделяют
следующие типы языков четвертого поколения:
• языки представления информации, например языки запросов или генера-
торы отчетов;
• специализированные языки, например языки электронных таблиц и баз
данных;
• генераторы приложений, которые при создании приложений обеспечивают
определение, вставку, обновление или извлечение сведений из базы данных;
• языки очень высокого уровня, предназначенные для генерации кода при-
ложений.
В качестве примеров языков четвертого поколения можно указать упоминав-
шиеся выше языки SQL и QBE.
Генераторы форм
Генератор форм представляет собой интерактивный инструмент, предназна-
ченный для быстрого создания шаблонов ввода и отображения данных в экранных формах. Генератор форм позволяет пользователю определить внешний вид экранной формы, ее содержимое и место расположения на экране. С его помощью можно задавать цвета элементов экрана, а также другие характеристики,
например полужирное, подчеркнутое, мерцающее или реверсивное начертание шрифта и т.д. Более совершенные генераторы форм позволяют создавать вычисляемые атрибуты с использованием арифметических операторов или агрегирующих функций, а также задавать правила проверки вводимых данных.
Генераторы отчетов
Генератор отчетов является инструментом создания отчетов на основе хранимой в базе данных информации. Он подобен языку запросов в том смысле, что пользователю предоставляются средства создания запросов к базе данных и извлечения из нее информации, используемрй для представления в отчете. Однако генераторы отчетов, как правило, предусматривают гораздо большие возможности управления внешним видом отчета. Генератор отчета позволяет либо автоматически определять вид получаемых результатов, либо с помощью специальных команд создавать свой собственный вариант внешнего вида печатаемого документа
Генераторы графического представления данных
Этот генератор представляет собой инструмент, предназначенный для извле-
чения информации из базы данных и отображения ее в виде диаграмм с графическим представлением существующих тенденций и связей. Обычно с помощью подобного генератора создаются гистограммы, круговые, столбчатые, точечные диаграммы и т.д.
Генераторы приложений
Генератор приложений представляет собой инструмент для создания про-
грамм, взаимодействующих с базой данных. Применяя генератор приложений, можно сократить время, необходимое для проектирования полного объема требуемого прикладного программного обеспечения. Генераторы приложений обычно состоят из предварительно созданных модулей, содержащих фундаментальные функции, которые требуются для работы большинства программ. Эти модули, обычно создаваемые на языках высокого уровня, образуют "библиотеку"
доступных функций. Пользователь указывает, какие задачи программа должна выполнить, а генератор приложений определяет, как их следует выполнить.
Модели данных и концептуальное
Моделирование
Модель данных. Интегрированный набор понятий для описания и обработки
данных, связей между ними и ограничений, накладываемых на данные в некоторой организации.
Модель является представлениям "реального мира" объектов и событий, а также существующих между ними связей. Это некоторая абстракция, в которой акцент делается на самых важных и неотъемлемых аспектах деятельности организации, а все второстепенные свойства игнорируются. Таким образом, можно сказать, что модель данных представляет саму организацию. Модель должна отражать основные концепции, представленные в таком виде, который позволит проектировщикам и пользователям базы данных обмениваться конкретными и недвусмысленными мнениями о роли тех или иных данных в организации. Модель данных можно рассматривать как сочетание трех указанных ниже компонентов.
• Структурная часть, т.е. набор правил, по которым может быть построена
база данных.
• Управляющая часть, определяющая типы допустимых операций с данными
(сюда относятся операции обновления и извлечения данных, а также опе-
рации изменения структуры базы данных).
• Набор (необязательный) ограничений поддержки целостности данных, га-
рантирующих корректность используемых данных.
Цель построения модели данных заключается в представлении данных в по-
нятном виде. Если такое представление возможно, то модель данных можно легко применить при проектировании базы данных. Для отображения обсуждавшейся в разделе 2.1 архитектуры ANSI-SPARC можно определить следующие три связанные модели данных:
• внешняя модель данных, отображающая представления каждого сущест-
вующего в организации типа пользователей, которую иногда называют
предметной областью (Universe of Discourse — UoD);
• концептуальная модель данных, отображающая логическое (или обобщен-
ное) представление о данных, независимое от типа выбранной СУБД;
• внутренняя модель данных, отображающая концептуальную схему опреде-
ленным образом, подходящим для выбранной целевой СУБД.
В литературе предложено и опубликовано достаточно много моделей
Объектные модели данных
При создании объектных моделей данных используются такие понятия, как
сущности, атрибуты и связи. Сущность — это отдельный элемент деятельности организации (сотрудник или клиент, место или вещь, понятие или событие), который должен быть представлен в базе данных. Атрибут — это свойство, которое описывает некоторый аспект объекта и значение которого следует зафиксировать, а связь является ассоциативным отношением между сущностями. Ниже перечислены некоторые наиболее общие типы объектных моделей данных.
• Модель типа "сущность-связь", или ER-модель (Entity-Relationship model).
• Семантическая модель.
• Функциональная модель.
• Объектно-ориентированная модель.