Каноническое – неизбыточное покрытие, состоящее из полной ФЗ, правая часть которой содержит только один атрибут. Канонические покрытия выполняют вспомогательную роль, при получении минимального покрытия и неизбыточного. Декомпозицию на таком покрытии не производят. Алгоритм получения:

• применяя аксиомы проективности, все ФЗ приводят к виду «XA»;

• из полученного множества удаляются все избыточные ФЗ;

• в оставшихся ФЗ, удаляются все избыточные атрибуты.

Т.о., вновь полученное множество ФЗ, становится редуцированным.

Пример: F5 = {ABCD, ACBE, AC, CDK}

F6 = {AC, AD, AB, CDK} – каноническое покрытие.

5. Оптимальное – покрытие, для которого не существует эквивалентного ему множества с еще меньшим числом вхождений атрибутных символов.

F7 = {ABCD, ABE, EAB}. (10 симв);

Оптимальное: F8 = { ECD, ABE, EAB} (9 симв)

6. Кольцевое – используется в качестве основания для декомпозиции на минимальном покрытии ФЗ с эквивалентными левыми частями. Множество ФЗ называется кольцевым покрытием множества F, если оно эквивалентно ему и представлено виде комплексных ФЗ. Например, для множества F9 = {AB, BA, BC, CD} кольцевое покрытие будет иметь вид: G1 = {(A; B) C; (C) D}. Кольцевые покрытия могут быть: неизбыточными, минимальными, редуцированными, оптимальными.

F= {A->BDC, B->ACE}. G={(B)->ACE, (A)->BCD} - неизб, G={(B)->AE, (A)->BCD} - редуцир,

G={(B, A)-> CE, D} – мин-но.

7. Проблемы декомпозиции на минимальном покрытии. Теорема Хеза.

Проблема возникает тогда, когда отношение имеет несколько ключей. Например, отношение R = {A,B,C} и множество ФЗ на этой схеме F = {ABC, CB}. Возможные ключи AB и AC, при этом AC не детерминант. В отношении наблюдается аномалия, обусловленная тем, что атрибут B, являясь основным атрибутом зависит от собственного подмножества второго ключа AC, т.е. исходное отношение не находится во 2НФ. Традиционное выделение в отдельное отношение ФЗ не позволяет решить проблему – появляется новое отношение, со схемой R={C,B}, но при этом сохраняется исходное отн-ние, что приводит к “абсурду” (избыточность и внедрение дополнительных механизмов, поддерживающих это избыточность). Решить проблему можно исп-я теорему Хеза. Пусть дано отн-ние со схемой: R = {A,B,C} и мн-вом ФЗ на этой схеме F = {ABC, CB}. Декомпозиция без потерь будет сост-ть из 2 отн-ний: R1 = {CA} и R2 = {CB}. Остается потерянной зависимость ABC, поддерживаем программным путем.

8. Ключи. Неопределенность значений атрибутов в ключах.

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

Из определения следует - ключ отношения должен отвечать следующим требованиям: идентифицировать кортеж; не содержать "лишних" атрибутов.

Одно отношение может иметь несколько ключей. Ключ может состоять как из одного атрибута, так и нескольких (составной ключ).

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

Когда невозможно найти идентификатор, отвечающий этим требованиям, вводится суррогатный ключ, значение которого является внутренним делом системы.

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

R(Студент) = {№ зачетки, Фамилия, Имя, Отчество, …}

R(Успеваемость) = {№ зачетки, Название предмета, Название вида отчетности, Оценка}

Внешний ключ - № зачетки.

Отношение, содержащее внешний ключ, называется ссылающимся отношением (Успеваемость). Отношение, содержащее первичный ключ, адекватный внешнему ключу другого отношения, называется ссылочным отношением (Студент).

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

Недопустимо, чтобы атрибуты, входящие в первичный или внешний ключ принимали NULL значения. Если в каком-то кортеже отсутствуют данные о значении атрибута, то говорят, что его значение NULL (не определено, неизвестно, неприемлемо для данного кортежа). Определитель NULL следует воспринимать как логическую величину «неизвестно». Т.е. либо это значение не входит в область определения некоторого кортежа, либо никакое значение еще не задано. Ключевое слово NULL представляет собой способ обработки неполных или необычных данных. Значение NULL не эквивалентно не нулевому численному значению, не пустой строке. Для избежания NULL значений в первичном и внешнем ключах целесообразно вводить суррогатный ключ.

Понятие супреключа. Суперключ - содерж внутри себя подмнож-во атр, однозн-но идентиф кортеж отнош-я. Суперключ – не ключ.

9. Нормальные формы. Общая классификация. Пример построения.

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

1НФ: отнош-е нах-ся в 1НФ, если все знач-я его атрибутов атомарны. Понятие атомарности условно. Атомарность или огранич-ие на атомарность устан-ся исходя из анализа информац-го обесп-я системы и структуры вых-ой документации (если никогда не возникнет необх-ть выводить отдельно фам-ю, имя и отч-во, то мож. принять, что ФИО атомарно). При приведении к атомарному значению необходимо следить, чтобы не был утерян смысл атрибутов.

2НФ: отношение находится во 2НФ, если оно находится в 1НФ, и каждый его неосновной атрибут функционально полно зависит от возможного ключа, т.е. не зависит ни от какого его сомножества. Если ключ отношения состоит из одного атрибута, то оно всегда находится во 2НФ. Однако 2НФ не освобождает от избыточного дублирования. Пример: R={ABCD}, F={AB→D, A→ C}. Анализ: D функционально полно зависит от ключа, C – нет, т.е. отношение не находится во 2НФ. Здесь целесообразно вторую ФЗ вынести в отдельное отношение: R1={ABD} и R2={AC}. Оба отношения нормализованы до 2НФ.

3НФ: отнош-е нах-ся в 3НФ, если оно нах-ся во 2НФ, и каждый неосновной атрибут его схемы нетранзит-но зависит от возм-го ключа (т.е. напрямую). Пример: R={ABC}, F={A→B, B→C}. Декомп-ся на R^/={AB}, R^//={BC}. 3НФ неадекв: отнош-е им 2 и более потенц ключа, эти потенц ключи явл составн, 2 и более потенц ключа перекр-ся (им общ атрибут).

Декомпозиция до 2НФ и 3НФ осуществляется на минимальном покрытии путем последовательного выделения в отдельное отношение крайних ФЗ, т.е. ФЗ, правая часть которых в исходном отношении не является детерминантом другой ФЗ. Во многих случаях, приводя отношение ко 2НФ, можно получить сразу 3НФ.

НФБК (Нормальная форма Бойса-Кодда): отношение находится в НФБК, если оно находится в 1НФ и каждый детерминант является возможным ключом (или ключом является вся схема отношения). Методы декомпозиции до НФБК: декомпозиция до НФБК осуществляется на минимальном покрытии. В исходном отношении выявляется множество возможных ключей и детерминант. Если выясняется, что эти два множества неэквивалентны, то в отдельное отношение выделяется крайняя ФЗ. Если после этого множества детерминантов и ключей оказываются эквивалентными, то декомпозиция заканчивается. В противном случае, продолжается выделение ФЗ пошагово, по одной на каждом шаге. Любая декомпозиция прошла успешно, если все ФЗ, имеющиеся в исходной БД были сохранены в новом проекте, т.е. говорят, что все ФЗ навязаны БД. Пример: R={ABC} F={A→B, B→C}. Декомпозируется на 2 отношения: R={AB}, R={BC}. Все ФЗ, имеющие место в исходном отношении сохранены: F^/={A→B}, F^//={B→C}.

10. Практическая значимость понятий: замыкания фз, замыкание атрибутов.

Понятие ФЗ: ФЗ определяют однозначное соответствие м/у значениями атрибутов. ПР2: ТАБ_№→ФИО, ТАБ_№→квалификация

Множество ФЗ, которое не может быть дополнено ни одной новой ФЗ с помощью аксиом рефлексивности, пополнения и псевдотранзитивности, называется замыканием множества ФЗ и обозначается F+.

Для получения замыкания F⁺ используются аксиомы Армстронга. Эти аксиомы могут быть использованы для практического вычисления замыкания, т.к. эти правила являются полными (для заданного множества ФЗ F минимальный набор ФЗ, которые подразумевают все зависимости из множества F, может быть выведен из ФЗ множества F на основе этих правил) и исчерпывающими (никакие ФЗ, которые не подразумеваются ФЗ множества F, с их помощью не могут быть выведены).

Практическая значимость замыкания ФЗ – используется для доказательства эквивалентности покрытий, но применяется редко из-за проблем временного характера.

Замыкание множества атрибутов {A1, A2, …, An} на схеме R есть полное множество атрибутов, принадлежащих схеме R и функционально зависящих от A1, A2, …, An. Обозначается замыкание как {A₁,A₂,…,A_n}⁺.

Два множества ФЗ эквивалентны, если имеют одно и тоже замыкание множеств ФЗ (если кажд ФЗ в F мож получ из F’). F={X->YZ, X->Y, X->Z} F’={X->Y, X->Z}

Два множества атрибутов (принадлежат одному классу эквивалентности) эквивалентны, если они имеют одинаковое замыкание.

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

Пусть дано множество функциональных зависимостей F={AB, BC} , на схеме R={ABC} отношения r. Докажем, что ключом данного отношения будет атрибут А. С этой целью построим замыкания для всех атрибутов левых частей ФЗ:

AA	1		BB	1
AB	Дано		BC	Дано
AAB	2		BBC	2
BC	Дано
AABC	2

Т.о., атрибут А является ключом отношения, т.к. от него функционально зависят все атрибуты схемы отношения. Замыканием множеств AB, AC, ABC тоже будет вся схема отношения, но они не будут явл-ся ключами, т.к. содержат внутри себя ключи.

11. Формализация реляционной базы данных.

Реляционная база данных (БД) – это совокупность отношений. Отношением называется таблица, которая обладает следующими свойствами:

• все элементы каждого ее столбца имеют одинаковую природу;

• каждый столбец имеет уникальное имя;

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

• информативность таблицы не зависит от порядка расположения строк или столбцов.

Строки отношения называются кортежами. Каждый столбец отношения имеет уникальное имя, которое называется наименованием атрибута или просто атрибутом. Множество допустимых значений атрибута образует домен атрибута, который обозначается как dom (н-р, домен атрибута А – dom(A)), а множество допустимых значений всех атрибутов отношения - домен отношения (обозначается буквой D). Количество атрибутов в отношении, как правило, остается неизменным в течение жизни БД и называется степенью отношения. Количество кортежей определяет мощность отношения (кардинальное число), которая в свою очередь постоянно изменяется во времени.

Кортеж t={a₁, a₂, …, a_n} есть отображ-е из схемы отнош-я в домен отнош-я D такое, что a₁ є d₁, a₂ є d₂, …, a_n є d_n.

Отношение есть множ-во отбражений из схемы отнош-я в домен отнош-я D такое, что a₁ є d₁, a₂ є d₂, …, a_n є d_n.

Реляционные базы данных составляют основу оперативных хранилищ информации, где над данными осуществляется 3 операции: добавление, правка, удаление. Декомпозиция обусловлена проблемами, которые возникают при выполнении этих операций.

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

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

12. ЕR – модель. Генерация отношений.

Диаграммы "сущность-связь" (Entity-Relationship) предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними. Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей). Первый вариант модели сущность-связь был предложен Ченом. В дальнейшем многими авторами были разработаны свои варианты подобных моделей (нотация Мартина, IDEF1X, нотация Баркера и др.).

ER-диаграммамы с позиции нотации Чена.

Сущность - класс однотипных объектов, информация о которых должна быть учтена в модели. Каждая сущность имеет наименование, выраженное существительным в единственном числе. Каждая сущность в модели изображается в виде прямоугольника с наименованием. Экземпляр сущности - конкретный представитель данной сущности. Н-р, представитель сущности "Игрок" - "Игрок Иванов". Экземпляры сущностей должны быть различимы, т.е. сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности. Атрибут сущности - именованная характеристика, являющаяся некоторым свойством сущности. Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными). Ключ сущности - неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности. Неизбыточность заключается в том, что удалением любого атрибута из ключа нарушается его уникальность. Сущность может иметь несколько различных ключей. Ключевые атрибуты изображаются на диаграмме подчеркиванием. Связь - некоторая ассоциация между двумя сущностями. Одна сущность может быть связана с другой сущностью или сама с собою. Связи позволяют по одной сущности находить другие сущности, связанные с нею. Графически изображается линией, соединяющей две сущности. Наименование обычно выражается в неопределенной глагольной форме: "иметь", "принадлежать". Каждое из наименований относится к своему концу связи. Иногда наименования не пишутся ввиду их очевидности. Каждая связь может иметь один из следующих типов связи:

Связь типа «1:1» означает, что один экземпляр первой сущности связан с одним экземпляром второй сущности. Связь «1:1» чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две. Связь типа «1:n» означает, что один экземпляр первой сущности связан с несколькими экземплярами второй сущности. Это наиболее часто используемый тип связи. Сущность со стороны "1" называется родительской, со стороны "n" - дочерней. Связь типа «n:m» означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи «n:m» является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа «1:n» путем создания промежуточной сущности.

Каждая связь может иметь одну из двух модальностей связи:

• "может" - экземпляр одной сущности может быть связан с одним или несколькими экземплярами другой сущности, а может быть и не связан ни с одним экземпляром.

• "должен" - экземпляр одной сущности обязан быть связан не менее чем с одним экземпляром другой сущности.

Связь может иметь разную модальность с разных концов.

Правила генерации:

Правило 1: при степени связи 1:1 и обязательном классе принадлежности обеих сущностей формируется одно отношение, куда в качестве обязательных атрибутов входят атрибуты обеих сущностей, при этом ключом отношения может быть ключ любой из сущностей.

R(препод-дисципина) = {Таб. №, ФИО, название дисциплины}

Правило 2: При степени связи 1:1 и необязательном классе принадлежности одной из сущностей формируется 2 отношения по одному на каждую сущность, при этом в отношении соответствующее сущности с обязательным классом принадлежности в качестве обязательного атрибута входит ключ сущности с необязательным классом принадлежности. Ключом вновь сформированного отношения может быть ключ любой из сущности.

R(препод) = {таб №, ФИО, разряд, название дисциплины}

R(дисциплина) = {название дисциплины, вид контроля}

Правило 3: при степени связи 1:1 и необязательном классе принадлежности обеих сущностей формируется три отношения по одному на каждую сущность + отношение связи. В отношение связи в качестве обязательных атрибутов входят ключи обеих сущностей, которые будут ключом отнош-я связи.

Правило 4: при 1:n, должен-должен и при степени связи 1:n и обязательном классе принадлежности n-связной сущности формируется 2 отношения, при этом в отношение соответствующее n-связной сущности в качестве обязательного атрибута войдет ключ односвязной сущности. Ключом этого отношения будет ключ n-связной сущности.

R(препод) = {таб №, ФИО, разряд, название дисциплины}

R(дисциплина) = {название дисциплины, вид контроля}

Правило 5: при 1:n может-может и при степени связи 1:n и необязательном классе принадлежности n-связной сущности формируется 3 отношения по одному на каждую сущность + отношение связи, куда в качестве обязательного атрибута входят ключи обеих сущностей, ключом отношения будет ключ n-связной сущности.

R(препод) ={таб №, фио, разряд}

R(дисципина) = {название дисциплины, вид отчетности}

R(читать) = {таб №, название дисциплины}

Обоснуем данное правило: следуя правилу у нас получилось 2 отношения с одинаковым ключом, но в данном случае объединение данных отношений будет не верно, т.к. модальность связи в данном отношении “может”, следовательно при объединении отношений получиться что какому-то атрибуту отношения может не соответствовать значение, т.е. будут присутствовать NULL поля. Чтобы этого избежать и вводится 3 сущность, которая позволяет избежать неопределенности.

П равило 6: при степени связи m:n независимо от класса принадлежности обеих сущностей формируется 3 отношения по одному на каждую сущность + отношение связи (слаб сущ-ть), куда в качестве обязательных атрибутов входят ключи обеих сущностей, ключом данного отношения будут ключи обеих сущностей. Связь m:n преобр-ся в две связи 1:n, мод-ть «должен»

R(препод) = {таб №, фио, разряд}

R(дисциплина) = {название дисциплины, вид отчетности}

R(читать) = {таб №, название дисциплины}

13. Трёхуровневая архитектура ansi-sparc.

Выделяются 3 уровня абстракции, т.е. 3 различных уровня описания элементов данных. Эти уровни формируют трехуровневую архитектуру, которая охватывает внешний, концептуальный и внутренний уровни.

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

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

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

3. Администратор базы данных (АБД) должен иметь возможность изменять структуру хранения данных в базе, не оказывая влияния на пользовательские представления.

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

5. АБД должен иметь возможность изменять концептуальную или глобальную структуру БД без какого-либо влияния на всех пользователей.

Внешний уровень – представление БД с т.з. пользователей. Этот уровень описывает ту часть БД, которая относится к каждому пользователю. Внешний уровень состоит из нескольких различных внешних представлений БД. Каждый пользователь имеет дело с представлением “реального мира”, выраженным в наиболее удобной для него форме. Внешнее представление содержит только те сущности, атрибуты и связи “реального мира”, которые интересны пользователю.

Концептуальный уровень – обобщающее представление данных. Этот уровень описывает то, какие данные хранятся в БД, а также связи, существующие между ними, т.е. логическую структуру всей БД. Фактически это полное представление требований, которое не зависит от любых соображений относительно способа их хранения. На концептуальном уровне представлены следующие компоненты: все сущности, их атрибуты, связи; накладываемые на данные ограничения; семантическая информация о данных; информация о мерах обеспечения безопасности и поддержки целостности данных. Однако этот уровень не содержит никаких сведений о методах хранения данных (например, объем занятого пространства в байтах).

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

На внутреннем уровне хранится следующая информация:

• Распределение дискового пространства для хранения данных и индексов;

• Описание подробностей сохранения записей (с указанием реальных размеров сохраняемых элементов данных);

• Сведения о размещении записей;

• Сведения о сжатии данных и выбранных методах шифрования.

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

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

Основным назначением трехуровневой архитектуры является обеспечение независимости данных, которая означает, что изменения на нижних уровнях никак не влияют на верхние уровни. Различают два типа независимости от данных: логическую и физическую.

Логическая независимость от данных – означает полную защищенность внешних схем от изменений, вносимых в концептуальную схему (например, добавление или удаление новых сущностей, атрибутов или связей).

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

14. Функции и компоненты субд.

СУБД – ПО, с помощью которого пользователи могут определять, создавать и поддерживать БД, а также осуществлять к ней контролируемый доступ.

Функции СУБД (первые 8 предложены Коддом – сервисы, которые должны быть реализованы в любой полномасштабной СУБД; остальные 2 – добавлены Коннолли):

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

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

Преимущества применения системного каталога: 1) информация о данных может быть централизованно собрана и сохранена, что позволит контролировать доступ к этим данным, как и к любому другому ресурсу; 2) можно определить смысл данных, что поможет другим пользователям понять их предназначение; 3) упрощается сообщение, т.к. сохраняются точные определения смысла данных; 4) благодаря централизованному хранению избыточность и противоречивость описания отдельных элементов могут быть легко обнаружены; 5) внесенные в БД изменения могут быть запротоколированы; 6) последствия любых изменений могут быть определены еще до их внесения; 7) меры обеспечения безопасности могут быть дополнительно усилены; 8) появляются новые возможности организации поддержки целостности данных; 9) может выполняться аудит сохраняемой информации.

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

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

5. Сервисы восстановления. СУБД должна предоставлять средства восстановления БД на случай какого-либо ее повреждения или разрушения.

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

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

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

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

10. Вспомогательные службы. Вспомогательные утилиты обычно предназначены для оказания помощи администратору БД в эффективном администрировании БД. Примеры подобных утилит: 1) утилиты импортирования - для загрузки БД из плоских файлов и утилиты экспортирования для выгрузки БД в плоские файлы; 2) средства мониторинга - отслеживание характеристик функционирования и использования БД; 3) программы статистического анализа - оценка производительности или степени использования БД; 4) инструменты реорганизации индексов - для перестройки индексов и обработки случаев их переполнения; 5) инструменты сборки мусора и перераспределения памяти для физического устранения удаленных записей с запоминающих устройств, объединения освобожденного пространства и перераспределения памяти в случае необходимости.

Компоненты СУБД (основные программные компоненты среды СУБД представлены на рисунке).

1. Процессор запросов. Основной компонент СУБД, который преобразует запросы в последовательность низкоуровневых инструкций для контроллера БД

2. Контроллер БД. Взаимодействует с запущенными пользователем прикладными программами и запросами. Принимает запросы и проверяет внешние и концептуальные схемы для определения тех концептуальных записей, которые необходимы для удовлетворения требований запроса. Затем вызывает контроллер файлов для выполнения поступившего запроса.

3. Контроллер файлов. Манипулирует предназначенными для хранения данных файлами и отвечает за распределение доступного дискового пространства. Создает и поддерживает список структур и индексов, определенных во внутренней схеме. Не управляет физическим вводом и выводом данных непосредственно, а передает запросы соответствующим методам доступа.

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

5. Компилятор языка DDL. Преобразует DDL-команды в набор таблиц, содержащих метаданные. Затем эти таблицы сохраняются в системном каталоге, а управляющая информация – в заголовках файлов с данными.

6. Контроллер словаря. Управляет доступом к системному каталогу и обеспечивает работу с ним. Системный каталог доступен большинству компонентов СУБД.

15. Архитектуры многопользовательских субд.

Типовые архитектурные решения, используемые при реализации многопользовательских СУБД – телеобработка, файловый сервер и технология «клиент-сервер».

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

2. Файловый сервер

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

1. Технология «клиент-сервер»

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

Преимущества: 1) более широкий доступ к существующим БД; 2) повышение общей производительности системы (из-за нахождения клиентов и сервера на разных компьютерах их процессоры способны выполнять приложения параллельно); 3) снижение стоимости аппаратного обеспечения (мощный компьютер необходим только серверу для хранения и управления БД); 4) сокращение коммуникационных расходов (приложения выполняют часть операций на клиентских машинах и посылают через сеть только запросы к БД); 5) повышение уровня непротиворечивости данных (сервер может самостоятельно управлять проверкой целостности данных, каждому приложению не придется выполнять собственную проверку); 6) данная архитектура естественно отображается на архитектуру открытых систем.

Двухуровневая архитектура «клиент/сервер» может быть расширена до трехуровневой, при которой функциональная часть прежнего, толстого (интеллектуального) клиента разделяется на две части. В трехуровневой архитектуре тонкий (неинтеллектуальный) клиент на рабочей станции управляет только пользовательским интерфейсом, а средний уровень обработки данных управляет всей остальной логикой приложения. Третий уровень – сервер БД.

16. Составные части языка sql и основные операторы.

SQL является примером языка предназначенного для работы с таблицами с целью преобразования входных данных к требуемому выходному виду. Язык SQL имеет два основных компонента:

язык DDL (Data Definition Language) - предназначенный для определения БД:

CREATE – создание таблицы;

CREATE TABLE [<имя базы данных>.[<имя владельца>] <имя таблицы>

({<имя столбца> <тип данных> (<размер>) [<ограничение для столбца>]}

[,…n])

[,<ограничение для таблицы>];

CREATE VIEW <имя представления>

[(<имя столбца> [,…n ])

[WITH {ENCRYPTION | SCHEMABINDING | VIEW_METADATA}]

AS

< команда SELECT>

[WITH CHECK OPTION];

DROP – удаление таблицы;

ALTER – внесение изменений в описание таблицы, в т.ч.: добавление и изменение столбцов; добавление, разрешение, запрет и удаление ограничений.

ALTER TABLE <имя таблицы>

[WITH CHECK| WITH NOCHECK]

ALTER| ADD| DROP {CONSTRAINT <имя ограничения>}

FOREIGN KEY [REFERENCES<имя таблицы> (<имя столбца> [,…n])] | PRIMARY KEY | UNIQUE | CHECK (<имя столбца> [,…n])}

[ON DELETE CASCADE]

язык DML (Data Manipulation Language) - для выборки и обновления данных:

INSERT – ввод новых строк в таблицу;

INSERT INTO {<имя таблицы>[(<имя столбца> [псевдоним] [, …n]] |[<подзапрос>]}

VALUES (<значение>[,…n]);

DELETE – удаление строк из таблицы;

DELETE FROM{<имя таблицы>

WHERE <условие>};

UPDATE – редактирование данных в таблице;

UPDATE {<имя таблицы>

[SET (<имя столбца>)] = <выражение> [,…n]|<подзапрос>]

WHERE <условие>};

SELECT – оператор выбора - спорный оператор (можно выделить в отдельную группу).

17. Реализация запросов средствами sql (хранимые процедуры, функции, представления).

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

SELECT [DISTINCT] *|<столбец> [<псевдоним>]

[,<групповая функция>] [,…n]

FROM <таблица>[, …n]| (<подзапрос>)

[WHERE <условие>]

[GROUP BY<выражение группировки>]

[HAVING <условие отбора группы>]

[ORDER BY < столбец >[,…n]]

Ключевое слово DISTINCT используется для возвращения запросом только уникальных строк. При необходимости вывести все записи из отношения используется команда SELECT *. SELECT устанавливает, какие столбцы должны присутствовать в выходных данных. FROM определяет имена используемой таблицы или нескольких таблиц. WHERE выполняет фильтрации строк объекта в соответствии с заданными условиями. GROUP BY образ-ся группы строк, имеющих одно и то же значение в указанном столбце. HAVING фильтрует группы строк объекта в соответствии с указанным условием. ORDER BY определяет упорядоченность результатов выполнения оператора. Порядок предложений и фраз в операторе SELECТ не может быть изменен. Только предложения SELECT и FROM являются обязательными, все остальные предложения и фразы могут быть опущены. Операция SELECT является закрытой, т.е. результат запроса к таблице представляет собой др. таблицу. Пример запроса: вывести названия всех предметов, по которым сред. оценка меньше 4.

SELECT Name_Subject, AVG(Mark)

FROM Progress Pr, Subject S

WHERE Pr.Code_Subject=S.Code_Subject

GROUP BY Name_Subject

HAVING AVG(Mark)<4

Стандарт ISO содержит определение 5 обобщающих функций: COUNT возвращает количество значений в указанном столбце. Функция COUNT() с аргументом отличным от *, игнорирует строки с признаком NULL, в то время как функция вида COUNT(*) посчитает все строки, в том числе и строки, в которых есть атрибуты с признаком NULL.

. SUM возвращает сумму значений в указанном столбце. AVG возвращает усредненное значение в указанном столбце. MIN возвращает минимальное значение в указанном столбце. MAX возвращает максимальное значение в указанном столбце.

Запрос, в котором присутствует фраза GROUP BY называется группирующим запросом; столбцы, перечисленные в данной фразе называются группируемыми столбцами. Все имена столбцов, приведенные в предложении SELECT, должны присутствовать и во фразе GROUP BY. За исключением случаев, когда имя столбца используется в обобщающей функции.

Предложение ORDER BY всегда ставится в конец команды SELECT. По умолчанию сортировка идет по возрастанию. Для изменения порядка сортировки используется опция DESC. При сортировке по нескольким столбцам столбцы перечисляются через запятую. ORDER BY всегда стоит в конце запроса. Пример: Вывести список имен студентов, имеющих оценки, расположив их по возрастанию имен: SELECT DISTINCT Sname ФИО

FROM Student, Progress

WHERE Student.N_record_book= Progress.N_record_book;

ORDER BY Sname

Запросы с подзапросами:

Внутрь каждого запроса может входить другой запрос, называемый подзапрос. подзапросы создаются на уровне опций: where, having, from. Порядок выполнения: сначала подзапрос, потом запрос, куда подзапрос передает свои данные. Отличие составляют коррелированные подзапросы – внеш запрос выбирает строку; вып-ся внутр запрос, используя знач-е строки внеш запроса; рез-т вып-я внутр запроса возвращ-ся во внеш запрос, где провер-ся его соотв-е выбранной строке; выбир-ся след строка внеш запроса. Коррелированный подзапрос выполняется столько раз, сколько строк-кандидатов в основном подзапросе. Пример: вывести имена студентов и их средние оценки: Select Sname, Amk.Amark

From Student, (select N_record_book, avg(mark) Amark

From Progress

Group by N_record_book) Amk

Where Student. N_record_book = Amk. N_record_book;

Вывести имена студентов, чьи оценки выше, чем средняя оценка в их группе.

SELECT DISTINCT SName,Mark FROM Student s,Progress p

WHERE S.NRecordBook=P.NRecordBook

AND Mark>(SELECT AVG(Mark) FROM Progress P1,Student S1

WHERE S1.IDGroup=S.IDGroup AND S1.NRecordBook=P1.NRecordBook)

Подзапрос (пз) помещ в кругл скобки и долж стоять в прав части опер-ра сравнения внеш запроса, пз мож обращ к табл отличн от тех, к котор обращ основн запрос, пз может задав в слож критериях поиска внеш запросов с использ логич связок AND и OR, предл ORDER BY став-ся последн в основн запросе и не может содерж в пз. В команде SELECT пз мож стоять в предл FROM, WHERE, HAVING, пз мож содерж группы и групповые функции. Имена столбцов в предл SELECT внутр запр долж стоять в той же послед-ти, что и имена столбцов в левой части опер-ра сравн-я внешнего запроса. Типы столбцов должны попарно соотв-ть. В критерии поиска могут использ-ся логич опер-ры, операторы ANY (SOME), ALL.

Выборка данных из нескольких таблиц

Синтаксис предложения FROM:

FROM <первая таблица> [[AS] <псевдоним>] <тип объединения> <вторая таблица>[[AS] <псевдоним>] [ON <условие объединения>]

Псевдоним должен быть уникален в рамках одного запроса. INNER JOIN, OUTER JOIN (LEFT – RIGHT), FULL JOIN (включ-е всех данных из соед-мых таблиц) CROSS JOIN

Объединение двух или более запросов с помощью UNION – опер-р, с помощью котор. можно из двух или более запросов постр. единое результ-щее множ-во. Осн. правила: запросы должны им. одинак. кол-во столбцов в предл SELECT; возвращ комбинир результат будет иметь заголовки столбцов первого предлож-я SELECT; тип данных каждого столбца должен быть совместим с типом данных соотв-го столбца др запроса; по умолчанию режимом вывода для UNION является DISTINCT, иначе, после оператора UNION поставить опцию ALL. Предложение ORDER BY в операциях над множествами может стоять только в последнем предложении запроса, при этом вместо имен столбцов используются их номера из предложения SELECT.

Получить все записи о студентах, фамилии которых начинаются на букву 'М' или 'И'.

SELECT NRecordBook,SName FROM Student WHERE SUBSTRING(SName,1,1)= 'М'

UNION

SELECT NRecordBook,SName FROM Student WHERE SUBSTRING¹(SName,1,1)= 'И'

18. Целостность базы данных. Средства обеспечения целостности средствами sql.

Основное из требований предъявляемых к БД – надежность хр-ния инф-ции, что в свою очередь невозможно без согласованности данных. Целостность базы – взаимная согласованность отдельных фрагментов данных и их корректность. Полагая также, что согласованность имеет место, когда все порции данных в БД единообразно смоделированы и включены в систему, а данные корректны, если они достоверны, точны и значимы, сформ-ем ниже ряд правил, к-ые позволяют поддерживать согласованность и корректность данных в БД. Сущ-ют 2 осн. правила поддержания целостности БД:

1) Целостности объектов. В частности оно задает ограничение на значения атрибутов, которые должны принадлежать определенному домену и накладывает запрет на неопределенные значения атрибутов первичного ключа отношения. Первичный ключ – минимальный идентификатор, который используется для уникальной идентификации картежа. Это значит, что никакое подмножество первичного ключа не может быть достаточным для уникальной идентификации картежей. Если допустить присутствие определителя NULL в любой части первичного ключа, это равноценно утверждению, что не все его атрибуты необходимы для уникальной идентификации картежей, что противоречит определению первичного ключа.

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

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

• Запретить удаление записи в ссылочном отношении, если в ссылающемся отношении есть кортеж, в котором значение внешнего ключа совпадает со значением первичного ключа в ссылочном отношении.

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

При выполнении операции редактирования следует:

• Запретить обновление первичного ключа записи в ссылочном отношении, если в ссылающемся отношении есть кортеж, в котором значение внешнего ключа совпадает со значением первичного ключа в ссылочном отношении.

• Выполнить каскадное редактирование. При редактировании записи в ссылочном отношении, отредактир-ть все соответствующие записи в ссылающемся отношении.

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

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

19. Индексы базы данных. Назначение, классификация.

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

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

Индексы создаются по умолчанию при создании ограничений:

первичного ключа (кластеризованный);

ограничении уникальности (Unique - некластеризованный).

Кластеризованные индексы

В кластеризованном индексе уровень листовых вершин содержит сами данные.

Поэтому для таблицы можно определить только один кластеризованный индекс.

Если индекс есть, то данные хранятся не в куче, а в строго упорядоченном индексе.

В SQL Server по умолчанию создается для первичного ключа.

Создание кластеризованного индекса:

CREATE [ UNIQUE ] CLUSTERED INDEX <Название индекса>

ON <Название таблицы>

( <Название столбца>[ ASC | DESC ]

[ ,...n ] ) или

ALTER TABLE <Название таблицы>

ADD CONSTRAINT <Название ограничения> PRIMARY KEY CLUSTERED

( <Название столбца>[ ASC | DESC ]

[ ,...n ] )

Некластеризованные индексы

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

Создание некластеризованного индекса:

CREATE [ UNIQUE ] NONCLUSTERED

INDEX <Название индекса>

ON <Название таблицы>

( <Название столбца> [ ASC | DESC ]

[ ,...n ] )

Указатель (куча). SQL Server хранит указатель в физической строке (идентификатор файла, идентификатор страницы и идентификатор строки на странице) на уровне листовых вершин некластеризованного индекса. Чтобы найти определенную строку, SQL Server выполняет поиск по индексам и переходит по указателю, чтобы извлечь строку.

Указатель (кластер. индекс)

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

Правило «хорошего тона»

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

Особенность составных индексов

Если индекс состоит из нескольких столбцов, то при построении дерева используется только первый столбец и поэтому по нему поиск будет эффективнее.

Следовательно, лучше создавать индекс по одному столбцу и обдуманно выбирать первый столбец индекса.

Покрывающие индексы

Включаются столбцы в некластеризованный индекс, поэтому нет необходимости поиска покластеризованному индексу (или куче)

CREATE INDEX <Название индекса>

ON <Название таблицы>

(<Список столбцов индекса>)

INCLUDE (<Список добавляемых столбцов>)

20. Оператор соединения в sql.

Существует несколько способов соединения таблиц, наиболее применяемый способ INNER JOIN, который также может быть реализован и с помощью предложения WHERE.

В предложении FROM должны быть указаны все таблицы, участвующие в запросе, даже если данные из той или иной таблицы не обозначены в предложении SELECT.

Операция соединения по двум отношениям (таблицам)

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

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

Формат операции:

FROM имя_таблицы_1 {INNER | LEFT | RIGHT}

JOIN имя_таблицы_2

ON условие_соединения

Существуют различные типы операций соединения:

• тета-соединение   ;

• соединение по эквивалентности   ;

• естественное соединение   ;

• внешнее соединение  ,   ;

• полусоединение  .

Операция тета-соединения

Операция тета-соединения   определяет отношение, которое содержит кортежи из декартова произведения отношений R и S, удовлетворяющие предикату F. Предикат F имеет вид  , где вместо   может быть указан один из операторов сравнения ( >, >=, <, <=, =, <> ).

Если предикат F содержит только оператор равенства ( = ), то соединение называется соединением по эквивалентности.

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

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

Блоки данных из двух таблиц объединяются, как только в указанных полях будут найдены совпадающие значения.

Если в предложении FROM перечислено несколько таблиц и при этом не употребляется спецификация JOIN, а для указания соответствия полей из таблиц используется условие в предложении WHERE, то некоторые реляционные СУБД (например, Access) оптимизируют выполнение запроса, интерпретируя его как соединение.

Если перечислять ряд таблиц или запросов и не указывать условия объединения, в качестве исходной таблицы будет выбрано декартово (прямое) произведение всех таблиц.

SELECT R.a1, R.a2, S.b1, S.b2

FROM R, S

WHERE R.a2=S.b1

или

SELECT R.a1, R.a2, S.b1, S.b2

FROM R INNER JOIN S ON R.a2=S.b1

Пример 5.4. Тета-соединение отношений в SQL. (html, txt)

Естественное соединение

Естественным соединением называется соединение по эквивалентности двух отношений R и S, выполненное по всем общим атрибутам, из результатов которого исключается по одному экземпляру каждого общего атрибута.

SELECT R.a1, R.a2, S.b2

FROM R, S

WHERE R.a2=S.b1

или

SELECT R.a1, S.b1, S.b2

FROM R INNER JOIN S ON R.a2=S.b1

Пример 5.5. Естественное соединение отношений в SQL. (html, txt)

Пример 5.6. Вывести информацию о проданных товарах.

SELECT *

FROM Сделка, Товар

WHERE Сделка.КодТовара=Товар.КодТовара

Или (что эквивалентно)

SELECT *

FROM Товар INNER JOIN Сделка

ON Товар.КодТовара=Сделка.КодТовара

Пример 5.6. Выборка информации о проданных товарах. (html, txt)

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

Какая из таблиц будет ведущей, определяет вид соединения. LEFT - левое внешнее соединение, ведущей является таблица, расположенная слева от вида соединения ;RIGHT - правое внешнее соединение, ведущая таблица расположена справа от вида соединения.

Левое внешнее соединение

Левым внешним соединением называется соединение, при котором кортежи отношения R, не имеющие совпадающих значений в общих столбцах отношения S, также включаются в результирующее отношение.

SELECT R.a1, R.a2, S.b1, S.b2

FROM R LEFT JOIN S ON R.a2=S.b1

Пример 5.9. Левое внешнее соединение отношений в SQL. (html, txt)

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

SELECT R.a1, R.a2, S.b1, S.b2

FROM R RIGHT JOIN S ON R.a2=S.b1

Пример 5.10. Правое внешнее соединение отношений в SQL. (html, txt)

Пример 5.11. Вывести информацию о всех товарах. Для проданных товаров будет указана дата сделки и количество. Для непроданных эти поля останутся пустыми.

SELECT Товар.*, Сделка.*

FROM Товар LEFT JOIN Сделка

ON Товар.КодТовара=Сделка.КодТовара;

Пример 5.11. Выборка информации о всех товарах. (html, txt)

Полусоединение

Операция полусоединения определяет отношение, содержащее те кортежи отношения R, которые входят в соединение отношений R и S .

SELECT R.a1, R.a2

FROM R, S

WHERE R.a2=S.b1

или

SELECT R.a1, R.a2

FROM R INNER JOIN S ON R.a2=S.b1

Пример 5.12. Полусоединение отношений в SQL. (html, txt)

21. Использование подзапросов, коррелированные подзапросы.

Подзапрос – это команда SELECT, вложенная в предложение другой команды SQL. Подзапрос может возвращать одну и более строк или один и более столбцов. Допускается до 255 уровней вложенности подзапросов.

Подзапросы могут использоваться в командах SELECT,UPDATE, INSERT, DELETE, CREATE TABLE.

Правила создания подзапросов:

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

• Подзапрос может обращаться к таблицам отличным от тех, к которым обращается основной запрос.

• Подзапрос может задаваться в сложных критериях поиска внешних запросов с использованием логических связок AND и OR.

• Предложение ORDER BY ставится последним в основном запросе и не может содержаться в подзапросе.

• Подзапрос может содержать группы и групповые функции.

• Имена столбцов в предложении SELECT внутреннего запроса должны стоять в той же последовательности, что и имена столбцов в левой части оператора сравнения внешнего запроса. Типы столбцов должны попарно соответствовать.

• В критерии поиска могут использоваться логические операторы, операторы ANY (SOME), ALL.

• В команде SELECT подзапрос может стоять в предложениях FROM, WHERE, HAVING.

INSERT INTO Student

SELECT NRecordBook, Sname, CodeGroup

FROM Student1;

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

SELECT Sname, Mark

FROM Student St,Progress Pr

WHERE St.NRecordBook=Pr.NRecordBook

AND mark>(SELECT AVG(mark)

FROM Progress P1, Student S1

WHERE S1.CodeGroup=St.CodeGroup AND S1.NRecordBook=P1.NRecordBook)

П оследовательность выполнения:

• Внешний запрос выбирает строку;

• Выполняется внутренний запрос, используя значение строки внешнего запроса;

• Результат выполнения внутреннего запроса возвращается во внешний запрос, где проверяется его соответствие выбранной строке;

• Выбирается следующая строка внешнего запроса.

• При задании вложенных запросов допускаются применение операторов АNY, EXIST, ALL и др. логические операторы.

22. Необходимость управления параллельностью.

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

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

Существуют три проблемы параллельности (возникающие при параллельной обработке транзакций):

1. Проблема потери результатов обновления:

Результат операции обновления, выполненной транзакцией А, будет утерян, поскольку в момент t4 он будет перезаписан транзакцией В.

2. Проблема незафиксированной зависимости (чтение “грязных” данных, неаккуратное считывание):

В данном случае транзакция А будет обрабатывать данные, которые уже не существуют (и, в сущности, никогда не существовали).

3. Проблема несовместимого анализа: включает 3 варианта: неповторяемое считывание; фиктивные элементы фантомы; собственно несовместимый анализ.

а) Неповторяемое считывание:

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

б) Фиктивные элементы фантомы:

Эффект фиктивных элементов фантомов наблюдается, когда происходит чтение нескольких строк, удовлетворяющих некоторому условию: транзакция А производит считывание строк с одним и тем же условием. Н-р, считывает результаты экзамена студентов группы ИС-01. В это время вклинивается транзакция В и вставляет или удаляет n-ое количество строк. При повторном считывании транзакция А видит другое количество строк. Транзакция А ничего не знает о существовании В и не может понять, что происходит с данными.

в) Собственно несовместимый анализ:

Транз А более длин, чем транз В, счит кол-во студ-тов. В это время транз В вклин-ся в транз А и переводит студ-та в ту группу, по котор расчёты заверш. Рез-т: транз А после заверш обнаруж, что кол-во студ меньше, чем ожид.

Т.о., рассмотренные коллизии показывают, что если не принимать определенных мер, то нарушится одно из важнейших свойств изолированности транзакций. Очевидно, что транзакции не будут мешать друг другу, если они выполняются в разное время и работают с разными данными. Конфл: W-W (потеря обновл), R-W (неповтор счит-е), W-R (чтен-е грязн данных)

23. Транзакция и её свойства.

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

Любая транзакция всегда должна переводить БД из одного согласованного состояния в другое, хотя допускается, что согласованность состояния БД будет нарушаться в ходе выполнения транзакции. Любая транзакция завершается одним из двух возможных способов. В случае успешного завершения результаты транзакции фиксируются (commit) в БД, и транзакция переходит в новое согласованное состояние. Если выполнение транзакции не прошло успешно, она отменяется, в этом случае в БД должно быть восстановлено то согласованное состояние, в котором она находилась до начала данной транзакции - откат (roll back) транзакции. Зафиксированная транзакция не может быть отменена. Если оказывается, что зафиксированная транзакция была ошибочной, потребуется выполнить другую транзакцию, отменяющую действия, выполненные первой транзакцией. В большинстве языков манипулирования данными для указания границ отдельных транзакций используются операторы BEGIN TRANSACTION, COMMIT и ROLLBACK.

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

Синтаксис осн команд:

Begin Tran [saction] [<имя транз>],

Commit Tran [saction] [<имя транз>],

RollBack Tran [saction] [<имя транз>] [<имя т сохр>],

Save Tran [saction] [<имя т сохр>]

Неявн транз – не треб наличия Begin Tran. Нач-ся с 1-го опер-ра, заканч традиц-но. Без Begin Tran кажд опер-р SQL счит-ся отд странз. Неявн начало: set implicit_transaction on. Опер-ры, инициир транз-ю: Create, insert, update, delete, trunicate, drop, open, fetch, grant, select, revoke.

24. Методы управления параллельностью.

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

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

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

Протоколом доступа к данным (или протоколом блокировки),

1) Прежде чем прочитать объект, транзакция должна наложить на него блокировку чтения (S-блокировку).

2) Прежде чем обновить объект, транзакция должна установить для него блокировку для записи (Х-блокировку). Если транзакция уже установила для объекта S-блокировку, необходимо расширить S-блокировку до уровня X-блокировки.

3) Если запрашиваемая со стороны транзакции B блокировка отвергается из-за конфликта с блокировкой, установленной транзакцией A, то транзакция B переводится в состояние ожидания, до тех пор, пока не будет снята блокировка, установленная транзакцией А. Во избежание ситуации «зависания» (транзакция В бесконечно долго находится в состоянии ожидания), необходимо обрабатывать запросы на блокировку по принципу «первым поступил - первым обработан».

4). Х-блокировки сохраняются вплоть до конца выполнения установившей их транзакции (до ее фиксации (commit) или отката (rollback)).

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

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

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

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

25. Функции и архитектура распределённых субд.

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

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

• Расширенные службы установки соединений должны обеспечивать доступ к удаленным сайтам позволять передавать запросы и данные между сайтами, входящими в сеть.

• Расширенные средства ведения каталога, позволяющие сохранять сведения о распределенности данных в сети.

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

• Расширенные функции управления параллельностью, позволяющие поддерживать целостность реплицируемых данных.

• Расширенные функции восстановления, учитывающие возможность отказов работ отдельных сайтов и отказов линий связи.

Архитектура СУРБД

Трехуровневая архитектура ANSI-SPARС для СУБД представляет собой типовое решение для централизованных СУБД.

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

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

Схемы фрагментации и распределения. Схемы фрагментации - описание того, как данные должны логически распределяться по разделам.

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

26. Olap и oltp системы, хранилище данных.

Первоначально в теории БД была сформирована концепция

OLTP (On-Line Transaction Processing) систем или систем оперативной обработки транзакций. Эти системы предназначены для решения задач сбора, хранения и поиска оперативных данных. Они используются в повседневной деятельности предприятия.

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

Но для выполнения полного анализа деятельности организации, определения ее деловых показателей и тенденций их изменения необходимо иметь доступ не только к текущим данным, но и к ранее накопленным. Для упрощения подобного анализа Коддом была разработана концепция хранилища данных (data warehouse).

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

Хранилище оперативных данных (Operational Data Store — ODS) представляет собой репозитарий для текущих и интегрированных оперативных данных, применяемых при анализе. Чаще всего оно структурируется и заполняется данными по такому же принципу≫ как и обычное хранилище данных, но фактически применяется просто как область накопления данных перед их передачей в обычное хранилище. Это что-то среднее между хранилищем и реляционной БД.

Однако лицам, ответственным за принятие корпоративных решений, необходимо иметь мощные инструменты анализа накопленных данных. Основными средствами анализа в последние годы стали инструменты оперативной аналитической обработки (On-Line Analytical Processing — OLAP) и инструменты разработки данных (data mining).

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

27. Архитектуры olap.

1