распознанный текст 1. Теория баз данных Общие понятия
 Скачать 283.55 Kb.
|
|
Глава 6 Теория баз данных Общие понятия Модели данных Реляционные базы данных Постреляционные модели и базы данных Проектирование баз данных Современные информационные системы, основанные на концепции интеграции данных, характеризуются огромными объемами хранимых данных, сложной организацией, необходимостью удовлетворять разнообразные требования многочисленных пользователей. Данная глава призвана сформировать представление о базах данных (БД), в ней рассказывается о возможностях систем управления базами данных (СУБД) и их использовании. Основные функциональные возможности и технологические операции при работе с СУБД рассматриваются без привязки к конкретному типу программного продукта. Знания, полученные при изучении данной главы, являются базовыми при практическом знакомстве с любым новым видом СУБД. Общие понятия Целью любой информационной системы является обработка данных об объектах реального мира. В широком смысле база данных — это совокупность сведений о конкретных объектах реального мира в какой-либо предметной области. Под предметной областью принято понимать часть реального мира, например, предприятие, вуз и т. д., подлежащую изучению с целью организации управления и автоматизации. В Рассмотрим несколько определений термина «база данных» (database).  се эти определения не являются противоречивыми или взаимоисключающими. Скорее, они представляют разные точки зрения авторов на одно и то же понятие. Сложность определения заключается в том, что компьютерные базы данных за свою не очень длинную историю прошли несколько этапов развития, от файловых систем, хранящих в себе «сырые» (неупорядоченные) данные, до постреляционных СУБД, содержимым которых являются данные, обладающие поведением (объекты). Остановимся на еще одном определении. Щ  зщ данных — ато информационная модель фттх, хранимых в рам яти комт>10тераи П  од информационной моделью понимают информацию об объекте, отобранную и структурированную в соответствии с заданной целью. И  сторически первые базы данных создавались на основе файловых систем, и вся ответственность за работу с ними возлагалась на прикладное программное обеспечение, использовавшее эти базы. Файловые базы данных сегрдня практически не применяются. В современной технологии баз данных предполагается, что создание базы данных, ее поддержка и обеспечение доступа пользователей к ней осуществляются централизованно с помощью специального программного инструментария — системы управления базами данных. Кроме базы данных и программного обеспечения, обеспечивающего основную функциональность СУБД, в состав современных серверов баз данных входят всевозможные средства разработки и механизмы взаимодействия с пользователем на высоком уровне (генераторы отчетов, конструкторы таблиц, построители запросов и форм). Эти средства разработки, сами являясь приложениями пользователя, позволяют создавать приложения, функционирующие как часть СУБД (например, формы и отчеты MS Access или веб-публикации в Oracle и MS SQL Server). На рис. 6.1 представлена схема, в которой определены основные термины, используемые при обсуждении СУБД.  Рис. 6.1. Терминология СУБД Компоненты среды функционирования СУБД СУБД представляет собой комплекс программных средств, в работе которого принимает участие множество людей, как обслуживающих эти программы, так и использующих результат их работы. На рис. 6.2 представлены основные компоненты СУБД. П База данных База данных содержит: данные метаданные процедуры Ядро СУБД Разработчик Средства для создания таблиц Средства для создания формул Средства для создания запросов Средства для создания отчётов  Процессор форм Процессор запросов Генератор отчётов Средства обработки, реализованные на процедурных языках Прикладные программы > Пользователи I Прикладные программы Рис. 6.2. Компоненты среды функционирования СУБД рограммное обеспечение К программному обеспечению относятся все компьютерные программы, используемые в работе системы управления базами данных. Для выполнения всех функций СУБД требуется программное обеспечение трех видов: системное программное обеспечение, программное обеспечение СУБД, а также прикладные программы и утилиты. Поскольку программное обеспечение СУБД функционально располагается между системным и приложениями пользователя, его относят к разряду промежуточного (middleware) программного обеспечения. Системное программное обеспечение управляет всеми компонентами оборудования и обеспечивает доступ к нему всех остальных приложений, работающих на компьютере. Примеры системного программного обеспечения: Windows, Linux, UNIX, MVS, MacOS, OpenSolaris и др. Подсистема обработки СУБД управляет базой данных, реализуя функции СУБД. Средства проектирования СУБД предназначены для получения доступа к данным и манипулирования ими в среде СУБД. Прикладные программы (приложения пользователя) в большинстве случаев служат для представления данных, хранящихся в БД, в виде отчетов и таблиц. Люди Сюда относятся все пользователи системы управления базой данных. Если взять за основу функциональные обязанности, то в системе управления базами данных можно выделить шесть основных групп пользователей: системные администраторы, администраторы баз данных, системные аналитики, проектировщики баз данных, программисты и конечные пользователи. Системные администраторы несут ответственность и обеспечивают надежное функционирование системного программного обеспечения. Администраторы баз данных (Data Base Administrator, DBA) управляют работой СУБД, обеспечивают функционирование СУБД, создают учетные записи пользователей СУБД, назначают права, ограничивают доступ, выполняют различные процедуры, связанные с обеспечением безопасности и надежности хранения данных. Системные аналитики выполняют работу по сбору, систематизации и уточнению требований к структуре данных, приложениям и отчетам. Проектировщики базы данных (системные архитекторы) проектируют структуру БД. Программисты разрабатывают прикладное программное обеспечение. Они проектируют и создают формы ввода и отображения данных, отчеты и процедуры, с помощью которых конечные пользователи получают доступ к данным и возможность манипулирования ими. Конечные пользователи применяют прикладные программы с целью выполнения ежедневных операций, например, в компании — это продавцы, заведующие складами, работники бухгалтерии, руководители и управляющие. Конечные пользователи высшего руководящего звена применяют информацию, полученную из базы данных, для решения тактических и стратегических задач предприятия. База данных База данных включает в себя данные, метаданные и процедуры. Данные. Под терминами «данные», «информация» или «сведения» в данном контексте понимается весь фактический материал, хранящийся в базе данных. Данные являются необработанным сырьем, которое подлежит соответствующему структурированию. Принятие решения о том, какую информацию поместить в БД, каким образом ее упорядочить и структурировать, является важнейшей частью работы системных архитекторов (проектировщиков) базы данных. Метаданные составляют содержимое системного каталога базы данных и представляют собой сведения об именах и структуре таблиц, именах и правах пользователей, наименовании и типах ограничений, о процедурах, функциях и других объектах базы данных. Процедуры являются важным компонентом системы. Они устанавливают стандарты ведения коммерческой, технологической и производственно-технической деятельности в рамках предприятия и в отношениях с клиентами. Процедуры также используются для организации наблюдения и аудита как за вводимой в БД информацией, так и за информацией, порождаемой на основе извлекаемых данных. Классификация СУБД Классификация по типу принятой модели данных Классификацию баз данных по модели данных иллюстрирует рис. 6.3. Иерархические базы данных основаны на иерархической модели данных, в которой связь между объектами базы данных образует перевернутое дерево. При такой модели каждый нижележащий элемент иерархии соединен только с одним расположенным выше элементом  Рис. 6.3. Классификация баз данных по модели данных Сетевые базы данных основаны на сетевой модели данных, в которой связи между объектами данных могут быть установлены в произвольном порядке. Реляционные базы данных основаны на реляционной модели данных, в которой каждая единица данных в базе данных однозначно определяется именем таблицы (называемой отношением), идентификатором записи (кортежа) и именем поля. Объектно-реляционные базы данных содержат объектно-ориентированные механизмы построения структур данных (как минимум, механизмы наследования и поддержки методов) в виде расширений языка и программных надстроек над ядром СУБД. Объектно-ориентированные базы данных определяют как новое поколение баз данных, основанное на сочетании трех принципов: реляционной модели, стандартов на описание объектов и принципов объектно-ориентированного программирования. Классификация по архитектуре Классификацию баз данных по архитектуре иллюстрирует рис. 6.4.  Рис. 6.4. Классификация баз данных по архитектуре В локальных базах данных все данные и объекты СУБД находятся на одном компьютере. В распределенных базах данных различные части данных (группы таблиц, таблицы и даже фрагменты таблиц) и объекты СУБД могут находится на разных компьютерах. Пример. В качестве примера можно привести сложное производство (или сеть супермаркетов), разные части которого находятся в разных городах. Каждое предприятие накапливает «свои» данные. Необходимо, чтобы каждое из предприятий имело доступ к одним и тем же данным, как своим, так и данным других предприятий. Решением данной проблемы может быть создание одной локальной базы данных на одном компьютере с механизмом удаленного доступа. Однако это решение нерационально, поскольку быстрый доступ к данным будут получать клиентские компьютеры только того предприятия, на котором находится СУБД. Другим решением данной проблемы может быть создание на каждом предприятии своей копии СУБД. В этом случае возникает затруднение с синхронизацией данных между копиями (особенно в масштабах нашей страны, где в Хабаровске может быть разгар рабочего дня, а в Москве — глубокая ночь). Распределенная СУБД в этом случае обеспечивает механизм хранения данных в разных базах данных таким образом, что при обращении совокупность разных баз данных выглядит как одна база. Тогда часто используемые данные («свои» данные) находятся в той части базы данных, которая расположена на предприятии. А при необходимости обратиться к «чужим» данным, СУБД делает запрос к удаленной СУБД и получает данные оттуда. Совокупность разных баз данных на разных компьютерах с точки зрения клиента выглядит как одна база данных. Классификация по способу доступа к БД Классификацию баз данных по способу доступа иллюстрирует рис. 6.5.  Рис. 6.5. Классификация баз данных по способу доступа В мэйнфреймовых базах данных пользовательское рабочее место представляет собой текстовый или графический терминал, а вся информация обрабатывается на том же компьютере, где находится СУБД. В файл-серверных СУБД файлы данных располагаются централизованно на файл-сервере, а ядро СУБД находится на каждом клиентском компьютере. Доступ к данным осуществляется через локальную сеть. Синхронизация чтений и обновлений осуществляется посредством файловых блокировок. Преимуществом этой архитектуры является низкая нагрузка на ЦП сервера, а недостатком — высокая загрузка локальной сети. Клиент-серверные СУБД состоят из клиентской части (которая входит в состав прикладной программы) и сервера. Клиент-серверные СУБД, в отличие от файл- серверных, обеспечивают разграничение доступа между пользователями и мало загружают сеть и клиентские машины. Сервер является внешней по отношению к клиенту программой, и при необходимости его можно заменить другим. Недостаток клиент-серверных СУБД состоит в самом факте существования сервера (что плохо для локальных программ — в них удобнее встраиваемые СУБД) и больших вычислительных ресурсах, потребляемых сервером. Встраиваемая СУБД представляет собой программную библиотеку, которая позволяет унифицированным образом хранить большие объемы данных на локальной машине. Доступ к данным может происходить посредством запросов на языке SQL либо путем вызова функций библиотеки из приложения пользователя. Встраиваемые СУБД быстрее обычных клиент-серверных и не требуют развертывания сервера. Классификация по скорости обработки информации Классификацию баз данных по скорости обработки информации иллюстрирует рис. 6.6.  Рис. 6.6. Классификация баз данных по скорости обработки информации Операционные (operational), или рабочие (production), базы данных обладают высокими скоростями реакции на запрос, извлечения и представления информации. Хранилища данных и многомерные хранилища данных (data warehouse, OLAP) — это базы данных с очень большим объемом информации, подготовка представления которой занимает значительный объем времени. Функции СУБД Абстракция данных, управление словарем данных. Функционирование СУБД предусматривает, что определения элементов данных и их отношений (метаданные) хранятся в словаре данных (data dictionary). В свою очередь любые программы получают доступ к данным посредством СУБД. Для поиска необходимых структур данных и их отношений СУБД использует словарь данных, помогая избежать кодирования таких сложных взаимосвязей в каждой программе. Вдобавок любые изменения, которые делаются в структуре базы данных, автоматически регистрируются в словаре данных, что также освобождает программиста от необходимости модифицировать программы доступа к изменившимся структурам данных. СУБД обеспечивает абстракцию данных, тем самым устраняя в системе структурную зависимость и зависимость по данным. Управление хранением данных. СУБД создает сложные структуры, необходимые для хранения данных, освобождая программистов от определения и программирования физических свойств данных. Современные СУБД обеспечивают хранение не только данных, но и связанных с данными экранных форм, схем отчетов, правил проверки данных, кода процедур, систем обработки мультимедиа, форматов изображений, и т. п. Преобразование и представление данных. СУБД берет на себя задачу структурирования вводимых данных, преобразуя их в форму, удобную для хранения. Поэтому СУБД и в данном случае избавляет человека от рутинной работы по преобразованию логического формата данных в физический формат. Обеспечивая независимость данных, СУБД преобразует логические запросы в команды, определяющие их физическое местоположение и извлечение. Таким образом, СУБД обеспечивает программную независимость и абстракцию данных. Управление безопасностью. СУБД создает систему безопасности, которая обеспечивает защиту пользователя и конфиденциальность данных внутри БД. Правила безопасности устанавливают, какие пользователи могут получить доступ к базе данных, к каким элементам данных пользователь может получить доступ, какие операции с данными (чтение, добавление, удаление или изменение) может выполнять пользователь. Управление многопользовательским доступом. СУБД создает сложные структуры, обеспечивающие доступ к данным нескольких пользователей одновременно. Для того чтобы обеспечить целостность и непротиворечивость данных, в СУБД применяются сложные алгоритмы, гарантирующие, что несколько пользователей могут получить одновременный доступ к базе данных без риска нарушить ее целостность. Управление резервным копированием и восстановлением. В СУБД имеются процедуры резервного копирования и восстановления данных, обеспечивающие их безопасность и целостность. Современные СУБД содержат специальные утилиты, с помощью которых администраторы базы данных могут выполнять регулярные и экстренные процедуры резервного копирования и восстановления данных. Восстановление данных производится после повреждения БД, например, в случае появления сбойного сектора на жестком диске или после аварийного отключения питания. Такая возможность необходима для обеспечения целостности данных. Управление целостностью данных. В СУБД предусмотрены правила, обеспечивающие целостность данных, что позволяет минимизировать избыточность данных и гарантировать их непротиворечивость. Для обеспечения целостности данных используются их связи, которые хранятся в словаре данных. Поддержка языка доступа к данным и интерфейсов прикладного программирования. СУБД обеспечивает доступ к данным при помощи языка запросов. Язык запросов — это непроцедурный язык, то есть он предоставляет пользователю возможность определить, что необходимо выполнить, не указывая, как это сделать. В состав языка запросов СУБД входят два основных компонента: язык определения данных (Data Definition Language, DDL) и язык манипулирования данными (Data Manipulation Language, DML). DDL определяет структуры, в которых размещаются данные, a DML позволяет конечным пользователям извлекать данные из БД. СУБД также предоставляет программистам доступ к данным из процедурных языков третьего поколения, таких как COBOL, С, PASCAL и др. В составе СУБД имеются административные утилиты, ориентированные на администраторов и проектировщиков базы данных и предназначенные для внедрения, текущего контроля и обслуживания базы данных. Интерфейсы взаимодействия с базой данных. Текущее поколение СУБД обеспечивает специальные программы взаимодействия, разработанные для того, чтобы база данных могла принимать запросы конечных пользователей в сетевом окружении. Фактически, возможности взаимодействия конечных пользователей с базой данных являются неотъемлемой составляющей современных СУБД. Например, СУБД предоставляет функции взаимодействия для получения доступа к базе данных, используя в качестве внешнего интерфейса интернет-браузер (Mozilla Firefox, Opera или Internet Explorer). В подобной среде взаимодействие может осуществляться несколькими способами: конечный пользователь может получать ответы на запросы, заполняя экранные формы с помощью выбранного им браузера; средствами СУБД можно автоматизировать публикацию форм отчетов в Интернете посредством веб-форматирования, что позволяет просматривать отчеты в любом браузере и др. Модели данных Классификация моделей данных Центральным понятием в области баз данных является понятие модели данных. Термин «модель» используется в нескольких значениях. В предыдущем разделе уже было дано определение модели данных. Другим его значением является описание на разных уровнях абстракции схемы конкретной базы данных, предназначенной для работы в определенных условиях. Несмотря на то что термины одинаковы, во втором случае подразумевается моделирование с точки зрения разработчиков информационной системы (базы данных). Для того чтобы спроектировать и реализовать реляционную базу данных, состоящую из трех таблиц, нет необходимости прибегать к специальным технологиям и приемам, такого рода работу можно выполнить непосредственно при помощи соответствующих SQL-выражений. Но когда речь идет о базе данных для информационной системы предприятия, такое «прямое» проектирование становится не только утомительным и трудоемким, но во многих случаях просто невозможным. Для того чтобы облегчить работу проектировщиков, в процесс проектирования включается этап моделирования данных. На этом этапе структуры данных сначала представляются в виде графических схем и диаграмм, облегчающих общее пони- мание связей и взаимодействия объектов базы данных, а также способствующих установлению большего соответствия бизнес-процессов предприятия, бизнес-правил информационной системы и структуры данных, а затем уже реализуют базу данных в виде набора реляционных таблиц и объектов. На рис. 6.7 представлена классификация моделей данных в соответствии с трехуровневой архитектурой, предложенной в 1975 г. Комитетом планирования стандартов и норм (Standards Planning and Requirements Committee, SPARC) Национального института стандартизации США (American National Standard Institute, ANSI), ANSI/X3/SPARC (рис. 6.8). Так, модели данных, обозначенные на рис. 6.7 как физические, соответствуют первому уровню архитектуры ANSI/X3/SPARC, да- талогические модели можно отнести ко второму, внутреннему уровню архитектуры, а инфологические модели соответствуют концептуальному уровню архитектуры, изображенной на рис. 6.8  Рис. 6.7. Классификация моделей данных Поскольку практически все современные базы данных построены на основе реляционной модели данных, для моделирования данных чаще всего применяется модель «сущность-связь», лучшим образом позволяющая моделировать схемы реляционных баз данных. Однако прежде чем рассмотреть основные принципы применения этой модели, ознакомимся с базовыми терминами и определениями, принятыми при описании структур данных. Пользователь 1 Пользователь 2 Пользователь N  Рис. 6.8. Трехуровневая модель представления данных ANSI-SPARC Термины и определения Элемент данных определяет тип данных. Понятие элемента данных применяется как при концептуальном моделировании, так и в ходе создания физической модели данных. На этапе концептуального моделирования элемент данных — это элемент абстрактного типа данных, а во время создания физической модели данных это уже элемент базового типа конкретной СУБД. Пример. Во время концептуального моделирования элементу данных, в котором нужно сохранить строку, присваивается абстрактный тип String. Если эта концептуальная модель будет реализована на СУБД MS SQL Server, то элемент абстрактного типа String преобразуется к базовому типу строковых данных, принятому в MS SQL Server, то есть к типу varchar. При реализации этого же элемента на СУБД Oracle он получит тип char, являющийся базовым типом для строки в Oracle. Понятие записи в базах данных близко к этому понятию в языках программирования, но не во всем совпадает с ним.  Схема (тип) записи определяет связную последовательность полей — позиций в структурах хранения записей. Внутренняя структура каждого поля определяется типом данных, заданным в объявлении каждой записи. Для уникальной идентификации записей одно или более полей записи должны быть объявлены явно как ключ записи. Значениями полей являются конкретные данные (числа, символьные строки, слова и пр. Модель «сущность-связь» Команда разработчиков анализирует требования и строит пользовательскую модель данных, или модель требований к данным. Эта модель является представлением требований пользователя к структуре и связям объектов, которые должны храниться в базе данных. Для создания пользовательской модели данных команда разработчиков задействует средства, которые называются моделью «сущность- связь» и семантической объектной моделью. Эти средства состоят из языковых и изобразительных стандартов для представления пользовательской модели данных. Их роль в разработке баз данных подобна той роли, которую исполняют алгоритмы и псевдокод в программировании. В этом разделе описывается и иллюстрируется использование модели «сущность-связь» (Entity-Relationship Model, MER), или ER-модели, введенной Питером Ченом (Peter Chen) в 1976 г. Модель «сущность-связь» вошла в состав множества CASE-инструментов, которые также внесли свой вклад в ее эволюцию. На сегодняшний день не существует единого общепринятого стандарта для модели «сущность-связь», но есть набор общих конструкций, которые лежат в основе большинства вариантов этой модели. Символы, применяемые для графического представления модели «сущность-связь», весьма различны. Термины модели «сущность-связь»  Поскольку термином сущность обозначают класс объектов, можно также встретить определение класса сущностей, которое является синонимичным термину сущность. Сущность определяет собой некоторый тип сложной структуры данных, то есть наличие определенных полей (атрибутов), их имена и элементарные типы данных, к которым они принадлежат. Пример. Пример структурно-графического определения класса АВТОР изображен на рис. 6.9.
Рис. 6.9. Определение класса сущностей АВТОР В этом примере АВТОР — это наименование сущности, в то время как Ш, Фамилия, Имя и Отчество являются атрибутами сущности, которым присвоены типы, соответствующие хранимым данным. П Атрибуты*  ример, Класс сущностей АВТОР описывается атрибутами ID, Фамилия, Имя, Отчество. В  модели «сущность-связь» предполагается, что все экземпляры данного класса сущностей имеют одинаковые атрибуты.щ ' -Л В экземпляре сущности, в отличие от класса, каждый атрибут содержит данные, характеризующие конкретный объект. Пример, Пример нескольких экземпляров сущности класса АВТОР приведен на рис. 6.10.
Рис. 6.10. Несколько экземпляров сущностей класса АВТОР К  ак видно из рисунка, все экземпляры имеют одинаковые атрибуты, но разные данные (значения) каждого атрибута. Идентификатор экземпляра сущности состоит из одного или более атрибутов сущности. Идентификатор может быть уникальным (unique) либо неуникальным (nonunique). Если идентификатор является уникальным, его значение будет указывать на один и только на один экземпляр сущности. Если идентификатор является неуникальным, его значение будет указывать на некоторое множество экземпляров. Синонимом термину «идентификатор» является термин «ключ». Пример, В классе сущностей АВТОР идентификатором является атрибут ID. В случае, если мы в качестве идентификатора приняли бы атрибут Фамилия, этот идентификатор был бы неуникальным. Например, он указывал бы на группу сущностей со значением Толстой у данного атрибута.  Модель «сущность-связь» включает в себя классы связей и экземпляры связей. Классы связей определяют взаимоотношения между классами сущностей, а экземпляры связи — взаимоотношения между экземплярами сущностей. У связей могут быть атрибуты. Класс связей может затрагивать несколько классов сущностей. Число классов сущностей, участвующих в связи, называется степенью связи (relationship degree). Изображенная на рис. 6.11 связь ПРОДАВЕЦ-ЗАКАЗ имеет степень 2, поскольку в ней участвуют два класса сущностей: ПРОДАВЕЦ и ЗАКАЗ. Связь РОДИТЕЛЬ имеет степень 3, так как в ней участвуют три класса сущностей: МАТЬ, ОТЕЦ и РЕБЕНОК. Связи степени 2 весьма распространены, их часто называют еще бинарными связями (binary relationships).  Рис. 6.11. Типы связей Типы бинарных связей На рис. 6.12 показаны три типа бинарных связей. В связи 1:1 (один к одному) одиночный экземпляр сущности одного типа связан с одиночным экземпляром сущности другого типа. Связь СЛУЖЕБНЫЙ-АВ- ТОМОБИЛЬ связывает одиночную сущность класса СОТРУДНИК с одиночной сущностью класса АВТОМОБИЛЬ. В соответствии с этой диаграммой, ни за одним сотрудником не закреплено более одного автомобиля и ни один автомобиль не закреплен более чем за одним сотрудником. | ||||||||||||||||||||||