4. База данных Oracle. Реляционная алгебра, реляционные базы данных, теорема Хеза; понятие схемы, логическое представление базы данных; объекты схемы: таблица, представление.

СУБД Oracle – объектно-реляционная СУБД, т.е. реляционная СУБД, поддерживающая некоторые технологии, реализующие объектно-ориентированный подход.

а) реляционная алгебра, реляционные базы данных, теорема Хеза;

Реляционная модель данных — логическая модель данных, строгая математическая теория, состоящая из трех частей:

• Структурной части.

• Целостной части.

• Манипуляционной части.

Структурная часть описывает, какие объекты рассматриваются реляционной моделью. Постулируется, что единственной структурой данных, используемой в реляционной модели, являются нормализованные n-арные отношения.

Целостная часть описывает ограничения специального вида, которые должны выполняться для любых отношений в любых реляционных базах данных. Это целостность сущностей и целостность внешних ключей. Манипуляционная часть описывает два эквивалентных способа манипулирования реляционными данными - реляционную алгебру и реляционное исчисление.

Реляционная база данных — база данных, основанная на реляционной модели данных. Реляционная БД представляется пользователю как совокупность взаимосвязанных таблиц, каждая из которых содержит информацию об объектах определенного типа. В реляционной базе данных каждый объект задается записью (строкой) в таблице (например, информация о товаре, клиенте), а столбцы таблицы описывают различные характеристики этих объектов — атрибутов (например, наименование, код товара, сведения о клиенте). Записи, т. е. строки таблицы, имеют одинаковую структуру — они состоят из полей, хранящих атрибуты объекта. Каждое поле, т. е. столбец, описывает только одну характеристику объекта и имеет строго определенный тип данных. Все записи имеют одни и те же поля, только в них отображаются различные информационные свойства объекта.

В реляционной базе данных каждая таблица должна иметь первичный ключ — поле или комбинацию полей, которые единственным образом идентифицируют каждую строку таблицы. Если ключ состоит из нескольких полей, он называется составным. Ключ должен быть уникальным и однозначно определять запись. По значению ключа можно отыскать единственную запись. Ключи служат также для упорядочивания информации в БД.

Таблицы реляционной БД должны отвечать требованиям нормализации отношений. Нормализация отношений — это формальный аппарат ограничений на формирование таблиц, который позволяет устранить дублирование, обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты на ведение базы данных.

Для работы с реляционными БД применяют реляционные СУБД.

Атрибут отношения есть пара вида <Имя_атрибута : Имя_домена (тип_данных)>.

Отношение R, определенное на множестве доменов D₁,D₂,…,D_n (не обязательно различных), содержит две части: заголовок и тело.

Заголовок отношения содержит фиксированное количество атрибутов отношения: (<A₁:D₁>,<A₂:D₂>,…,<A_n:D_n>).

Тело отношения содержит множество кортежей отношения.

Каждый кортеж отношения представляет собой множество пар вида <Имя_атрибута:Значение_атрибута>: (<A₁:Val₁>,<A₂:Val₂>,…,<A_n:Val_n>).

Отношение обычно записывается в виде: R(<A₁:D₁>,<A₂:D₂>,…,<A_n:D_n>), или короче R(A₁,A₂,…,A_n), или просто R.

Реляционная алгебра — формальная система манипулирования отношениями в реляционной модели данных. Реляционная алгебра представляет собой набор операторов, использующих отношения в качестве аргументов, и возвращающие отношения в качестве результата. Таким образом, реляционный оператор f выглядит как функция с отношениями в качестве аргументов: R=f(R₁,R₂,…,R_n).

Реляционная алгебра является замкнутой, т.к. в качестве аргументов в реляционные операторы можно подставлять другие реляционные операторы, подходящие по типу: R=f(f₁(R₁₁,R₁₂,…), f₂(R₂₁,R₂₂,…),…). Таким образом, в реляционных выражениях можно использовать вложенные выражения сколь угодно сложной структуры.

Традиционно определяют восемь реляционных операторов, объединенных в две группы:

• Теоретико-множественные операторы: объединение, пересечение, вычитание, декартово произведение.

• Специальные реляционные операторы: выборка, проекция, соединение, деление.

Не все операторы реляционной алгебры являются независимыми - некоторые из них выражаются через другие реляционные операторы. Операторы соединения, пересечения и деления можно выразить через другие реляционные операторы, т.е. эти операторы не являются примитивными. Оставшиеся реляционные операторы (объединение, вычитание, декартово произведение, выборка, проекция) являются примитивными операторами - их нельзя выразить друг через друга.

В реализациях конкретных реляционных СУБД сейчас не используется в чистом виде ни реляционная алгебра, ни реляционное исчисление. Фактическим стандартом доступа к реляционным данным стал язык SQL. Язык SQL представляет собой смесь операторов реляционной алгебры и выражений реляционного исчисления, использующий синтаксис, близкий к фразам английского языка и расширенный дополнительными возможностями, отсутствующими в реляционной алгебре и реляционном исчислении. Вообще, язык доступа к данным называется реляционно-полным, если он по выразительной силе не уступает реляционной алгебре, т.е. любой оператор реляционной алгебры может быть выражен средствами этого языка. Именно таким и является язык SQL.

Теорема (Хеза). Пусть R(A,B,C) является отношением, и A,B,C - атрибуты или множества атрибутов этого отношения. Если имеется функциональная зависимость A→B, то проекции R₁=R[A,B] и R₂=R[A,C] образуют декомпозицию без потерь.

Доказательство. Необходимо доказать, что R₁ JOIN R₂ = R для любого состояния отношения R. В левой и правой части равенства стоят множества кортежей, поэтому для доказательства достаточно доказать два включения для двух множеств кортежей:

R₁ JOIN R₂ R и R₁ JOIN R₂ R.

Докажем первое включение. Возьмем произвольный кортеж r=(a,b,c)R. Докажем, что он включается также и в R₁ JOIN R₂. По определению проекции, кортежи r₁=(a,b)R₁ и r₂=(a,c)R₂. По определению естественного соединения кортежи r₁ и r₂, имеющие одинаковое значение a общего атрибута A, будут соединены в процессе естественного соединения в кортеж (a,b,c)R₁ JOIN R₂. Таким образом, включение доказано.

Докажем обратное включение. Возьмем произвольный кортеж r=(a,b,c)R₁ JOIN R₂. Докажем, что он включается также и в R. По определению естественного соединения получим, что в имеются кортежи r₁=(a,b)R₁ и r₂=(a,c)R₂. Т.к. R₁=R[A,B], то существует некоторое значение c₁, такое что кортеж r₁=(a,b,c₁)R. Аналогично, существует некоторое значение b₁, такое что кортеж r₂=(a,b₁,c)R. Кортежи r₁ и r₂ имеют одинаковое значение атрибута A, равное a. Из этого, в силу функциональной зависимости A→B, следует, что b=b₁. Таким образом, кортеж r₂=(a,b,c)R. Обратное включение доказано.

Теорема доказана.

Замечание. В доказательстве теоремы Хеза наличие функциональной зависимости не использовалось при доказательстве включения R₁ JOIN R₂ R. Это означает, что при выполнении декомпозиции и последующем восстановлении отношения при помощи естественного соединения, кортежи исходного отношения не будут потеряны. Основной смысл теоремы Хеза заключается в доказательстве того, что при этом не появятся новые кортежи, отсутствовавшие в исходном отношении.

Т.к. алгоритм нормализации (приведения отношений к 3НФ) основан на имеющихся в отношениях функциональных зависимостях, то теорема Хеза показывает, что алгоритм нормализации является корректным, т.е. в ходе нормализации не происходит потери информации.

б) понятие схемы, логическое представление базы данных;

Общее описание базы данных называется схемой базы данных. Существуют три различных типа схем базы данных, которые определяются в соответствии с уровнями абстракции трехуровневой архитектуры. На самом высоком уровне имеется несколько внешних схем или подсхем, которые соответствуют разным представлениям данных. На концептуальном уровне описание базы данных называют концептуальной схемой, а на самом низком уровне абстракции — внутренней схемой. Концептуальная схема описывает все сущности, атрибуты и связи между ними, с указанием необходимых ограничений поддержки целостности данных. На нижнем уровне находится внутренняя схема, которая является полным описанием внутренней модели данных. Она содержит определения хранимых записей и методов представления, описания полей данных, сведения об индексах и выбранных схемах хеширования. Для каждой базы данных существует только одна концептуальная и одна внутренняя схема.

СУБД отвечает за установление соответствия между этими тремя типами схем, а также за проверку их непротиворечивости. Иначе говоря, СУБД должна обеспечивать, чтобы каждую внешнюю схему можно было вывести на основе концептуальной схемы. Для установления соответствия между любыми внешней и внутренней схемами СУБД должна использовать информацию из концептуальной схемы. Концептуальная схема связана с внутренней схемой посредством концептуально внутреннего отображения. Оно позволяет СУБД найти фактическую запись или набор записей на физическом устройстве хранения, которые образуют логическую запись в концептуальной схеме, с учетом любых ограничений, установленных для операций, выполняемых над данной логической записью. Оно также позволяет обнаружить любые различия в именах объектов, именах атрибутов, порядке следования атрибутов, их типах данных и т.д. Наконец, каждая внешняя схема связана с концептуальной схемой с помощью концептуально внешнего отображения. С его помощью СУБД может отображать имена пользовательского представления на соответствующую часть концептуальной схемы.

Важно различать описание базы данных и саму базу данных. Описанием базы данных является схема базы данных. Схема создается в процессе проектирования базы данных, причем предполагается, что она изменяется достаточно редко.

Однако содержащаяся в базе данных информация может меняться часто — например, всякий раз при вставке сведений о новом сотруднике или новом объекте сдаваемой в аренду недвижимости. Совокупность информации, хранящейся в базе данных в любой определенный момент времени, называется состоянием базы данных. Следовательно, одной и той же схеме базы данных может соответствовать множество ее различных состояний. Схема базы данных иногда именуется содержанием базы данных, а ее состояние — детализацией

Применительно к Oracle

Одна из основных задач СУБД - это возможность дать право на просмотр, создание и модификацию информации только тем лицам, которые имеют для этого законную причину. Для этого пользователи должны проходить идентификацию и на ее основе получать доступ лишь к четко определенным объектам.

Традиционный подход к процедуре идентификации состоит в том, что у каждого пользователя есть свое уникальное имя пользователя (логин) и пароль. СУБД Oracle также поддерживает использование различных альтернативных технологий, таких как смарт-карты или другие физические устройства в сочетании с паролями и PIN-кодами посредством опции Oracle Advanced Security Option.

В базе данных учетная запись не является физической структурой. Тем не менее, все объекты базы данных принадлежат пользователям. Так, системный пользователь SYS владеет таблицами словаря данных, содержащим информацию обо всех остальных структурах базы данных. Системному пользователю SYSTEM принадлежат представления, полученные на основе таблиц пользователя SYS. Все объекты базы данных создаются с учетными записями их владельцев.

Набор объектов, принадлежащих учетной записи пользователя называется схемой. Можно создать пользователя, у которого не будет права входа в систему, но схему которого можно будет использовать для отдельного хранения объектов базы данных.

в) объекты схемы: таблица, представление.

Таблица (англ. table) — (в реляционной модели данных) структура хранения данных, состоящая из строк и столбцов и обладающая следующими свойствами:

• значения, находящиеся в одном столбце таблицы имеют один тип данных;

• атомарность: ячейки не содержат структур данных, например массивов;

• таблицы не содержат одинаковых строк.

Слово «таблица» является неформальным синонимом термина «отношение» (англ. relation). Аналогично, «строка» таблицы — это кортеж, «тип данных» — домен, «столбец» — атрибут.

Представление (англ. view, в сленге программистов часто используется в качестве заимствования из английского — «вьюшка») — виртуальная (логическая) таблица, представляющая собой поименованный запрос (алиас к запросу), который будет подставлен как подзапрос при использовании представления.

В отличие от обычных таблиц реляционной БД, представление не является самостоятельной частью набора данных, хранящегося в базе. Содержимое представления динамически вычисляется на основании данных, находящихся в реальных таблицах. Изменение данных в реальной таблице БД немедленно отражается в содержимом всех представлений, построенных на основании этой таблицы.

Способ создания и содержимое представлений

Типичным способом создания представлений для СУБД, поддерживающих язык запросов SQL, является связывание представления с определённым SQL-запросом. Соответственно, содержимое представления — это результат выполнения этого запроса, а возможности построения представления ограничиваются только степенью сложности диалекта SQL, поддерживаемого конкретной СУБД. Так, для типичных СУБД, таких как PostgreSQL, Interbase, Microsoft SQL Server, Oracle, представление может содержать:

• подмножество записей из таблицы БД, отвечающее определённым условиям (например, при наличии одной таблицы «Люди» можно создать два представления «Мужчины» и «Женщины», в каждом из которых будут записи только о людях соответствующего пола);

• подмножество столбцов таблицы БД, требуемое программой (например, из реальной таблицы «Сотрудники» представление может содержать по каждому сотруднику только ФИО и табельный номер);

• результат обработки данных таблицы определёнными операциями (например, представление может содержать все данные реальной таблицы, но с приведением строк в верхний регистр и обрезанными начальными и концевыми пробелами);

• результат объединения (join) нескольких таблиц (например, при наличии таблиц «Люди», «Адреса», «Улицы», «Фирмы и организации» возможно построение представления, которое будет выглядеть как таблица, для каждого человека содержащее его личные данные, адрес места жительства, название организации, где он работает, и адрес этой организации);

• результат слияния нескольких таблиц с одинаковыми именами и типами полей, когда в представлении попадают все записи каждой из сливаемых таблиц (возможно, с исключением дублирования);

• результат группировки записей в таблице (например, при наличии таблицы «расходы» с записями по каждому платежу можно построить представление, содержащее средства, израсходованные на каждую отдельную статью расходов);

• практически любую комбинацию вышеперечисленных возможностей.