Билет 1 (стр. 2 )

CREATE INDEX имя_индекса

ON иия_таблицы (имя_поля_1, имя_поля_2. ...)

БИЛЕТ 4

1.  . Постреляционная и объектно-ориентированная модели;

2.  Язык SQL Работа с представлениями

1.  Постреляционная и объектно-ориентированная модели.

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

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

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

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

Поскольку постреляционная модель допускает хранение в таблицах ненормали­зованных данных, возникает проблема обеспечения целостности и непротиворечиво­сти данных. Эта проблема решается включением в СУБД механизмов, подобных хра­нимым процедурам в клиент-серверных системах.

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

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

Недостатком постреляционной модели является сложность решения проблемы обеспечения целостности и непротиворечивости хранимых данных.

Объектно-ориентированная модель

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

Структура объектно-ориентированной БД графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стан­дартным типом (например, строковым — string) или типом, конструируемым пользо­вателем (определяется как class).

Значением свойства типа string является строка символов. Значение свойства типа class есть объект, являющийся экземпляром соответствующего класса. Каждый объект-экземпляр класса считается потомком объекта, в котором он определен как свойство. Объект-экземпляр класса принадлежит своему классу и имеет одного родителя. Родовые отношения в БД образуют связную иерархию объектов.

Логическая структура объектно-ориентированной БД внешне похожа на структу­ру иерархической БД. Основное отличие между ними состоит в методах манипули­рования данными.

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

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

Рассмотрим кратко понятия инкапсуляции, наследования и полиморфизма при­менительно к объектно-ориентированной модели БД.

Инкапсуляция ограничивает область видимости имени свойства пределами того объекта, в котором оно определено.

Наследование, наоборот, распространяет область видимости свойства на всех потомков объекта.

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

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

Основным достоинством объектно-ориентированной модели данных в сравнении с реляционной является возможность отображения информации о сложныхсвязях объектов. Объектно-ориентированная модель данных позволяет идентифици­ровать отдельную запись базы данных и определять функции их обработки.

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

2.  Работа с представлениями.

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

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

Представления в отличие от таблиц не занимают дискового пространства (или, точнее, дисковое пространство, занимаемое представлениями, очень мало — толь­ко то, что требуется для хранения запроса).

Области применения представлений

Представления в основном применяются в двух случаях:

□ с целью защиты данных;

□ для формирования итоговых данных.

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

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

Создание представлений

Для создания представлений используется оператор CREATE VIEW. Представление может быть создано на основе одной или нескольких таблиц и/или других пред­ставлений. Наиболее типичный синтаксис оператора создания представлений име­ет следующий вид:

CREATE VIEW имя_представления AS {оператор выборки данных}

Оператор выборки может быть любой сложности, он может содержать любые ус­ловия отбора и предложения группировки.

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

Удаление представлений

Удаление представлений выполняется с помощью оператора DROP VIEW, при вызове которого могут указываться параметры RESTRICT или CASCADE. Данные параметры определяют действия при удалении представления, на которое ссылаются другие представления и/или ограничения. При использовании варианта RESTRICT в этом случае будет выдано сообщение об ошибке, и удаление не будет выполнено. Если же используется режим CASCADE, то выполнение оператора DROP VIEW приведет к уда­лению всех базовых представлений и ограничений.

Типовой синтаксис оператора DROP VIEW имеет следующий вид:

DROP VIEW имя_предстаеления [RESTRICT | CASCADE].

БИЛЕТ 5

1.  Реляционная модель данных, основные понятия, определения.

2.  Язык SQL Хранимые процедуры

1.  Реляционная модель данных, основные понятия, определения.

Реляционная модель

Реляционная модель данных основывается на понятии отношение (relation).

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

Таблица имеет строки (записи) и столбцы (колонки). Каждая строка таблицы имеет одинаковую структуру и состоит из полей. Строкам таблицы соответствуют кортежи, а столбцам — атрибуты отношения.

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

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

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

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

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

2.  Хранимые процедуры.

Хранимые процедуры

Хранимые процедуры (Stored Procedure) представляют собой группы связан­ных операторов SQL. Использование хранимых процедур обеспечивает допол­нительную гибкость при работе с базой данных, так как выполнить хранимую процедуру обычно гораздо проще, чем последовательность отдельных операто­ров SQL.

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

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

Основные преимущества, которые дает использование хранимых процедур, за­ключаются в следующем:

□ хранимые процедуры позволяют вынести часть логики на сервер базы данных. Это ослабляет зависимость базы данных информационной системы от клиент­ской части;

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

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

□ хранимые процедуры повышают эффективность работы информационной си­стемы: они выполняются сервером, а не клиентом, что снижает сетевой тра­фик;

□ скорость выполнения хранимых процедур выше, чем для последовательности отдельных операторов SQL. Это связано с тем, что хранимые процедуры хра­нятся на сервере в откомпилированном виде.

Различают два вида хранимых процедур:

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

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

БИЛЕТ 6

1.  Индексирование; связывание таблиц;

2.  Язык SQL Триггеры

1.  Индексирование. Связывание таблиц.

Индексирование

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

Термин «индекс» тесно связан с понятием «ключ», хотя между ними есть и неко­торое отличие.

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

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

Варианты решения проблемы организации физического доступа к информации зависят в основном от следующих факторов:

·  вида содержимого в поле ключа записей индексного файла;

·  типа используемых ссылок (указателей) на запись основной таблицы;

·  метода поиска нужных записей.

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

Для организации ссылки на запись таблицы могут использоваться три типа адресов:

абсолютный (действительный), относительный и символический (идентификатор).

На практике чаще всего используются два метода поиска: последовательный и бинарный (основан на делении интервала поиска пополам).

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

При одноуровневой схеме в индексном файле хранятся короткие записи, имеющие два поля: поле содержимого старшего ключа (хеш-кода ключа) адресуемого бло­ка и поле адреса начала этого блока. В каждом блоке записи располагаются в порядке возрастания значения ключа или свертки. Старшим ключом каждого блока является ключ его последней записи.

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

1.  Образование свертки значения ключевого поля искомой записи.

2.  Поиск в индексном файле записи о блоке, значение первого поля которого больше полученной свертки (это гарантирует нахождение искомой свертки в этом блоке).

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

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

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

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

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

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

Некоторыми СУБД, например Access, деление индексов на первичные и вто­ричные не производится. В этом случае используются автоматически создавае­мые индексы и индексы, определяемые пользователем по любому из не ключе­вых полей.

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

Связывание таблиц

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

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

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

Основные виды связи таблиц

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

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

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

Суть связывания состоит в установлении соответствия полей связи основной и дополнительной таблиц. Поля связи основной таблицы могут быть обычными и клю­чевыми. В качестве полей связи подчиненной таблицы чаще всего используют клю­чевые поля.

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

·  один — один (1:1);

·  один — много (1:М);

·  много — один (М:1);

·  много — много (М:М или M:N).

Связь вида 1:1

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

Связь вида 1:М

Связь 1:М имеет место в случае, когда одной записи основной таблицы соответ­ствует несколько записей вспомогательной таблицы.

Связь вида М:1

Связь М:1 имеет место в случае, когда одной или нескольким записям основной таблицы ставится в соответствие одна запись дополнительной таблицы.

Связь вида М:М

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

2.  Триггеры

Триггеры

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

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

□ возможность контроля вводимых данных, чтобы гарантировать, что пользова­тель ввел в поля таблицы только допустимые значения;

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

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

Создание триггера

Для создания триггера используется оператор CREATE TRIGGER. Синтаксис этого оператора существенно зависит от используемой реализации SQL, поэтому мы не будем рассматривать его подробно и поговорим лишь об общих особенностях со­здания триггеров.

Так же как и хранимые процедуры, триггеры состоят из заголовка и тела. Заголо­вок триггера содержит:

□ имя триггера, уникальное внутри базы данных;

□ имя таблицы, с которой связан триггер;

□ инструкции, которые определяют, когда триггер будет выполняться (при вы­полнении какого оператора манипулирования данными и в какой момент вре­мени — до или после выполнения оператора).

Тело триггера содержит:

□ список локальных переменных и их типов данных (если они используются в коде триггера);

□ блок инструкций на языке процедур и триггеров, заключенный между ключе­выми словами BEGIN и END. Блок может содержать в себе другой блок, реализуя несколько уровней вложенности.

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

заголовке.

Триггер связан с таблицей. Владелец таблицы и любой пользователь, наделенный

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

триггеры.

Удаление триггера

Для удаления триггера используется оператор DROP TRIGGER. Синтаксис этого опе­ратора является достаточно общим для различных реализаций SQL и имеет сле­дующий вид:

DROP TRIGGER имя_триггера.

БИЛЕТ 7

1.  Теоретические языки запросов

2.  Язык SQL. Манипулирование данными. Язык манипулирования данными - DML. Добавление в таблицу новой информации. Ввод данных в отдельные поля таблицы Изменение данных, хранящихся в таблице. Модификация данных в одном поле таблицы Изменение значений в нескольких полях таблицы

1.  Теоретические языки запросов.

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

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

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

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

·  реляционная алгебра;

·  реляционное исчисление.

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

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

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

2.  Язык SQL. Манипулирование данными. Язык манипулирования данными - DML. Добавление в таблицу новой информации. Ввод данных в отдельные поля таблицы Изменение данных, хранящихся в таблице. Модификация данных в одном поле таблицы Изменение значений в нескольких полях таблицы.

Язык SQL предназначен для выполнения операций над таблицами (создание, уда­ление, изменение структуры) и над данными таблиц (выборка, изменение, добавле­ние и удаление), а также некоторых сопутствующих операций. SQL является непро­цедурным языком и не содержит операторов управления, организации подпрограмм, ввода-вывода и т. п. В связи с этим SQL автономно не используется, обычно он погру­жен в среду встроенного языка программирования СУБД (например, FoxPro СУБД Visual FoxPro, ObjectPAL СУБД Paradox, Visual Basic for Applications СУБД Access).

Операторы языка SQL можно условно разделить на два подъязыка: язык опреде­ления данных (Data Definition Language — DDL) и язык манипулирования данными (Data Manipulation Language — DML).

Ввод данных: INSERT INTO <table> VALUES («value1», 1234, «value3», «value4»);

Ввод данных в отдельные поля: INSERT INTO <имя таблицы> [(<список столбцов>)] VALUES (<список значений>);

Изменение данных в таблице: UPDATE <table> SET <column_name1> = <value1> WHERE <column_name1> =<> <value2>.

Модификация данных в одном поле таблицы – тоже самое, но выбор строки по первичному ключу.

БИЛЕТ 8

1.Проблемы проектирования БД.

2.  Язык SQL Управление безопасностью базы данных.. Системные и объектные привилегии пользователей. Управление доступом к базе данных. Операторы GRANT и REVOKE.

1.  Проблемы проектирования БД.

Избыточное дублирование данных и аномалии.

Следует различать простое (не избыточное) и избыточное дублирование данных. Наличие первого из них допускается в базах данных, а избыточное дублирование дан­ных может приводить к проблемам при обработке данных. Приведем примеры обоих вариантов дублирования.

Описывать слишком нудно, см. Проектирование БД/Нормальные формы

2.  Язык SQL. Управление безопасностью базы данных. Системные и объектные привилегии пользователей. Управление доступом к базе данных. Операторы GRANT и REVOKE.

Управление безопасностью базы данных

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

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

Привилегии пользователей

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

Различают привилегии двух типов:

□ системные привилегии;

□ объектные привилегии.

Рассмотрим каждый из типов более подробно.

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

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

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

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

□ создание представления;

□ создание хранимой процедуры;

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

□ удаление представления;

□ удаление хранимой процедуры.

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

Объектные привилегии

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

Стандартом ANSI предусмотрены следующие объектные привилегии:

□ SELECT — разрешает производить выборку данных из указанной таблицы (пред­ставления);

□ INSERTимя_поля) — разрешает выполнять добавление данных в определенное поле указанной таблицы (представления);

□ INSERT — разрешает добавление данных во все поля указанной таблицы (пред­ставления);

□ UPDАТЕ(имя_поля) — разрешает модифицировать данные в заданном поле ука­занной таблицы (представления);

□ UPDATE — разрешает модифицировать данные во всех полях указанной табли­цы (представления);

□ REFERENCE (имя_поля) — разрешает ссылаться на заданное поле указанной таб­лицы (эта привилегия требуется при установке любых ограничений целостно­сти);

□ REFERENCE — позволяет ссылаться на все поля указанной таблицы.

Управление доступом к базе данных

Для управления доступом пользователей к базе данных в языке SQL существуют два оператора:

□ GRANT;

□ REVOKE.

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

Оператор GRANT

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

вид:

GRANT привилегия_1 [. привилегия_2]

ON имя_объекта

ТО имя_пользователя [WITH GRANT OPTION]

Предоставление пользователю с именем USER права на выбор данных из таблицы СОТРУДНИКИ выполняется с помощью следующего оператора:

GRANT SELECT ON Сотрудники ТО USER

С помощью одного оператора GRANT можно задавать сразу несколько привилегий. Например, следующий оператор предоставит пользователю USER право как про­сматривать, так и добавлять данные в таблицу СОТРУДНИКИ:

GRANT SELECT. INSERT ON Сотрудники TO USER

При вызове оператора GRANT может использоваться необязательное предложение WITH GRANT OPTION. Данное предложение означает, что пользователь, для которо­го предоставляются привилегии, также получает право предоставлять привиле­гии на данный объект. Например, если вызвать рассмотренный выше оператор с предложением WITH GRANT OPTION, то пользователь с1 именем USER, кроме права просматривать и добавлять данные в таблицу СОТРУДНИКИ, получит также право предоставлять эти привилегии другим пользователям:

GRANT SELECT. INSERT

ON Сотрудники

TO USER

WITH GRANT OPTION

Оператор REVOKE

Оператор REVOKE используется для отмены предоставленных пользователю приви­легий. Данный оператор может вызываться с одним из двух параметров — RESTRICT или CASCADE. При использовании варианта RESTRICT оператор REVOKE будет успешно выполнен только в том случае, если его выполнение не приведет к появлению так называемых оставленных привилегий.

При использовании режима CASCADE удаляются все привилегии, которые могли бы остаться у других пользователей. Это означает, что если пользователю USER1 были предоставлены привилегии с помощью параметра WITH GRANT OPTION, а он, в свою очередь, предоставил эти привилегии пользователю USER2, то отмена приви­легий пользователю USER1 в режиме CASCADE приведет к отмене привилегий и для пользователя USER2.

Синтаксис оператора REVOKE имеет следующий вид:

REVOKE привилегия_1 [. привилегия_2]

ON имя_объекта

FROM имя_пользователя [RESTRICT | CASCADE]

Например, для отмены права добавления данных в таблицу СОТРУДНИКИ для пользователя USER следует использовать следующий оператор: