Теоретическая и практическая часть

ПРАКТИЧЕСКАЯ РАБОТА

Тема: Изменение значений с помощью представлений. Кто что может делать в базе данных. Глобальные аспекты SQL.

Цель:

1. Изменение значений с помощью представлений
2. Кто что может делать в базе данных
3. Глобальные аспекты SQL

Оборудование и/или программное обеспечение:IBM PC, MS Access /OpenOfficedBase.

Теоретическая и практическая часть

Модифицирование представления

Один из наиболее трудных и неоднозначных аспектов представлений - непосредственное их использование с командами модификации DML. Эти команды фактически воздействуют на значения в базовой таблице представления. Это является некоторым противоречием. Представление состоит из результатов запроса, и когда вы модифицируете представление, вы модифицируете набор результатов запроса. Но модификация не должна воздействовать на запрос; она должна воздействовать на значения в таблице к которой был сделан запрос, и таким образом изменять вывод запроса. Это не простой вопрос. Следующий оператор будет создавать представление показанное на Рисунке 21.1:

CREATE VIEW Citymatch (custcity, salescity)
AS SELECT DISTINCT a.city, b.city
FROM Customers a, Salespeople b
WHERE a.snum = b.snum;

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

Например, одна строка этой таблицы - London London - показывает, что имеется по крайней мере один заказчик в Лондоне, обслуживаемый продавцом в Лондоне. Эта строка может быть произведена при совпадении Hoffmanа с его продавцом Peel, причем если оба они из Лондона.

custcity	salescity
Berlin	San Jose
London	London
Rome	London
Rome	New York
San Jose	Barselona
San Jose	San Jose

Рисунок 0-1 Представление совпадения по городам

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

Даже если вы не получите выбора используя отличия, вы все еще будете в том же самом положении, потому что вы будете тогда иметь две строки в представлении с идентичными значениями, то-есть с обоими столбцами равными " Lоndon London ". Эти две строки представления будут отличаться друг от друга, так что вы пока не сможете сообщить, какая строка представления исходила из каких значений базовых таблиц(имейте в виду, что запросы не использующие предложение ORDER BY, производят вывод в произвольном порядке. Это относится также и к запросам используемым внутри представлений, которые не могут использовать ORDER BY. Таким образом, порядок из двух строк не может быть использован для их отличий. Это означает, что мы будем снова обращаться к выводу строк которые не могут быть точно связаны с указанными строками запрашиваемой таблицы. Что если вы пробуете удалить строку ” London London ” из представления? Означало бы это удаление Hoffmanа из таблицы Заказчиков, удаление Clemens из той же таблицы, или удаление их обоих? Должен ли SQL также удалить Peel из таблицы Продавцов? На эти вопросы невозможно ответить точно, поэтому удаления не разрешены в представлениях такого типа. Представление Citymatch - это пример представления только_чтение, оно может быть только запрошено, но не изменено.

Вывод

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

Это означает что команда модификации, при выполнении, не должна требовать ни изменений для многих строк сразу, ни сравнений между многочисленными строками либо базовой таблицы либо вывода запроса. Так как объединения включают в себя сравнение строк, они также запрещены. Вы также поняли различие между некоторыми способами которые используют модифицируемые представления и представления только_чтение. Вы научились воспринимать модифицируемые представления как окна, отображающие данные одиночной таблицы, но необязательно исключающие или реорганизующие столбцы, посредством выбора только определенных строк отвечающих условию предиката. Представления только_чтение, с другой стороны, могут содержать более допустимые запросы SQL; они могут следовательно стать способом хранения запросов, которые вам нужно часто выполнять в неизменной форме. Кроме того, наличие запроса чей вывод обрабатывается как объект данных, дает вам возможность иметь ясность и удобство при создании запросов в выводе запросов. Вы теперь можете предохранять команды модификации в представлении от создания строк в базовой таблице, которые не представлены в самом представлении с помощью предложения WITH CHECK OPTION в определении представления. Вы можете также использовать WITH CHECK OPTION как один из способов ограничения в базовой таблице. В автономных запросах, вы обычно используете один или более столбцов в предикате не представленных среди выбранных для вывода, что не вызывает никаких проблем. Но если эти запросы используются в модифицируемых представлениях, появляются проблемы, так как эти запросы производят представления, которые не могут иметь вставляемых в них строк.

Пользователи

Каждый пользователь в среде SQL, имеет специальное идентификационное имя или номер. Терминология везде разная, но мы выбрали (следуя ANSI) ссылку на имя или номер как на Идентификатор (ID) доступа. Команда, посланная в базе данных ассоциируется с определенным пользователем; или иначе, специальным Идентификатором доступа. Поскольку это относится к SQL базе данных, ID разрешения - это имя пользователя, и SQL может использовать специальное ключевое слово USER, которое ссылается к Идентификатору доступа связанному с текущей командой. Команда интерпретируется и разрешается (или запрещается) на основе информации связанной с Идентификатором доступа пользователя подавшего команду.

Регистрация

В системах с многочисленными пользователями, имеется некоторый вид процедуры входа в систему, которую пользователь должен выполнить чтобы получить доступ к компьютерной системе. Эта процедура определяет какой ID доступа будет связан с текущим пользователем. Обычно, каждый человек использующий базу данных должен иметь свой собственный ID доступа и при регистрации превращается в действительного пользователям. Однако, часто пользователи имеющие много задач могут регистрироваться под различными ID доступа, или наоборот один ID доступа может использоваться несколькими пользователями. С точки зрения SQL нет никакой разницы между этими двумя случаями; он воспринимает пользователя просто как его ID доступа.

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

Предоставление привилегий

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

Стандартные привилегии

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

 

SELECT	Пользователь с этой привилегией может выполнять запросы в таблице.
INSERT	Пользователь с этой привилегией может выполнять команду INSERT в таблице.
UPDATE	Пользователь с этой привилегией может выполнять команду UPDATE на таблице. Вы можете ограничить эту привилегию для определенных столбцов таблицы.
DELETE	Пользователь с этой привилегией может выполнять команду DELETE в таблице.
REFERENCES	Пользователь с этой привилегией может определить внешний ключ, который использует один или более столбцов этой таблицы, как родительский ключ. Вы можете ограничить эту привилегию для определенных столбцов.

Кроме того, вы столкнетесь с нестандартными привилегиями объекта, такими например как INDEX (ИНДЕКС) дающим право создавать индекс в таблице, SYNONYM (СИНОНИМ) дающим право создавать синоним для объекта и ALTER (ИЗМЕНИТЬ) дающим право выполнять команду ALTER TABLE в таблице. Механизм SQL назначает пользователям эти привилегии с помощью команды GRANT.

Команда grant

Позвольте предположить, что пользователь Diane имеет таблицу Заказчиков и хочет позволить пользователю Adrian выполнить запрос к ней. Diane должна в этом случае ввести следующую команду:

GRANT INSERT ON Salespeople TO Diane;

Теперь Adrian может выполнить запросы к таблице Заказчиков. Без других привилегий, он может только выбрать значения; но не может выполнить любое действие, которые бы воздействовало на значения в таблице Заказчиков (включая использование таблицы Заказчиков в качестве родительской таблицы внешнего ключа, что ограничивает изменения которые выполнять со значениям в таблице Заказчиков). Когда SQL получает команду GRANT, он проверяет привилегии пользователя подавшего эту команду, чтобы определить допустима ли команда GRANT.

Adrian самостоятельно не может выдать эту команду. Он также не может предоставить право SELECT другому пользователю: таблица еще принадлежит Diane (позже мы покажем как Diane может дать право Adrian предоставлять SELECT другим пользователям). Синтаксис - тот же самый, что и для предоставления других привилегий. Если Adrian - владелец таблицы Продавцов, то он может позволить Diane вводить в нее строки с помощью следующего предложения

GRANT INSERT ON Salespeople TO Diane;

Теперь Diane имеет право помещать нового продавца в таблицу.

Отмена привилегий

Также как ANSI предоставляет команду CREATE TABLE чтобы создать таблицу, а не DROP TABLE чтобы от нее избавиться, так и команда GRANT позволяет вам давать привилегии пользователям, не предоставляя способа чтобы отобрать их обратно. Потребность удалять привилегии сводится к команде REVOKE, фактически стандартному средству с достаточно понятной формой записи. Синтаксис команды REVOKE - похож на GRANT, но имеет обратный смысл. Чтобы удалить привилегию INSERT для Adrian в таблице Порядков, вы можете ввести

REVOKE INSERT ON Orders FROM Adrian;

Использование списков привилегий и пользователей здесь допустимы как и в случае с GRANT, так что вы можете ввести следующую команду:

REVOKE INSERT, DELETE ON Customers
FROM Adrian, Stephen;

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

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

Другие типы привилегий

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

· Кто имеет право изменять, удалять, или ограничивать таблицы?

· Должны ли права создания базовых таблиц отличаться от прав создания представлений?

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

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

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

Типичные привилегии системы

При общем подходе имеется три базовых привилегии системы:

· CONNECT (Подключить),

· RESOURCE (Ресурс), и

· DBA ( Аминистратор Базы Данных ).

Проще, можно сказать, что CONNECT состоит из права зарегистрироваться и права создавать представления и синонимы, если переданы привилегии объекта. RESOURCE состоит из права создавать базовые таблицы. DBA - это привилегия суперпользователя, дающая пользователю высокие полномочия в базе данных. Один или более пользователей с функциями администратора базы данных может иметь эту привилегию. Некоторые системы кроме того имеют специального пользователя, иногда называемого SYSADM или SYS (Системный Администратор Базы Данных), который имеет наивысшие полномочия; это - специальное имя, а не просто пользователь со специальной DBA привилегией. Фактически только один человек имеет право зарегистрироваться с именем SYSADM, являющимся его идентификатором доступа. Различие весьма тонкое и функционирует по разному в различных системах. Для наших целей, мы будем ссылаться на высокопривилегированного пользователя, который разрабатывает и управляет базой данных имея полномочия DBA, понимая что фактически эти полномочия - та же самая привилегия. Команда GRANT, в измененной форме, является пригодной для использования с привилегиями объекта как и с системными привилегиями. Для начала передача прав может быть сделана с помощью DBA. Например, DBA может передать привилегию для создания таблицы пользователю Rodriguez следующим образом:

GRANT RESOURCE TO Rodriguez;

Глобальные аспекты sql

Переименование таблиц

Каждый раз, когда вы ссылаетесь в команде к базовой таблице или представлению не являющимися вашей собственностью, вы должны установить в ней префикс имени владельца, так что бы SQL знала где ее искать. Так как это со временем становится неудобным, большинство реализаций SQL позволяют вам создавать синонимы для таблиц (что не является стандартом ANSI) Синоним - это альтернативное имя, наподобие прозвища, для таблицы. Когда вы создаете синоним, вы становитесь его собственником, так что нет никакой необходимости, чтобы он предшествовал другому пользовательскому идентификатору доступа(имени пользователя) Если вы имеете по крайней мере одну привилегию в одном или более столбцах таблицы; вы можете создать для них синоним. (Некоторое отношение к этому может иметь специальная привилегия для создания синонимов.)

Adrian может создать синоним с именем Clients, для таблицы с именем Diane.Customers, с помощью команды CREATE SYNONYM следующим образом:

CREATE SYNONYM Clients FOR Diane.Customers;

Теперь, Adrian может использовать таблицу с именем Clients в команде точно так же как ее использует Diane.Customers. Синоним Clients - это собственность, используемая исключительно для Adrian.

Одно имя для каждого

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

CREATE PUBLIC SYNONYM Customers FOR Customers;

Мы пронимаем, что таблица Заказчиков это ваша собственность, поэтому никакого префикса имени пользователя в этой команды не указывается. В основном, общие синонимы создаются владельцами объектов или привилегированными пользователями, типа DBA. Пользователям кроме того, должны еще быть предоставлены привилегии в таблице Заказчиков чтобы они могли иметь к ней доступ. Даже если имя является общим, сама таблица общей не является. Общие синонимы становятся собственными с помощью команды PUBLIC, а не с помощью их создателей.

Удаление синонимов

Общие и другие синонимы могут удаляться командой DROP SYNONYM. Синонимы удаляются их владельцами, кроме общих синонимов, которые удаляются соответствующими привилегированными личностями, обычно DBA. Чтобы удалить например синоним Clients, когда вместо него уже появился общий синоним Customers, Adrian может ввести

DROP SYNONYM Clients;

Сама таблица Заказчиков, естественно, становится не эффективной.

Типы блокировок

Имеется два базовых типа блокировок:

· распределяемые блокировки и

· специальльные блокировки.

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

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

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

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

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

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

Вывод

Ключевые определения:

· Синонимы, или как создавать новые имена для объектов данных.

· Области базы даных (DBS), или как распределяется доступная память в базе данных.

· Транзакция, или как сохранять или восстанавливать изменения в базе данных.

· Управление Параллелизмом, или как SQL предохраняет от конфликта одной команды с другой.

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

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

СOMMIT и ROLLBACK -это команды, используемые для выполнения изменений в базе данных, в то время когда предыдущая команда COMMIT или команда ROLLBACK, начинают сеанс и оставляют изменения, или игнорируют их как группу.

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

Практическая часть

1. Какое из этих представлений - модифицируемое?

#1 CREATE VIEW Dailyorders
AS SELECT DISTINCT cnum, snum, onum, odate
FROM Orders;

#2 CREATE VIEW Custotals
AS SELECT cname, SUM (amt)
FROM Orders, Customers
WHERE Orders.cnum = customer.cnum
GROUP BY cname;

#3 CREATE VIEW Thirdorders
AS SELECT *
FROM Dailyorders
WHERE odate = 10/03/1990;

#4 CREATE VIEW Nullcities
AS SELECT snum, sname, city
FROM Salespeople
WHERE city IS NULL
OR sname BETWEEN 'A' AND 'MZ';

2. Создайте представление таблицы Продавцов с именем Commissions (Комиссионные). Это представление должно включать только поля comm и snum. С помощью этого представления, можно будет вводить или изменять комиссионные, но только для значений между.10 и.20.

3. Некоторые SQL реализации имеют встроенную константу представляющую текущую дату, иногда называемую " CURDATE ". Слово CURDATE может следовательно использоваться в операторе SQL, и заменяться текущей датой, когда его значение станет доступным с помощью таких команд как SELECT или INSERT. Мы будем использовать представление таблицы Порядков с именем Entryorders для вставки строк в таблицу Порядков. Создайте таблицу порядков, так чтобы CURDATE автоматически вставлялась в поле odate если не указано другого значения. Затем создайте представление Entryorders, так чтобы значения не могли быть указаны.

4. Передайте Janet право на изменение оценки заказчика.

5. Передайте Stephan право передавать другим пользователям право делать запросы в таблице Порядков.

6. Отнимите привилегию INSERT(ВСТАВКА) в таблице Продавцов у Claire и у всех пользователей которым она была предоставлена.

7. Передайте Jerry право вставлять или модифицировать таблицу Заказчиков с сохранением его возможности оценивать значения в диапазоне от 100 до 500.

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

9. Создайте область базы данных с именем Myspace которая выделяет 15 процентов своей области для индексов, и 40 процентов на расширение строк.

10.Вы получили право SELECT в таблице Порядков продавца Diane. Введите команду так чтобы вы могли ссылаться к этой таблице как к "Orders" не используя имя "Diane" в качестве префикса.

11.Если произойдет сбой питания, что случится с всеми изменениями сделанными во время текущей транзакции?

12.Если вы не можете видеть строку из-за ее блокировки, какой это тип блокировки?

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

Контрольные вопросы:

Литература

ПРАКТИЧЕСКАЯ РАБОТА

Тема: Изменение значений с помощью представлений. Кто что может делать в базе данных. Глобальные аспекты SQL.

Цель:

1. Изменение значений с помощью представлений
2. Кто что может делать в базе данных
3. Глобальные аспекты SQL

Оборудование и/или программное обеспечение:IBM PC, MS Access /OpenOfficedBase.

Теоретическая и практическая часть