лекции. Конспект лекций профессионального модуля пм. 02 Разработка и администрирование баз данных междисциплинарного курса
 Скачать 0.63 Mb.
|
3. Системы управления базами данных. Компоненты и структуры данных3.1. Обзор современных СУБД Развитие СУБД началось еще в 60-е годы прошлого века, когда разрабатывался проект полета корабля Apollo на Луну. Была разработана система GUKM (Generalized Update Access Method), использующая иерархическую структуру. Затем была предложена система IDS (Integrated Data Store), основанная на сетевой структуре. В 1970 году Кодд предложил реляционную модель данных, ставшую основой реляционных баз данных. Первые коммерческие продукты появились в конце 60-х – начале 80-х годов, тогда же был разработан структурированный язык запросов SQL. В 80-х годах были созданы различные реляционные СУБД – DB2, Oracle и другие. В настоящее время существует несколько десятков различных реляционных СУБД. Для персональных компьютеров – это Access, FoxPro, Paradox, InterBase, FireBird, Oracle и др. В 1976 году Чен предложил модель "сущность-связь" (Entity Relationship model – ER модель), которая в настоящее время стала самой распространенной технологией проектирования баз данных. Появились две новые системы: объектно-ориентированная СУБД или ООСУБД и объектно-реляционная СУБД или ОРСУБД. Однако действительная структура этих моделей не совсем ясна. Эти СУБД относятся к СУБД третьего поколения и еще до конца не разработаны. Современные СУБД кратко характеризуются следующими принципами их построения: значительная часть современных СУБД может работать на компьютерах различной архитектуры под управлением разных операционных систем; подавляющее большинство современных СУБД использует реляционную модель данных; современные СУБД для описания данных и манипуляции ими используют принятые стандарты в области языков; многие существующие СУБД являются сетевыми СУБД, которые предназначены для поддержки многопользовательского режима работы с базой данных; существующие СУБД имеют развитые средства администрирования баз данных и средства защиты хранимой в них информации. В настоящее время число используемых СУБД превышает несколько десятков. Основные термины: CASE- средства (Computer Assisted System Engineering). Нормализация РБД – одна из возможных технологий проектирования РБД. Файл-серверные СУБД и клиент-серверные СУБД. Транзакции – transformation action. Отношение – плоская таблица, состоящая из столбцов и строк. Триггер – действие, связанное с событием, которое возникает при попытке изменить содержимое таблицы. Хранимые процедуры – Stored procedure – процедуры, выполняемые на стороне сервера. 3.2. Методы описания схем баз данных в современных СУБД Основная цель СУБД заключается в том, чтобы предложить пользователю абстрактное представление данных, скрыв от него конкретные особенности хранения и управления ими. При этом, поскольку БД является общим ресурсом, то каждому пользователю может потребоваться свое, отличное от других, представление об информации, хранимой в БД. Архитектура большинства современных СУБД строится на базе так называемой архитектуры ANSI – SPARC (American National Standard Institute Standards Planning and Requirements Committee). Хотя модель ANSI/SPARC не стала стандартом, тем не менее, она представляет собой основу для понимания некоторых функциональных особенностей СУБД. Наиболее важным моментом этой модели является определение трех уровней абстракции, то есть трех различных уровней описания элементов данных. В модели определены три уровня – внешний, концептуальный и внутренний (см. рис.5). Причины, по которым желательно выполнять такое разделение: Каждый пользователь должен иметь возможность обращаться к одним и тем же данным, используя свое собственное представление о них. Пользователи не должны иметь дело с подробностями физического хранения данных в базе. АБД должен иметь возможность изменять структуру хранения данных в базе, не оказывая влияния на пользовательское представление. Внешний уровень – представление базы данных с точки зрения пользователей. Этот уровень описывает ту часть базы данных, которая относится к каждому пользователю. С точки зрения пользователя определение данных представляется в контексте предметной области.  Рис. 5. Архитектура современных СУБД Каждый пользователь имеет дело с представлением «реального мира», выраженным в наиболее удобной для него форме. Интерес представляют следующие понятия: Сущность – объект «реального мира», такой как Работник, Отдел, Договор. Атрибуты – свойства или качества каждой сущности (например, Имя, Адрес, Зарплата для сущности Работник). Связи – взаимоотношения между сущностями (например, Работник работает в Отделе). Внешнее представление пользователя содержит только те сущности, атрибуты и связи «реального мира», которые интересны этому пользователю. Другие сущности, атрибуты и связи, которые ему не интересны, также могут быть представлены в базе данных, но они важны для другого пользователя. (Адрес – для отдела кадров, а бухгалтерия может им не пользоваться). Концептуальный уровень – обобщающее представление базы данных. Этот уровень описывает то, какие данные хранятся в базе данных, а также связи, существующие между ними. Этот уровень обобщает представления всех пользователей – фактически, это полное представление требований к данным со стороны организации, в которой работают пользователи. Это представление не зависит от способа хранения этих данных. На концептуальном уровне представлены следующие компоненты: все сущности, их атрибуты и связи; накладываемые на данные ограничения; семантическая информация о данных; информация о безопасности и целостности данных. Описание сущности должно содержать сведения о типах данных атрибутов (целочисленный, действительный, символьный) и их длине (количество значащих цифр или максимальное количество символов), не должно включать сведений об объеме занятого пространства в байтах. Внутренний уровень – физическое представление базы данных в компьютере. Этот уровень описывает, как информация хранится в базе данных. Этот уровень содержит описание структур данных и организации отдельных файлов, используемых для хранения данных в запоминающих устройствах. На физическом уровне определяются методы взаимодействия СУБД с операционной системой компьютера. Общее описание БД называется схемой базы данных. Существует три различных типа схем базы данных, которые соответствуют трем уровням абстракции. На самом верхнем уровне имеется несколько внешних схем или подсхем, которые соответствуют разным представлениям данных (рис. 6). На концептуальном уровне описание базы данных называют концептуальной схемой, а на самом нижнем уровне абстракции – внутренней схемой. Внешнее представление 1
Внешнее представление 2
Рис.6 Внешнее представление Концептуальный уровень
Внутренний уровень Struct STAFF Staff No integer (идентификатор) Branch No integer FName char (15) LName char (15) DOB date Salary double–precision Важно различать описание базы данных и саму базу данных. Описанием базы данных является схема БД, которая создается при проектировании и меняется достаточно редко. Данные, содержащиеся в БД, могут меняться часто (например, при добавлении сведений о новом сотруднике). Схема создается с помощью некоторого языка определения данных конкретной СУБД. Основным назначением трехуровневой архитектуры является обеспечение независимости от данных, которая означает, что изменения на нижних уровнях никак не влияют на верхние уровни. Различают два типа независимости от данных: логическую и физическую. Логическая независимость от данных – означает полную защищенность внешних схем от изменений, вносимых в концептуальную схему. Такие изменения концептуальной схемы как добавление или удаление новых сущностей, атрибутов или связей должны осуществляться без необходимости внесения изменений в уже существующие внешние схемы. Об этих изменениях должны знать только те, для которых они предназначены. Физическая независимость от данных – означает защищенность концептуальной схемы от изменений, вносимых во внутреннюю схему. Такие изменения внутренней схемы, как использование различных файловых систем или структур хранения, разных устройств хранения должны осуществляться без необходимости внесения изменений в концептуальную или внешнюю схемы. 3.3. Структуры данных СУБД, общий подход к организации представлений, таблиц, индексов и кластеров Пользователи нуждаются в описании схемы на некотором понятийном для всех уровне, которое называется моделью данных. Модель данных – интегрированный набор понятий для описания данных, связей между ними и ограничений, накладываемых на данные в некоторой организации. Модель данных является абстрактным представлением объектов и событий «реального мира», а также существующих между ними связей. В этой абстракции акцент делается на самых важных и неотъемлемых аспектах деятельности организации, а все второстепенные свойства игнорируются. Таким образом, можно сказать, что модель данных представляет саму организацию. Модель данных можно рассматривать как сочетание трех указанных ниже компонентов: структурной части – набора правил, по которым может быть построена база данных; управляющей части, определяющей типы допустимых операций с данными (операции обновления и извлечения данных, а также операции изменения структуры базы данных); набора ограничений поддержки целостности данных, гарантирующих корректность используемых данных. Цель построения модели данных заключается в понятном представлении данных, которое можно будет легко применить при проектировании базы данных. Для трехуровневой архитектуры существуют следующие три связанные модели данных (объектные модели): Внешняя модель данных, которую иногда называют моделью предметной области (она отображает представления каждого типа пользователей организации). Silverrun BPM (функциональная модель, модель потоков данных). Внешние объекты, процессы, потоки, накопители. Описание структур данных. Концептуальная модель данных, которая отображает логическое (или обобщенное) представление о данных, не зависимое от типа выбранной СУБД. Silverrun ERX (ER – модель). Сущности, связи, атрибуты. Внутренняя модель данных, которая отображает концептуальную схему для конкретной СУБД. Silverrun RDM (логическая модель, для конкретной СУБД – реляционная модель для реляционной СУБД). Домены, типы атрибутов. Кроме объектных моделей существуют модели данных на основе записей. В зависимости от способа записи данных база данных состоит из нескольких (множества) записей фиксированного формата, которые могут иметь разные типы. Каждый тип записи определяет фиксированное количество полей, каждое из которых имеет фиксированную длину. Существует три основных типа записей, определяющие три типа моделей: реляционная модель данных (relational data model); сетевая модель данных (network data model); иерархическая модель данных (hierarchical data model). Реляционная модель данных основана на понятии математических отношений. В реляционной модели данные и связи представлены в виде таблиц (см. рис.7), каждая из которых имеет несколько столбцов с уникальными именами. Сущность «Работник»
Сущность «Отдел»
Рис.7 Описание данных в реляционной модели В реляционной модели данных единственное требование состоит в том, чтобы база данных с точки зрения пользователя выглядела как набор таблиц. Это требование относится только к внешнему и концептуальному уровням архитектуры ANSI/SPARC. В сетевой модели данные представлены в виде коллекций записей, а связи – в виде наборов (см. рис.8). Сетевую модель можно представить как граф с записями в виде узлов (вершин) графа, и наборов данных в виде его ребер.  Рис.8. Сетевая модель данных Иерархическая модель данных является подтипом сетевой модели. В ней данные представлены как коллекции записей, а связи – как наборы (см. рис.9). Однако узел может иметь только одного родителя.  Рис.9. Иерархическая модель данных Наиболее важные термины описания структуры данных представлены на рисунке 10. Отношение – плоская таблица, состоящая из столбцов и строк. Атрибут – поименованный столбец отношения. Домен – набор допустимых значений для одного или нескольких атрибутов. Кортеж – строка отношения. Степень – количество атрибутов, содержащихся в отношении. Кардинальность – количество кортежей, которое содержит отношение. Первичный ключ – атрибут или множество атрибутов, которые выбраны для уникальной идентификации кортежей отношения.  Рис.10. Структура данных Реляционная база данных – набор отношений (нормализованных). Каждый кортеж отношения представляет собой определенное высказывание об объекте. Точное определение термина отношение: Пусть задано множество доменов Тi (I = 1, 2,..n), все из которых необязательно должны быть различными. Тогда r будет отношением, определенным на этих доменах, если оно состоит из двух частей – заголовка и тела, где а) заголовок – это множество из n атрибутов вида Ai : Ti; здесь Ai – имена атрибутов, а Ti – соответствующие им имена типов. б) тело – это множество из m кортежей t; здесь t, в свою очередь, является множеством компонентов вида Ai : Vi, в которых Vi – значение типа Ti, то есть значение атрибута Ai в кортеже t (I = 1, 2,..n). Подходы к определению понятия отношения могут быть различными. Математически отношение может быть определено как множество кортежей, являющееся подмножеством декартова произведения фиксированного числа областей (доменов). В результате получаем, что в каждом кортеже должно быть одинаковое число компонентов (атрибутов) и значение каждого из них выбирается из некоторого определенного домена. В терминах таблицы, заголовок – это строка, состоящая из названий столбцов и соответствующих имен типов, а тело – это множество строк данных. Отношения обладают следующими свойствами: в них нет одинаковых кортежей; кортежи отношения не имеют упорядоченности в направлении сверху вниз; атрибуты в кортежах не упорядочены слева направо; каждый кортеж содержит ровно одно значение для каждого атрибута. Свойство 1: Свойство следует из того факта, что тело отношения – это математическое множество (кортежей), а в математике множества по определению не содержат одинаковых элементов. Таблица, в общем случае, может содержать одинаковые строки (при отсутствии правил, запрещающих это). Свойство 2: Свойство следует из того, что тело отношения – это математическое множество, а простые множества в математике не упорядочены. В таблице строки упорядочены сверху вниз. Свойство 3: Свойство следует из того факта, что заголовок отношения также определен, как множество (атрибутов). Атрибут всегда определяется по имени, а не по расположению. В таблице столбцы могут быть упорядочены. Свойство 4: Свойство следует из определения кортежа: кортеж является множеством из n компонентов. Отношение, удовлетворяющее этому свойству, называется нормализованным или представленным в первой нормальной форме (1НФ). В частности, возможно существование типа, значениями которого будут отношения и, следовательно, существование отношения с атрибутами, значениями которых также являются отношения. Дополнительные свойства: Отношение имеет имя, которое отличается от имен всех других отношений. Каждый атрибут имеет уникальное имя. Значения атрибута берутся из одного и того же домена. Все кортежи одного отношения должны иметь одно и то же количество атрибутов. Необходимо иметь возможность уникальной идентификации каждого кортежа отношения с помощью атрибутов. Атрибут или множество атрибутов, которое единственным образом идентифицирует кортеж данного отношения, называется суперключом. Потенциальный ключ – это суперключ, который не содержит подмножества, также являющегося суперключом данного отношения. Такой ключ обладает двумя свойствами: уникальность – в каждом кортеже отношения значение ключа единственным образом идентифицирует этот кортеж; неприводимость – никакое допустимое подмножество ключа не обладает свойством уникальности. Отношение может иметь несколько потенциальных ключей. Если ключ состоит из нескольких атрибутов, то он называется составным ключом. Первичный ключ – это потенциальный ключ, который выбран для уникальной идентификации кортежей внутри отношения. Потенциальные ключи, которые не выбраны в качестве первичного ключа, называются альтернативными ключами. Отделение  Штат  Рис.11 Пример отношений с выбранными ключами Атрибут «Город» не может быть выбран в качестве потенциального ключа. Каждое значение атрибута «Номер отделения» имеет уникальное значение, поэтому этот атрибут является потенциальным ключом. Атрибуты «Номер телефона» и «Номер факса» также являются потенциальными ключами (рис.11). «Номер отдела» - первичный ключ. Внешний ключ – это атрибут или множество атрибутов, которое соответствует какому-либо потенциальному ключу некоторого (может быть, того же самого) отношения. Внешние ключи отражают определенную связь между кортежами этих отношений. Схема отношения обозначается с помощью имени отношения, за которым (в скобках) перечисляются имена атрибутов. При этом первичный ключ подчеркивается. Отделение (Номер отдела, Адрес, Район, Город, Почт. код, Номер телефона, Номер факса). Как уже говорилось ранее для управления отношениями в реляционных СУБД можно использовать процедурные и непроцедурные языки. Коддом были предложены формальные (а не дружественные пользователю) языки – реляционная алгебра и реляционное исчисление. Реляционная алгебра представляет процедурный язык, который может быть использован, чтобы сообщить СУБД как следует построить требуемое отношение на базе одного или нескольких существующих в базе данных отношений. Реляционное исчисление представляет собой непроцедурный язык, который можно использовать для определения того, каким будет некоторое отношение, созданное на основе одного или нескольких других отношений базы данных. Реляционная алгебра и реляционное исчисление эквивалентны друг другу. Для каждого выражения алгебры существует эквивалентное выражение в реляционном исчислении (и наоборот). Следует различать сами отношения (то есть значения отношений) и переменные-отношения, так как отношения являются переменными (в математическом смысле), над которыми можно осуществлять определенные действия – конструировать новые отношения, изменять их значения и т.д. Кодд определил восемь операторов реляционной алгебры, использующих отношения в качестве операндов и возвращающих отношения в качестве результата. Восемь операторов составляют две группы по четыре оператора: 1. Традиционные операции над множествами – объединение, пересечение, разность и декартово произведение (с учетом того, что их операндами являются отношения, а не произвольные множества). 2. Специальные реляционные операции – выборка, проекция, соединение и деление. Выборка  Возвращает отношение, содержащее все кортежи из заданного отношения, которые удовлетворяют определенным условиям. Проекция  Возвращает отношение, содержащее кортежи заданного отношения, состоящие из определенных атрибутов (остальные атрибуты исключены). Соединение  Возвращает отношение, содержащее все возможные кортежи, которые представляют собой комбинацию атрибутов двух кортежей, принадлежащих двум заданным отношениям, при условии, что в этих двух комбинируемых кортежах присутствуют одинаковые значения в одном или нескольких общих для исходных отношений атрибутах (причем эти общие значения в результирующем кортеже появляются один раз, а не дважды). Деление  Для заданных двух отношений (унарных) и одного бинарного возвращает отношение, содержащее все кортежи из первого унарного отношения, которые содержатся также в бинарном отношении и соответствуют всем кортежам во втором унарном отношении. Результатом оператора деления R на S является набор кортежей отношения R, определенных на множестве атрибутов не входящих в S, которые соответствуют комбинации всех кортежей отношения S. Объединение  Возвращает отношение, содержащее все кортежи, которые принадлежат либо одному из двух заданных отношений, либо им обоим. Произведение  Возвращает отношение, содержащее все возможные кортежи, которые являются сочетанием двух кортежей, принадлежащих соответственно двум заданным отношениям. Пересечение  Возвращает отношение, содержащее все кортежи, которые принадлежат одновременно двум заданным отношениям. Разность  Возвращает отношение, содержащее все кортежи, которые принадлежат первому из двух заданных отношений и не принадлежат второму. Так как результатом выполнения любой операции является отношение, то можно записывать вложенные реляционные выражения, то есть выражения, в которых операнды сами представлены реляционными выражениями, причем произвольной сложности. Основная цель алгебры – обеспечить запись реляционных выражений. Выражения можно преобразовывать в соответствии с правилами преобразования. Таким образом, реляционная алгебра может служить хорошим обоснованием для построения оптимизатора запросов СУБД. Реляционная алгебра в явном виде представляет набор операций, которые можно использовать, чтобы сообщить системе, как в базе данных из определенных отношений построить некоторое требуемое отношение. Реляционное исчисление просто представляет систему обозначений для определения требуемого отношения в терминах данных отношений.    сначала выполнить соединение отношения поставщиков и отношения поставок по атрибуту «Номер поставщика»;  Выбрать из результата кортежи с номером детали P2.
Выполнить для результата выборки операцию проекции по атрибутам “Номер поставщика” и “Город”.
Этот же запрос в терминах реляционного исчисления формулируется приблизительно так: получить атрибуты “№ поставщика” и “Город” для таких поставщиков, у которых в отношении “Поставки” существует запрос о поставке с тем же значением атрибута “№ поставщика” и со значением атрибута “Номер поставки”, равным P2. Select P.”Номер поставки”, S.”Город” From “Поставщики” S, “Поставки” P Where P.“Номер поставщика” = S.” Номер поставщика ” And P.” Номер поставки ”=P2 Индекс (Index) — это объект базы данных, создаваемый для повышения производительности выборки данных и контроля уникальности первичного ключа. Функция (Function) - это объект базы данных, представляющий поименованный набор команд SQL и/или операторов специализированных языков обработки программирования базы данных, который при выполнении возвращает значение — результат вычислений. Для обработки данных специальным образом или для реализации поддержки ссылочной целостности базы данных используются объекты: хранимая процедура, триггер. Хранимая процедура (Stored procedure) — это объект базы данных, представляющий поименованный набор команд SQL. Триггер (Trigger) - это объект базы данных, который представляет собой специальную хранимую процедуру. Эта процедура запускается автоматически, когда происходит связанное с триггером событие (например, до вставки строки в таблицу). Данные объекты реляционной базы данных представляют собой программы, т.е. исполняемый код. Этого код обычно называют серверным кодом (server-side code), поскольку он выполняется компьютером, на котором установлена СУБД. Планирование и разработка такого кода является одной из задач проектировщика реляционной базы данных. Для эффективного управления разграничением доступа к данным в Interbase/Firebird поддерживается объект роль. Роль (Role) — это объект базы данных, представляющий собой поименованную совокупность привилегий, которые могут назначаться пользователям, категориям пользователей или другим ролям. |
етр