Составляющие оператора Select

Вложенные запросы.

10.1. Оператор выбора SELECT

Все запросы пользователей реализуются с помощью оператора SELECT.

Структура оператора:

SELECT [ALL/DISTINСТ] <смысл полей> (| или *) FROM<список таблиц>

[WHERE<предикат - условия выборки или соединения>]

[GROUP BY<список полей результата>]

[HAVING<предикат - для группировки>]

[ORDER BY<список полей упорядочивания>]

| - в результирующий набор включаются значения всех перечисленных атрибутов исходных отношений.

* - в результирующий набор включаются значения всех атрибутов исходных отношений.

10.2. Составляющие оператора:

10.2.1. SELECT - ключевое слово начала запроса.

ALL - означает, что в результирующий набор включаются все кортежи, удовлетворяющие условию запроса.

DISTING - в результирующий набор включаются только разные кортежи.

<список полей> (| или *) - либо мы можем указать список полей, которые должны быть в результирующей таблице, либо все атрибуты отношений удовлетворяют запросу.

10.2.2. FROM - является обязательным, задаёт перечень исходных отношений запроса.

10.2.3. WHERE - содержит условия отбора кортежей или условия соединения кортежей, задается с помощью предиката.

Предикат - это выражение с неопределенными переменными; если этим переменным придать конкретные значения, то предикат принимает значение "истина" или "ложь". С помощью предиката мы задаем условия выборки, например,

Если а = в то: а = 3, в = 3 – истина, а = 3, в = 4 – ложь.

В этом разделе могут быть использованы шесть групп предикатов:

1) предикат сравнения (>,<,<=,>=):

оценка = "отлично".

2) Between A and B - предикат-диапазон, принимает значения "истина", когда сравнимое значение попадает в сравниваемый диапазон, включает границы диапазона:

Года рождения: Between 1980 and 1990.

3) Предикат отношения к множеству:

3.1) In (множество) - предикат вхождения во множество:

Оценка IN ("отлично", "хорошо").

Истина - если атрибут принимает значение "отлично" или "хорошо".

3.2) NOT IN (множество) - предикат непопадания во множество.

4) IS NULL - предикат сравнения с неопределенным значением. Истина - если значение атрибута не определено.

4.1) логическое сложение:

NOT NULL = NULL;

TRUE U NULL = TRUE;

NULL U NULL = NULL.

4.2) логическое умножение:

TRUE ∩ NULL = NULL.

5) предикат сравнения с образцами:

5.1) LIKE (образец)

Истина - если значение сравниваемого атрибута совпадает с заданным образцом.

5.2) NOT LIKE (образец)

Истина - если значение сравниваемого атрибута не совпадает с заданным образцом.

6) EXIST - предикат существования.

Итак, с помощью WHERE мы формируем выборку данных с большим набором условий.

10.2.3. GROUP BY - раздел задает список полей для группировки.

Кортежи будут группироваться по значениям какого-либо атрибута (нескольких). Кроме того, с помощью этого раздела можно задать дополнительные условия.

10.2.4. HAVING - раздел содержит предикат условий для каждой группы.

10.2.5. ORDER BY - позволяет упорядочить последовательность вывода кортежей по какому-то атрибуту.

ORDER BY <"Фамилия">- кортежи "Фамилия" будут располагаться по алфавиту.

10.3. Вложенные запросы

Внутри оператора SELECT может осуществляться ещё (не один) запрос:

Пусть требуется узнать поставщиков помидоров, являющихся поставляемым продуктом с каким-то номером. Для этого можно дать запрос:

SELECT Название, Статус

FROM Поставщики

WHERE ПС IN

( SELECT ПС

FROM Поставки

WHERE ПР IN

( SELECT ПР

FROM Продукты

WHERE Продукт = 'Помидоры' ));

В данном случае результатом самого внутреннего подзапроса является только одно значение. Подзапрос следующего уровня в свою очередь дает в результате множество. Последний, самый внешний SELECT, вычисляет окончательный результат. Вообще допускается любая глубина вложенности подзапросов.

Тот же результат можно получить с помощью соединения:

SELECT Название, Статус

FROM Поставщики, Поставки, Продукты

WHERE Поставщики.ПС = Поставки.ПС

AND Поставки.ПР = Продукты.ПР

AND Продукт = 'Помидоры';

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

Лекция 11. Модель бинарных ассоциаций.

Отношение ассоциации.

Бинарная ассоциация.

Исключающая ассоциация.

11.1. Отношение ассоциации

Ассоциация (association) - семантическое отношение между двумя и более классами, которое специфицирует характер связи между соответствующими экземплярами этих классов.

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

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

11.2. Бинарная ассоциация

Наиболее простой случай данного отношения - бинарная ассоциация (binary association), которая служит для представления произвольного отношения между двумя классами. Она связывает в точности два различных класса и может быть ненаправленным (симметричным) или направленным отношением. Частный случай бинарной ассоциации - рефлексивная ассоциация, которая связывает класс с самим собой. Существует 2 типа бинарных ассоциаций:

- Ненаправленная бинарная ассоциация

- Направленная бинарная ассоциация

11.2.1. Ненаправленная бинарная ассоциация

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

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

Рис.11.1. Графическое изображение ненаправленной бинарной ассоциации между классами.

11.2.2. Направленная бинарная ассоциация

Направленная бинарная ассоциация изображается сплошной линией с простой стрелкой на одной из её концевых точек. Направление этой стрелки указывает на то, какой класс является первым, а какой – вторым.

В качестве простого примера направленной бинарной ассоциации можно рассмотреть отношение между двумя классами - классом Клиент и классом Счет. Они связаны между собой бинарной ассоциацией с именем «Имеет», для которой определен порядок следования классов. Это означает, что конкретный объект класса Клиент всегда должен указываться первым при рассмотрении взаимосвязи с объектом класса Счет. Другими словами, эти объекты классов образуют кортеж элементов, например, <клиент, счет_1, счет_2,…, счет_n>.

Рис.11.2. Графическое изображение направленной бинарной ассоциации между классами.

11.3. Исключающая ассоциация

Частный случай отношения ассоциации - так называемая исключающая ассоциация (Xor-association). Семантика данной ассоциации указывает на то, что из нескольких потенциально возможных вариантов данной ассоциации в каждый момент времени может использоваться только один. На диаграмме классов исключающая ассоциация изображается пунктирной линией, соединяющей две и более ассоциации, рядом с которой записывается ограничение в форме строки текста в фигурных скобках: {xor}.

Рис.11.3. Графическое изображение исключающей ассоциации между тремя классами.

Тернарная ассоциация связывает отношением три класса. Ассоциация более высокой арности называется n-арной ассоциацией. n-арная ассоциация (n-ary association) - ассоциация между тремя и большим числом классов.

Лекция 12. Системы управления базами данных.

Функции СУБД.

Типовая организация СУБД.

System R.

12.1. Функции СУБД

Как было показано во второй лекции, традиционных возможностей файловых систем оказывается недостаточно для построения даже простых Информационных Систем. Мы выявили несколько потребностей, которые не покрываются возможностями Систем Управления Файлами. Можно считать, что если прикладная Информационная Система опирается на некоторую систему управления данными, обладающую описанными (во второй лекции) свойствами, то эта система управления данными является системой управления базами данных (СУБД). Более точно, к числу функций СУБД принято относить следующие:

12.1.1. Непосредственное управление данными во внешней памяти

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

12.1.2. Управление буферами оперативной памяти

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

Существует отдельное направление СУБД, которое ориентировано на постоянное присутствие в оперативной памяти всей БД.

12.1.3. Управление транзакциями

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

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

12.1.4. Журнализация

Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), и жёсткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев могут быть: аварийное завершение работы СУБД (по причине ошибки в программе или в результате некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершённой. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции.

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

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

Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадёт во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

12.1.5. Поддержка языков БД

Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от её создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language). Перечислим основные функции реляционной СУБД, поддерживаемые на "языковом" уровне:

Прежде всего, язык SQL сочетает средства SDL(язык определения схемы) и DML (язык манипулирования данными), т.е. позволяет определять схему реляционной БД и манипулировать данными. При этом именование объектов БД (для реляционной БД - именование таблиц и их столбцов) поддерживается на языковом уровне в том смысле, что компилятор языка SQL производит преобразование имён объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов. Внутренняя часть СУБД (ядро) вообще не работает с именами таблиц и их столбцов.

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

Специальные операторы языка SQL позволяют определять так называемые представления БД, фактически являющиеся хранимыми в БД запросами (результатом любого запроса к реляционной БД является отношение, представленное в виде таблицы) с именованными столбцами. Для пользователя представление является такой же таблицей, как любая базовая таблица, хранимая в БД, но с помощью представлений можно ограничить или наоборот расширить видимость БД для конкретного пользователя. Поддержание представлений производится также на языковом уровне.

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

12.2. Типовая организация современной СУБД

Естественно, организация типичной СУБД и состав её компонентов соответствует рассмотренному нами набору функций. Напомним, что мы выделили следующие основные функции СУБД:

· управление данными во внешней памяти;

· управление буферами оперативной памяти;

· управление транзакциями;

· журнализация и восстановление БД после сбоев;

· поддержание языков БД.

Логически в современной реляционной СУБД можно выделить наиболее внутреннюю часть - ядро СУБД (часто его называют Data Base Engine), компилятор языка БД (обычно SQL), подсистему поддержки времени выполнения, набор утилит. В некоторых системах эти части выделяются явно, в других - нет, но логически такое разделение можно провести во всех СУБД.

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

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

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

12.3. System R – пример СУБД

Основными целями разработчиков System R являлись следующие:

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

· обеспечить многообразие допустимых способов использования СУБД, включая программируемые транзакции, диалоговые транзакции и генерацию отчетов;

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

· обеспечить возможность параллельной работы с одной базой данных многих пользователей с допущением параллельной модификации объектов базы данных при наличии необходимых средств защиты целостности базы данных;

· обеспечить средства восстановления согласованного состояния баз данных после разного рода сбоев аппаратуры или программного обеспечения;

· обеспечить гибкий механизм, позволяющий определять различные представления хранимых данных, и ограничивать этими представлениями доступ пользователей к базе данных по выборке и модификации на основе механизма авторизации;

· обеспечить производительность системы при выполнении упомянутых функций, сопоставимую с производительностью существующих СУБД низкого уровня.

Структурная организация System R вполне согласуется с поставленными при ее разработке целями. Основными структурными компонентами System Rявляются система управления реляционной памятью (Relational Storage System - RSS) и компилятор запросов языка SQL. RSS обеспечивает интерфейс довольно низкого, но достаточного для реализации SQL уровня для доступа к хранимым в базе данным. Синхронизация транзакций, журнализация изменений и восстановление баз данных после сбоев также относятся к числу функций RSS. Компилятор запросов использует интерфейс RSS для доступа к разнообразной справочной информации (каталогам отношений, индексов, прав доступа, условий целостности, условных воздействий и т.д.) и производит рабочие программы, выполняемые в дальнейшем также с использованием интерфейса RSS. Таким образом, система естественно разделяется на два уровня – уровень управления памятью и синхронизацией, фактически, не зависящий от базового языка запросов системы, и языковой уровень (уровень SQL), на котором решается большинство проблем System R.

Лекция 13. Архитектура «Клиент-Сервер».

Открытые системы.