Ответы на вопросы по базам данных (Вариант 12)

Базы данных 1.Базы данных. Вычислительная модель «клиент-сервер» в технологии баз данных. Презентационная логика, бизнес логика, функции хранения. Модели распределения функций между клиентом и сервером. Вычислительная модель «клиент—сервер» исходно связана с парадигмой открытых систем, которая появилась в 90-х годах и быстро эволюционировала. Сам термин «клиент-сервер» исходно применялся к архитектуре программного обеспечения, которое описывало распределение процесса выполнения по принципу взаимодействия двух программных процессов, один из которых в этой модели назывался «клиентом», а другой — «сервером». Клиентский процесс запрашивал некоторые услуги, а серверный процесс обеспечивал их выполнение. При этом предполагалось, что один серверный процесс может обслужить множество клиентских процессов. Основной принцип технологии «клиент—сервер» применительно к технологии баз данных заключается в разделении функций стандартного интерактивного приложения на 5 групп, имеющих различную природу: •функции ввода и отображения данных (Presentation Logic); •прикладные функции, определяющие основные алгоритмы решения задач приложения (Business Logic); •функции обработки данных внутри приложения (Database Logic), •функции управления информационными ресурсами (Database Manager System); •служебные функции, играющие роль связок между функциями первых четырех групп. Презентационная логика (Presentation Logic) как часть приложения определяется тем, что пользователь видит на своем экране, когда работает приложение. Сюда относятся все интерфейсные экранные формы, которые пользователь видит или заполняет в ходе работы приложения, к этой же части относится все то, что выводится пользователю на экран как результаты решения некоторых промежуточных задач либо как справочная информация. Поэтому основными задачами презентационной логики являются: •формирование экранных изображений; •чтение и запись в экранные формы информации; •управление экраном; •обработка движений мыши и нажатие клавиш клавиатуры. В децентрализованной архитектуре эти задачи могут быть по-разному распределены между серверным и клиентским процессами. В зависимости от характера распределения можно выделить следующие модели распределений (см. рис. 10.3): распределенная презентация (Distribution presentation, DP); удаленная презентация (Remote Presentation, RP); распределенная бизнес-логика (Remote business logic, RBL); распределенное управление данными (Distributed data management, DDM); удаленное управление данными (Remote data management, RDA). Эта условная классификация показывет, как могут быть распределены отдельные задачи между серверным и клиенскими процессами. В этой классификации отсутствует реализация удаленной бизнес-логики. Действительно, считается, что она не может быть удалена сама по себе полностью. Считается, что она может быть распределена между разными процессами, которые в общем-то могут выполняться на разных платформах, но должны корректно кооперироваться (взаимодействовать) друг с другом.

2.Базы данных. Журнал транзакций, его назначение и функции.

Реализация в СУБД принципа сохранения промежуточных состояний, подтверждения или отката транзакции обеспечивается специальным механизмом, для поддержки которого создается некоторая системная структура, называемая Журналом транзакций. Однако назначение журнала транзакций гораздо шире. Он предназначен для обеспечения надежного хранения данных в БД. А это требование предполагает, в частности, возможность восстановления согласованного состояния базы данных после любого рода аппаратных и программных сбоев. Очевидно, что для выполнения, восстановлений необходима некоторая дополнительная информация. В подавляющем большинстве современных реляционных СУБД такая избыточная дополнительная информация поддерживается в виде журнала изменений базы данных, чаще всего называемого Журналом транзакций. Итак, общей целью журнализации изменений баз данных является обеспечение возможности восстановления согласованного состояния базы данных после любого сбоя. Поскольку основой поддержания целостного состояния базы данных является механизм транзакций, журнализация и восстановление тесно связаны с понятием транзакции. Общими принципами восстановления являются следующие: •результаты зафиксированных транзакций должны быть сохранены в восстановленном состоянии базы данных; •результаты незафиксированных транзакций должны отсутствовать в восстановленном состоянии базы данных. Это, собственно, и означает, что восстанавливается последнее по времени согласованное состояние базы данных. Возможны следующие ситуации, при которых требуется производить восстановление состояния базы данных. •Индивидуальный откат транзакции. Этот откат должен быть применен в следующих случаях: oстандартной ситуацией отката транзакции является ее явное завершение оператором ROLLBACK; oаварийное завершение работы прикладной программы, которое логически эквивалентно выполнению оператора ROLLBACK, но физически имеет иной механизм выполнения; oпринудительный откат транзакции в случае взаимной блокировки при параллельном выполнении транзакций. В подобном случае для выхода из тупика данная транзакция может быть выбрана в качестве «жертвы» и принудительно прекращено ее выполнение ядром СУБД. •Восстановление после внезапной потери содержимого оперативной памяти (мягкий сбой). Такая ситуация может возникнуть в следующих случаях: oпри аварийном выключении электрического питания; oпри возникновении неустранимого сбоя процессора (например, срабатывании контроля оперативной памяти) и т. д. Ситуация характеризуется потерей той части базы данных, которая к моменту сбоя содержалась в буферах оперативной памяти. •Восстановление после поломки основного внешнего носителя базы данных (жесткий сбой). Эта ситуация при достаточно высокой надежности современных устройств внешней памяти может возникать сравнительно редко, но тем не менее СУБД должна быть в состоянии восстановить базу данных даже и в этом случае. Основой восстановления является архивная копия и журнал изменений базы данных. 3.Базы данных. Запрос пользователя. Процесс прохождения пользовательского запроса. Цифрами помечена последовательность взаимодействий: 1. Пользователь посылает СУБД запрос на получение данных из БД. 2. Анализ прав пользователя и внешней модели данных, соответствующей данному пользователю, подтверждает или запрещает доступ данного пользователя к запрошенным данным. 3. В случае запрета на доступ к данным СУБД сообщает пользователю об этом (стрелка 12) и прекращает дальнейший процесс обработки данных, в противном случае СУБД определяет часть концептуальной модели, которая затрагивается запросом пользователя. 4. СУБД запрашивают информацию о части концептуальной модели. 5. СУБД получает информацию о запрошенной части концептуальной модели. 6. СУБД запрашивает информацию о местоположении данных на физическом уровне (файлы или физические адреса). 7. В СУБД возвращается информация о местоположении данных в терминах операционной системы. 8. СУБД вежливо просит операционную систему предоставить необходимые данные, используя средства операционной системы. 9. Операционная система осуществляет перекачку информации из устройств хранения и пересылает ее в системный буфер. 10. Операционная система оповещает СУБД об окончании пересылки. 11. СУБД выбирает из доставленной информации, находящейся в системном буфере, только то, что нужно пользователю, и пересылает эти данные в рабочую область пользователя. БМД — это База Метаданных, именно здесь и хранится вся информация об используемых структурах данных, логической организации данных, правах доступа пользователей и, наконец, физическом расположении данных. Для управления БМД существует специальное программное обеспечение администрирования баз данных, которое предназначено для корректного использования единого информационного пространства многими пользователями. Всегда ли запрос проходит полный цикл? Конечно, нет. СУБД обладает достаточно развитым интеллектом, который позволяет ей не повторять бессмысленных действий. И поэтому, например, если этот же пользователь повторно обратится к СУБД с новым запросом, то для него уже не будут проверяться внешняя модель и права доступа, а если дальнейший анализ запроса покажет, что данные могут находиться в системном буфере, то СУБД осуществит только 11 и 12 шаги в обработке запроса. Разумеется, механизм прохождения запроса в реальных СУБД гораздо сложнее, но и эта упрощенная схема показывает, насколько серьезными и сложными должны быть механизмы обработки запросов, поддерживаемые реальными СУБД.

4.Базы данных. Курсоры: назначение, реализация, управление.

SQL Server поддерживает три вида курсоров: •курсоры SQL применяются в основном внутри триггеров, хранимых процедур и сценариев; •курсоры сервера действуют на сервере и реализуют программный интерфейс приложений для ODBC, OLE DB, DB_Library; •курсоры клиента реализуются на самом клиенте. Они выбирают весь результирующий набор строк из сервера и сохраняют его локально, что позволяет ускорить операции обработки данных за счет снижения потерь времени на выполнение сетевых операций. В среде SQL Server типы курсоров различаются по предоставляемым возможностям. Тип курсора определяется на стадии его создания и не может быть изменен. Некоторые типы курсоров могут обнаруживать изменения, сделанные другими пользователями в строках, включенных в результирующий набор. Однако SQL Server отслеживаетизменения таких строк только на стадии обращения к строке и не позволяет отслеживать изменения, когда строка уже считана. Курсоры делятся на две категории: Последовательные позволяют выбирать данные только в одном направлении – от начала к концу. Прокручиваемые же курсоры предоставляют большую свободу действий – допускается перемещение в обоих направлениях и переход к произвольной строке результирующего набора курсора. Если программа способна модифицировать данные, на которые указывает курсор, он называется прокручиваемым и модифицируемым. Говоря о курсорах, не следует забывать об изолированности транзакций. Когда один пользователь модифицирует запись, другой читает ее при помощи собственного курсора, более того, он может модифицировать ту же запись, что делает необходимым соблюдение целостности данных. SQL Server поддерживает курсоры статические, динамические, последовательные и управляемые набором ключей. В схеме со статическим курсором информация читается из базы данных один раз и хранится в виде моментального снимка (по состоянию на некоторый момент времени), поэтому изменения, внесенные в базу данных другим пользователем, не видны. На время открытия курсора сервер устанавливает блокировку на все строки, включенные в его полный результирующий набор. Статический курсор не изменяется после создания и всегда отображает тот набор данных, который существовал на момент его открытия. Если другие пользователи изменят в исходной таблице включенные в курсор данные, это никак не повлияет на статический курсор. Динамический курсор поддерживает данные в «живом» состоянии, но это требует затрат сетевых и программных ресурсов. При использовании динамических курсоров не создается полная копия исходных данных, а выполняется динамическая выборка из исходных таблиц только при обращении пользователя к тем или иным данным. На время выборки сервер блокирует строки, а все изменения, вносимые пользователем в полный результирующий набор курсора, будут видны в курсоре. Однако если другой пользователь внес изменения уже после выборки данных курсором, то они не отразятся в курсоре . Курсор, управляемый набором ключей, находится посередине между этими крайностями. Записи идентифицируются на момент выборки, и тем самым отслеживаютсяизменения . Такой тип курсора полезен при реализации прокрутки назад – тогда добавления и удаления рядов не видны, пока информация не обновится, а драйвер выбирает новую версию записи, если в нее были внесены изменения. Последовательные курсоры не разрешают выполнять выборку данных в обратном направлении. Пользователь может выбирать строки только от начала к концу курсора .Последовательный курсор не хранит набор всех строк. Они считываются из базы данных, как только выбираются в курсоре, что позволяет динамически отражать всеизменения, вносимые пользователями в базу данных с помощью команд INSERT, UPDATE, DELETE. В курсоре видно самое последнее состояние данных. Статические курсоры обеспечивают стабильный взгляд на данные. Они хороши для систем «складирования» информации: приложений для систем отчетности или для статистических и аналитических целей. Кроме того, статический курсор лучше других справляется с выборкой большого количества данных. Напротив, в системах электронных покупок или резервирования билетов необходимо динамическое восприятие обновляемой информации по мере внесения изменений. В таких случаях используетсядинамический курсор. В этих приложениях объем передаваемых данных, как правило, невелик, а доступ к ним осуществляется на уровне рядов (отдельных записей). Групповой доступ встречается очень редко.

5.Базы данных. Манипулирование данными средствами SQL.

К базовым средствам манипулирования данными языка SQL относятся «поисковые» варианты операторов UPDATE и DELETE. Эти варианты называются поисковыми, потому что при задании соответствующей операции задается логическое условие, налагаемое на строки адресуемой оператором таблицы, которые должны быть подвергнуты модификации или удалению. Кроме того, в такую категорию языковых средств входит оператор INSERT, позволяющий добавлять строки в существующие таблицы. Логично начать изложение именно с оператора INSERT, поскольку, для того чтобы можно было что-либо модифицировать в таблицах или удалять из таблиц, нужно, чтобы в таблицах содержались какие-то строки. Общий синтаксис оператора INSERT выглядит следующим образом: INSERT INTO table_name { [ (column_commalist) ] query_expression | DEFAULT VALUES Общий синтаксис оператора UPDATE выглядит следующим образом: UPDATE table_name SET update_assignment_commalist WHERE conditional_expression update_assignment ::= column_name = { value_expression | DEFAULT | NULL } Общий синтаксис оператора DELETE выглядит следующим образом: DELETE FROM table_name WHERE conditional_expression В некотором смысле оператор DELETE является частным случаем оператора UPDATE (или, наоборот, действие оператора UPDATE представляет собой комбинацию действий операторов DELETE и INSERT). Язык манипулирования данными (DML) — это часть языка SQL, предназначенная для реального внесения пользователем изменений в информацию, содержащуюся в реляционной базе данных. С помощью команд языка манипулирования данными пользователь может загружать в таблицы новые данные, а также изменять и удалять существующие. Команды DML также могут быть использованы при выполнении простых запросов к базе данных. В языке SQL существует три основных команды DML:INSERT, UPDATE, DELETE. Единственной структурой представления данных (как прикладных, так и системных) в реляционной базе данных (БД) является двумерная таблица. В реляционной модели данных таблица обладает следующими основными свойствами: •идентифицуруется уникальным именем; • имеет конечное ненулевое количество столбцов; •имеет конечное (возможно, нулевое) число строк; столбцы таблицы идентифицируются своими уникальными именами и номерами; • содержимое всех ячеек столбца принадлежит одному типу данных; • в общем случае ячейки таблицы могут оставаться пустыми, такое их состояние обозначается как NULL. 6Базы данных. Механизм блокировок. Виды блокировок. Проблемы применения различных видов блокировок. Одновременный доступ нескольких клиентов к хранилищу данных может приводить к ошибкам различного типа. Например, одновременное чтение одним клиентом и запись другим клиентом одной и той же строки таблицы с большой вероятностью приведет к сбою или чтению некорректных данных. Механизмы блокировок позволяют избежать ситуаций одновременного доступа к данным, регламентируя механизм взаимодействия пользователей между собой MySQL от имени одного из клиентов накладывает блокировку на определенный ресурс, при этом другие клиенты ждут освобождения блокировки. Блокировка может быть на уровне таблиц (блокируется таблица) или на уровне строк (блокируются определенные строки таблицы). В механизме хранения MyISAM (используемом по умолчанию) реализована табличная блокировка, а в механизме InnoDB построчная. Построчная блокировка достигается посредством усложнения структуры хранилища: в MyISAM структура файла с данными представляет собой простое перечисление строк таблицы, тогда как хранилище InnoDB структурировано и поддерживает мультиверсионность данных. Поэтому, InnoDB выигрывает в приложениях, в которых происходит многопоточное изменение данных в одну и ту же таблицу, несмотря на необходимые потери на обслуживание более сложного хранилища. Блокировки бывают двух видов: на чтение и на запись. 1.Если A хочет читать данные, то другие клиенты тоже могут читать данные, но никто не может записывать, пока А не закончит чтение (read lock). 2.Если А хочет записать данные, то другие клиенты не должны ни читать ни писать эти данные пока А не закончит(write lock). Блокировка может быть наложена явно или неявно. 1.Если клиент не назначает блокировку явным образом, MySQL сервер неявно устанавливает необходимый тип блокировки на время выполнения выражения или транзакции. Например, в случае выполнения оператора SELECT сервер установит READ LOCK, а в случае UPDATE — WRITE LOCK. При неявной блокировке уровень блокировки зависит от типа хранилища данных: для MyISAM, MEMORY и MERGE блокируется вся таблица, для InnoDB — только используемые в выражении строки (в случае, если набор этих строк может быть однозначно определен значениями первичного ключа — иначе, блокируется вся таблица). 2.Часто возникает необходимость выполнения нескольких запросов подряд без вмешательства других клиентов в это время. Неявная блоктровка не подходит для этих целей, так как устанавливается только на время выполнения одного запроса. В этом случае клиент может явно назначить, а потом отменить блокировку с помощью выражений LOCK TABLES и UNLOCK TABLES. Явной блокировка всегда блокирует всю таблицу, независимо от механизма хранения

7.Базы данных. Механизм блокировок. Уровни изолированности транзакций.

Одновременный доступ нескольких клиентов к хранилищу данных может приводить к ошибкам различного типа. Например, одновременное чтение одним клиентом и запись другим клиентом одной и той же строки таблицы с большой вероятностью приведет к сбою или чтению некорректных данных. Механизмы блокировок позволяют избежать ситуаций одновременного доступа к данным, регламентируя механизм взаимодействия пользователей между собой. MySQL от имени одного из клиентов накладывает блокировку на определенный ресурс, при этом другие клиенты ждут освобождения блокировки. Блокировка может быть на уровне таблиц (блокируется таблица) или на уровне строк (блокируются определенные строки таблицы). В механизме хранения MyISAM (используемом по умолчанию) реализована табличная блокировка, а в механизме InnoDB построчная. Построчная блокировка достигается посредством усложнения структуры хранилища: в MyISAM структура файла с данными представляет собой простое перечисление строк таблицы, тогда как хранилище InnoDB структурировано и поддерживает мультиверсионность данных. Поэтому, InnoDB выигрывает в приложениях, в которых происходит многопоточное изменение данных в одну и ту же таблицу, несмотря на необходимые потери на обслуживание более сложного хранилища С целью обеспечения предсказуемости работы приложений для многопользовательских БД стандарт ANSI/ISO для SQL устанавливает различные уровни изоляции для операций, выполняемых над базами данных. Уровень изоляции определяет, может ли транзакция «видеть» результаты работы других одновременно выполняемых завершённых и/или незавершённых транзакций (табл. 7.1). Уровень изоляции позволяет транзакциям в большей или меньшей степени влиять друг на друга: при повышении уровня изоляции повышается согласованность данных, но снижается степень параллельности работы и, следовательно, производительность системы. Таблица 7.1. Уровни изоляции по стандарту ANSI / ISO Уровень изоляции Черновое чтение Неповторяемое чтение Фантомы

8.Базы данных. Модели данных. Иерархическая и сетевая модели данных.

Базы данных (БД) – это данные, организованные в виде набора записей определенной структуры и хранящиеся в файлах, где, помимо самих данных, содержится описание их структуры. Система управления базами данных (СУБД) – система, обеспечивающая ввод данных в БД, их хранение и восстановление в случае сбоев, манипулирование данными, поиск и вывод данных по запросу пользователя. По моделям представления, базы данных делятся на: — иерархические; — сетевые; — реляционные; — объектно-реляционные. Иерархические базы данных – это самая первая модель представления данных, в которой все записи базы данных представлены в виде дерева, с соотношением предок-потомок (рис. 30). Фактически данные отношения реализуются в виде указателей на предков и потомков, содержащихся в самой записи. Такая модель представления данных связана с тем, что на ранних этапах, базы данных часто использовались для планирования производственного процесса: каждое выпускаемое изделие состоит из узлов, каждый узел из деталей и т.д. Для того, чтобы знать сколько деталей каждого вида надо заказать, строилось дерево. Поскольку список составных частей изделия представлял собой дерево, то для его хранения в базе данных наилучшим образом подходила иерархическая модель организации данных. Однако иерархическая модель не является оптимальной. Допустим, что один и тот же тип болтов используется в автомобиле 300 раз в различных узлах. При использовании иерархической модели, данный тип болтов будет фигурировать в базе данных 1 раз, а 300 раз (в каждом узле — отдельно). В данном случае, будет прослеживаться дублирование информации. Чтобы устранить этот недостаток была введена сетевая модель представления данных. Сетевая база данных – это база данных, в которой одна запись может участвовать в нескольких отношениях предок-потомок (рис. 31). Т.е. фактически, база данных представляет собой не дерево, а граф. Физически данная модель также реализуется за счет хранящихся внутри самой записи указателей на другие записи, только, в отличие от иерархической модели, число этих указателей может быть произвольным. И иерархическая и сетевая модели достаточно просты, однако они имеют общий недостаток: для того, чтобы получить ответ даже на простой вопрос, программист должен был написать программу, которая просматривала базу данных, двигаясь по указателям от одной записи к другой. Написание программы занимало некоторое время, и часто к тому моменту, когда такая программа была написана, необходимость в получении данных уже не требовалась. Поэтому в середине 80-х годов 20 века произошел практически повсеместный переход к реляционным базам данных.

9.Базы данных. Модели данных. Реляционная модель данных.

Базы данных (БД) – это данные, организованные в виде набора записей определенной структуры и хранящиеся в файлах, где, помимо самих данных, содержится описание их структуры. Система управления базами данных (СУБД) – система, обеспечивающая ввод данных в БД, их хранение и восстановление в случае сбоев, манипулирование данными, поиск и вывод данных по запросу пользователя. По моделям представления, базы данных делятся на: — иерархические; — сетевые; — реляционные; — объектно-реляционные. В реляционной базе данных вся информации представляется в виде таблиц, и любые операции над данными – это операции над таблицами. Таблицы строят из строк и столбцов. Строки – это записи, а столбцы представляют собой структуру записи (каждый столбец имеет определенный тип данных и длину данных). Строки в таблице не упорядочены – не существует первой или десятой строки. Однако поскольку на строки необходимо как-то ссылаться, то вводится понятие «первичный ключ». Первичный ключ – это столбец, значение которого во всех строках разные. Используя первичный ключ, можно однозначно ссылаться на любую строку таблицы. Первичный ключ может состоять и из нескольких столбцов (составной первичный ключ). Некоторые СУБД требуют в явном виде указать первичный ключ таблицы, а некоторые позволяют пользователю не задавать для таблицы первичный ключ – в таком случае СУБД сама добавляет в таблицу столбец – первичный ключ, не отображаемый на экране (так, например, в СУБД Oracle у любой таблицы существует псевдо-столбец ROWID, формируемый Oracle, который содержит уникальный адрес каждой строки). Отношения предок-потомок в реляционных БД реализуются при помощи внешних ключей. Внешний ключ – это столбец таблицы, значения которого совпадают со значениями первичного ключа некоторой другой таблицы. Так, например, на рис. 32 столбец «Ответственный» таблицы «Мероприятия» является внешним ключом для таблицы «Сотрудники» (первичный ключ – столбец «Фамилия»). Рис. 32. Отношения предок-потомок в реляционных базах данных. Важным моментом является также использование значения NULL в таблицах реляционной базе данных. NULL – это отсутствующее значение, отсутствие информации по данной позиции. Не допускается использование 0 или пробела вместо NULL: понятно, что «нулевой» объем продаж – это не тоже самое, что «неизвестный» объем продаж. По этой же причине, ни одно значение NULL не равно другому значению NULL. В реляционной базе данных, при запросах, группировке, сравнениях, и т.д., значения NULL обрабатываются особым образом.

10.Базы данных. Объектно-ориентированные и объектно-реляционные базы данных.

В отличие от реляционных, ООСУБД полностью поддерживают объектно-ориентированные языки программирования. Разработчики, применяющие С++ или Smalltalk, имеют дело с одним набором правил (позволяющих использовать такие преимущества объектной технологии, как наследование, инкапсуляция и полиморфизм). Разработчик не должен прибегать к трансляции объектной модели в реляционную и обратно. Прикладные программы обращаются и функционируют с объектами, сохраненными в базе данных, которая использует стандартную объектно-ориентированную семантику языка и операции. И, наконец, ООСУБД подходят для организации распределенных вычислений. Традиционные базы данных построены вокруг центрального сервера, выполняющего все операции над базой. По существу, эта модель мало отличается от мэйнфреймовой организации 60?х годов с центральной ЭВМ – мэйнфреймом (mainframe), выполняющей все вычисления, и пассивных терминалов. Такая архитектура имеет ряд недостатков, главным из которых является вопрос масштабируемости. Все ООСУБД по определению поддерживают сохранение и разделение объектов. Но, когда дело доходит до практической разработки приложений на разных ООСУБД, проявляется множество отличий в реализации поддержки трех характеристик: · Целостность; · Масштабируемость; · Отказоустойчивость. Отметим, что ООБД не требуют многих из тех внутренних функций и механизмов, которые столь привычны и необходимы в реляционных БД. Например, при небольшом числе пользователей, длинных транзакциях и незначительной загрузке сервера объектные СУБД не нуждаются в поддержке сложных механизмов резервного копирования/восстановления (исторически сложилось так, что первые ООБД проектировались для поддержки небольших рабочих групп – порядка десяти человек – и не были приспособлены для обслуживания сотен пользователей). Объектно-реляционные базы данных появились в последнее время у значительного числа производителей СУБД (Oracle, Informix, PostgreSQL) и сочетают в себе реляционную модель данных с концепциями объектно-ориентированного программирования (полиморфизм, инкапсуляция, наследование). Объектно-реляционные базы данных обладают рядом достоинств: разделение таблиц разными программами; развернутый “код возврата” при ошибках; высокая скорость обработки запросов (команда SELECT языка SQL; результатом выборки является таблица, которая содержит поля, удовлетворяющие заданному критерию); сама концепция объектных баз данных довольно сложна и требует от программистов серьезного и длительного обучения; относительно высокая скорость при работе с большими объемами данных. Кроме того, во всем мире значительные средства уже инвестированы в реляционные СУБД. Многие организации не уверены, что затраты, связанные с переходом на объектные базы данных, окупятся. Поэтому многие пользователи заинтересованы в комбинированном подходе, который бы им позволил воспользоваться достоинствами объектных баз данных, не отказываясь полностью от своих реляционных БД. Такие решения действительно существуют. Если переход от реляционной базы к объектной обходится слишком дорого, то применение последней в качестве расширения и дополнения реляционных СУБД часто является более экономичной альтернативой. Компромиссные решения позволяют соблюсти баланс между объектами и реляционными таблицами

11.Базы данных. Оператор выбора в SQL, его вид и разделы. Применение агрегатных функций в операторе выбора.

Операторы языка SQL можно условно разделить на два подъязыка: язык определения данных (Data Definition Language — DDL) и язык манипулирования данными (Data Manipulation Language — DML). Рассмотрим формат и основные возможности важнейших операторов, за исключением специфических операторов, отмеченных в таблице символом «*». Несущественные операнды и элементы синтаксиса (например, принятое во многих системах программирования правило ставить «;» в конце оператора) будем опускать. 1. Оператор создания таблицы имеет формат вида: CREATE TABLE <имя таблицы> (<имя столбца> <тип данных> [NOT NULL] [,<имя столбца> <тип данных> [NOT NULL]]) 2. Оператор удаления индекса имеет формат вида: DROP INDEX <имя индекса> Этот оператор позволяет удалять созданный ранее индекс с соответствующим именем. Так, например, для уничтожения индекса main_indx к таблице emp достаточно записать оператор DROP INDEX main_indx. 3. Оператор создания представления имеет формат вида: CREATE VIEW <имя представления> [(<имя столбца> [,<имя столбца> ]… )] AS <оператор SELECT> Данный оператор позволяет создать представление. Если имена столбцов в представлении не указываются, то будут использоваться имена столбцов из запроса, описываемого соответствующим оператором SELECT. 4. Оператор удаления представления имеет формат вида: DROP VIEW <имя представления> Оператор позволяет удалить созданное ранее представление. Заметим, что при удалении представления таблицы, участвующие в запросе, удалению не подлежат. Удаление представления rерr производится оператором вида: DROP VIEW repr. 5. Оператор выборки записей имеет формат вида: SELECT Это наиболее важный оператор из всех операторов SQL. Операторы языка SQL можно условно разделить на два подъязыка: язык определения данных (Data Definition Language — DDL) и язык манипулирования данными (Data Manipulation Language — DML). Операнд WHERE задает условия, которым должны удовлетворять записи в результирующей таблице. Выражение <условие выборки> является логическим. Его элементами могут быть имена столбцов, операции сравнения, арифметические oneрации, логические связки (И, ИЛИ, НЕТ), скобки, специальные функции LIKE, NULL, IN и т. д. Операнд GROUP BY позволяет выделять в результирующем множестве записей группы. Группой являются записи с совпадающими значениями в столбцах, перечисленных за ключевыми словами GROUP BY. Выделение групп требуется для использования в логических выражениях операндов WHERE и HAVING, а также для выполнения операций (вычислений) над группами. В логических и арифметических выражениях можно использовать следующие групповые операции (функции): AVG (среднее значение в группе), МАХ (максимальное значение в группе), MIN (минимальное значение в группе), SUM (сумма значений в группе), COUNT (число значений в группе). Операнд HAVING действует совместно с операндом GROUP BY и используется для дополнительной селекции записей во время определения групп. Правила записи <условия поиска> аналогичны правилам формирования <условия выборки> операнда WHERE. Операнд ORDER BY задает порядок сортировки результирующего множества. Обычно каждая <спецификация> аналогична соответствующей конструкции оператора CREATE INDEX и представляет собой пару вида: <имя столбца> [ ASC | DESC ].

12.Базы данных. Основные понятия: база данных, банк данных, СУБД.

Трехуровневая модель базы данных. База данных (БД) есть совокупность взаимосвязанных именованных данных, независимых от прикладных программ с общими правилами организации, описания, хранения и обработки. Базой данных называют совокупность значений взаимосвязанных элементов данных (атрибутов), отображающую состояние сущностей и их связей в конкретной предметной области. Автоматизированный банк данных (БнД) — это система информационных, ма¬тематических, программных, языковых, организационных и технических средств, пред¬назначенных для централизованного накопления и коллективного многоаспектного ис¬пользования данных в некоторой прикладной области. БнД включает в себя одну или несколько баз данных, систему управления ими (СУБД) и комплекс прикладных про¬грамм.УБД — это сложный комплекс программных и языковых средств, обеспечи¬вающих процессы создания, сопровождения и эксплуатации БД.Логический (модельный) уровень процесса накопления связан с физическим через программы, осуществляющие создание канонической структуры БД, схемы ее хранения и работу с дан¬ными (рис. 4.9). Каноническая структура БД создается с помощью модели выбора хранимых данных. Формализованное описание БД производится с помощью трех моделей: модели хранения данных (структура БД), модели актуализации данных и модели извлечения данных. Таким образом, переход к физической модели базы данных, реализуемой и используемой на компьютере, производится с помощью системы программ, позволяющих создать в памяти ЭВМ базу хранимых дан¬ных и работать с этими данными, т.е. извлекать, изменять, дополнять, уничтожать их. Эти программы называются СУБД. На рис. 4.9 программы, входящие в СУБД, заключены в пунк¬тирный прямоугольник. Современная СУБД содержит в своем составе програм¬мные средства создания баз данных, средства работы с дан¬ными и дополнительные, сервисные средства (рис. 4.10). С помощью средств создания БД проектировщик, используя язык описания данных (ЯОД), переводит логическую модель БД в физическую структуру, а на языке манипуляции данными (ЯМД) разрабатывает программы, реализующие основные операции с данными (в реляционных БД — это реляционные операции). При проектировании привлекаются визуальные средства, т.е. объекты, и программа-отладчик, с помощью ко¬торой соединяются и тестируются отдельные блоки разрабо¬танной программы управления конкретной БД. Средства работы с данными предназначены для пользова¬теля БД. Они позволяют установить удобный (как правило, графический многооконный) интерфейс с пользователем, создать необходимую функциональную конфигурацию экранного представления выводимой и вводимой информации (цвет, размер и количество окон, пиктограммы пользователя и т.д. и производить операции с данными БД, манипулируя текстовы¬ми и графическими экранными объектами. Дополнительные (сервисные) средства позволяют при про¬ектировании и использовании БД привлечь к работе с БД дру¬гие системы.

13.Базы данных. Понятие модели данных. Классификация моделей данных.

Модель данных — это некоторая абстракция, которая, будучи приложима к конкретным данным, позволяет пользователям и разработчикам трактовать их уже как информацию, то есть сведения, содержащие не только данные, но и взаимосвязь между ними. В соответствии с рассмотренной ранее трехуровневой архитектурой мы сталкиваемся с понятием модели данных по отношению к каждому уровню. И действительно, физическая модель данных оперирует категориями, касающимися организации внешней памяти и структур хранения, используемых в данной операционной среде. В настоящий момент в качестве физических моделей используются различные методы размещения данных, основанные на файловых структурах: это организация файлов прямого и последовательного доступа, индексных файлов и инвертированных файлов, файлов, использующих различные методы хэширования, взаимосвязанных файлов. Кроме того, современные СУБД широко используют страничную организацию данных. Физические модели данных, основанные на страничной организации, являются наиболее перспективными. Наибольший интерес вызывают модели данных, используемые на концептуальном уровне. По отношению к ним внешние модели называются подсхемами и используют те же абстрактные категории, что и концептуальные модели данных. Кроме трех рассмотренных уровней абстракции при проектировании БД существует еще один уровень, предшествующий им. Модель этого уровня должна выражать информацию о предметной области в виде, независимом от используемой СУБД. Эти модели называются инфологическими, или семантическими, и отражают в естественной и удобной для разработчиков и других пользователей форме информационно-логический уровень абстрагирования, связанный с фиксацией и описанием объектов предметной области, их свойств и их взаимосвязей. Инфологические модели данных используются на ранних стадиях проектирования для описания структур данных в процессе разработки приложения, а даталогические модели уже поддерживаются конкретной СУБД. Документальные модели данных соответствуют представлению о слабоструктурированной информации, ориентированной в основном на свободные форматы документов, текстов на естественном языке. Модели, основанные на языках разметки документов, связаны прежде всего со стандартным общим языком разметки — SGML (Standart Generalised Markup Language), который был утвержден ISO в качестве стандарта еще в 80-х годах. Этот язык предназначен для создания других языков разметки, он определяет допустимый набор тегов (ссылок), их атрибуты и внутреннюю структуру документа. Гораздо более простой и удобный, чем SGML, язык HTML позволяет определять оформление элементов документа и имеет некий ограниченный набор инструкций — тегов, при помощи которых осуществляется процесс разметки. Однако HTML сегодня уже не удовлетворяет в полной мере требованиям, предъявляемым современными разработчиками к языкам подобного рода. И ему на смену был предложен новый язык гипертекстовой разметки, мощный, гибкий и, одновременно с этим, удобный язык XML. XML (Extensible Markup Language) — это язык разметки, описывающий целый класс объектов данных, называемых XML-документами. Он используется в качестве средства для описания грамматики других языков и контроля за правильностью составления документов. То есть сам по себе XML не содержит никаких тегов, предназначенных для разметки, он просто определяет порядок их создания. Тезаурусные модели основаны на принципе организации словарей, содержат определенные языковые конструкции и принципы их взаимодействия в заданной грамматике. Эти модели эффективно используются в системах-переводчиках, особенно многоязыковых переводчиках. Принцип хранения информации в этих системах и подчиняется тезаурусным моделям. Дескрипторные модели — самые простые из документальных моделей, они широко использовались на ранних стадиях использования документальных баз данных. В этих моделях каждому документу соответствовал дескриптор — описатель. Этот дескриптор имел жесткую структуру и описывал документ в соответствии с теми характеристиками, которые требуются для работы с документами в разрабатываемой документальной БД.

14.Базы данных. Понятие транзакции. Свойства транзакций. SQL- операторы успешного завершения и отката транзакции.

Транзакция — это логически завершенная единица работы, содержащая одну или более элементарных операций обработки данных. Все действия, составляющие транз¬акцию, должны либо выполниться полностью, либо полностью не выполниться. Под транзакцией понимается последовательность операций над БД, рассматриваемых СУБД как единое целое (обслуживание запроса). Каждая транзакция начинается с целостного состояния БД и должна оставлять это состояние после своего завершения. Либо транзакция успешно выполняется и СУБД фиксирует изменения БД, произведенные ею, во внешней памяти, либо ни одно из этих изменений никак не отражается в состоянии БД. Таким образом, понятие транзакции необходимо для поддержания логической целостности Б Установка точки сохранения (начала транзакции) Откат изменений, сделанных с момента начала транзакции В большинстве СУБД элементарные команды, составляющие тело транзак¬ции, выполняются над некоторой буферной копией данных, и только если их уда¬ется успешно довести до конца, происходит окончательное обновление основ¬ной базы. Транзакция начинается от точки сохранения, задаваемой инструкцией SAVEPOINT, и может быть завершена по команде COMMIT или прервана по команде ROLLBACK (откат). Также в современных системах управления данными предусмотре¬ны средства автоматического отката транзакций при возникновении системных сбоев. Таким образом, механизм управления транзакциями является важнейшим инструментом поддержания целостности данных. Плоские, или традиционные, транзакции, характеризуются четырьмя классическими свойствами: атомарности, согласованности, изолированности, долговечности (прочности) — ACID (Atomicity, Consistency, Isolation, Durability). Иногда традиционные транзакции называют ACID-транзакциями. Упомянутые выше свойства означают следующее: •Свойство атомарности (Atomicity) выражается в том, что транзакция должна быть выполнена в целом или не выполнена вовсе. •Свойство согласованности (Consistency) гарантирует, что по мере выполнения транзакций данные переходят из одного согласованного состояния в другое — транзакция не разрушает взаимной согласованности данных. •Свойство изолированности (Isolation) означает, что конкурирующие за доступ к базе данных транзакции физически обрабатываются последовательно, изолированно друг от друга, но для пользователей это выглядит так, как будто они выполняются параллельно. •Свойство долговечности (Durability) трактуется следующим образом: если транзакция завершена успешно, то те изменения в данных, которые были ею произведены, не могут быть потеряны ни при каких обстоятельствах (даже в случае последующих ошибок).

15.Базы данных. Понятие целостности данных. Принципы и средства поддержки целостности в реляционной базе данных.

Эта характеристика подразумевает наличие средств, позволяющих удостовериться, что информация в базе данных всегда остается корректной и полной. Должны быть установлены правила целостности, и они должны храниться вместе с базой данных и соблюдаться на глобальном уровне. Целостность данных должна обеспечиваться независимо от того, каким образом данные заносятся в память (в интерактивном режиме, посредством импорта или с помощью специальной программы). К средствам обеспечения целостности данных на уровне СУБД относятся � встроенные средства для назначения первичного ключа, в том числе средства для работы с типом полей с автоматическим приращением, когда СУБД самостоятельно присваивает новое уникальное значение � средства поддержания ссылочной целостности, которые обеспечивают запись информации о связях таблиц и автоматически пресекают любую операцию, приводящую к нарушению ссылочной целостности. Некоторые СУБД имеют хорошо разработанный процессор СУБД для реализации таких возможностей, как уникальность первичных ключей, ограничение (пресечение) операций и даже каскадное обновление и удаление информации. В таких системах проверка корректности, назначаемая полю или таблице, будет проводиться всегда после изменения данных, а не только во время ввода информации с помощью экранной формы. Это свойство можно настраивать для каждого поля и для записи в целом, что позволяет контролировать не только значения отдельных полей, но и взаимосвязи между несколькими полями данной записи. 16.Базы данных. Проблемы параллельного выполнения транзакций. Сериализация транзакций Если с БД работают одновременно несколько пользователей, то обработка транзакций должна рассматриваться с новой точки зрения. В этом случае СУБД должна не только корректно выполнять индивидуальные транзакции и восстанавливать согласованное состояние БД после сбоев, но она призвана обеспечить корректную параллельную работу всех пользователей над одними и теми же данными. По теории каждый пользователь и каждая транзакция должны обладать свойством изолированности, то есть они должны выполняться так, как если бы только один пользователь работал с БД. И средства современных СУБД позволяют изолировать пользователей друг от друга именно таким образом. Однако в этом случае возникают проблемы замедления работы пользователей. Рассмотрим более подробно проблемы, которые возникают при параллельной обработке транзакций Основные проблемы, которые возникают при параллельном выполнении транзакций, делятся условно на 4 типа: · Пропавшие изменения. Эта ситуация может возникать, если две транзакции одновременно изменяют одну и ту же запись в БД. · Проблемы промежуточных данных. Когда данные изменяются несколько раз во время работы двух операторов. · Проблемы несогласованных данных. Когда данные изменяются одним из операторов, и другой получает два варианта до и после изменений. · Проблемы строк-призраков (строк-фантомов). Предположим, что администратор фирмы поручил секретарю напечатать итоговый отчет по результатам работы за текущий месяц. И допустим, что приложение печатает отчет в двух видах: в подробном и в укрупненном. В момент, когда приложение печати начало формировать свой первый вид отчета, один из операторов принимает еще один заказ, поэтому к моменту формирования укрупненного отчета в БД появились новые сведения о продажах, которые и были внесены в укрупненный отчет. Мы получили два отчета в одном приложении, которые содержат разные цифры и не совпадают друг с другом. Такое стало возможно потому, что приложение печати выполнило два одинаковых запроса и получило два разных результата. БД находится в согласованном состоянии, но приложение печати работает некорректно. Для того чтобы избежать подобных проблем, требуется выработать некоторую процедуру согласованного выполнения параллельных транзакций. Эта процедура должна удовлетворять следующим правилам: · В ходе выполнения транзакции пользователь видит только согласованные данные. Пользователь не должен видеть несогласованных промежуточных данных. · Когда в БД две транзакции выполняются параллельно, то СУБД гарантированно поддерживает принцип независимого выполнения транзакций, который гласит, что результаты выполнения транзакций будут такими же, как если бы вначале выполнялась транзакция 1, а потом транзакция 2, или наоборот, сначала транзакция 2, а потом транзакция 1. Такая процедура называется сериализацией транзакций. Фактически она гарантирует, что каждый пользователь (программа), обращающаясь к базе данных, работает с ней так, как будто не существует других пользователей (программ), одновременно с ним обращающихся к тем же данным. Сериализация транзакций — это механизм выполнения транзакций по некоторому сериальному плану. Обеспечение такого механизма является основной функцией компонента СУБД, ответственного за управление транзакциями. Система, в которой поддерживается сериализация транзакций обеспечивает реальную изолированность пользователей. Основная реализационная проблема состоит в выборе метода сериализации набора транзакций, который не слишком ограничивал бы их параллельность. Приходящим на ум тривиальным решением является действительно последовательное выполнение транзакций. Но существуют ситуации, в которых можно выполнять операторы разных транзакций в любом порядке с сохранением сериальности. Примерами могут служить только читающие транзакции, а также транзакции, не конфликтующие по объектам базы данных.

17.Базы данных. Проектирование БД методом нормализации.

Нормализация отношений – это формальный аппарат ограничений на их формирование, который позволяет устранить дублирование данных, обеспечить их непротиворечивость и уменьшить затраты на поддержание базы данных. Процесс проектирования представляет собой процесс нормализации схем отношений, причем каждая следующая нормальная форма обладает лучшими свойствами, чем предыдущая. Каждой нормальной форме соответствует некоторый определен1 ный набор ограничений, и отношение находится в некоторой нормальной форме, если удовлетворяет свойственному ей набору ограничений. В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм: • первая нормальная форма 1NF; • вторая нормальная форма 2NF; • третья нормальная форма 3NF; • нормальная форма Бойса – Кодда BCNF; • четвертая нормальная форма 4NF; • пятая нормальная форма 5NF’или нормальная форма проекции-соединения PJ/NF. INF, 2NF, 3NF ограничивают зависимость непервичных атрибутов от ключей, BCNF ограничивает зависимость первичных атрибутов, 4NF формулирует ограничения на виды многозначных зависимостей, 5NFвводит другие типы зависимостей – зависимости соединения. Каждая нормальная форма более высокого уровня предполагает, что анализируемое отношение уже находится в нормальной форме на уровень ниже рассматриваемой. Чем выше уровень нормальной формы, тем жестче накладываемые на отношение ограничения. Процесс перехода от нормальной формы более низкого уровня к нормальной форме более высокого уровня называется нормализацией отношения. Главная цель нормализации базы данных – устранение избыточности и дублирования информации. Как следствие, значительно сокращается вероятность появления противоречивых данных, облегчается администрирование базы и обновление информации в ней, сокращается объем дискового пространства. Отношение называется нормализованным или приведенным к первой нормальной форме (1NF), если все его атрибуты простые или атомарные (неделимые). Отношение, находящееся в первой нормальной форме, будет иметь следующие свойства: • в отношении нет одинаковых кортежей; • кортежи не упорядочены; • атрибуты не упорядочены и различаются по наименованиям; • все значения атрибутов атомарные. Вторая и третья нормальные формы возникли в результате стремления избежать аномалий обновления данных при работе с базой данных и избавиться от информационной избыточности в отношениях. Вторая нормальная форма применяется к отношениям с составным ключом, т.е. к таким отношениям, первичный ключ которых состоит из двух или более атрибутов. Чтобы таблица находилась в третьей нормальной форме, необходимо, чтобы не ключевые атрибуты в ней не зависели от других не ключевых атрибутов, а зависели только от первичного ключа. Нормальная форма Бойса – Кодда BCNF требует, чтобы в таблице был только один потенциальный первичный ключ. Если обнаружился второй столбец, позволяющий однозначно идентифицировать строку, то для приведения к нормальной форме Бойса – Кодда такие данные надо вынести в отдельную таблицу. Для приведения таблицы, находящейся в нормальной форме Бойса – Кодда, к четвертой нормальной форме необходимо устранить имеющиеся в ней многозначные зависимости. Нужно, чтобы вставка или удаление любой строки таблицы не требовали бы вставки, удаления или модификации других строк этой же таблицы.

18.Базы данных. Реляционная модель данных. Операции фильтрации, проецирования, условного соединения отношений и их реализация на языке SQL.

Концепция реляционной модели данных была предложена в 1969 году Эдгаром Коддом, известным специалистом в области баз данных, а в 1970 году она была им опубликованы. Реляционная модель представляет собой совокупность данных, состоящую из набора двумерных таблиц. В теории множеств таблице соответствует термин отношение (relation), физическим представлением которого является таблица, отсюда и название модели – реляционная. Реляционная модель является удобной и наиболее привычной формой представления данных. При табличной организации данных отсутствует иерархия элементов. Строки и столбцы могут быть просмотрены в любом порядке, поэтому высока гибкость выбора любого подмножества элементов в строках и столбцах. Любая таблица в реляционной базе состоит из строк, которые называют записями, и столбцов, которые называют полями. На пересечении строк и столбцов находятся конкретные значения данных. Для каждого поля определяется множество его значений, например, поле «Месяц» может иметь двенадцать значений. Структура таблицы в реляционной базе характеризуется следующим: •она состоит из совокупности столбцов; •каждый столбец имеет уникальное, то есть не повторяющееся в других столбцах, имя; •последовательность столбцов в таблице не существенна; •все строки таблицы организованы по одинаковой структуре, то есть имеют одно и то же количество реквизитов и имеют одинаковую длину; •в таблице нет одинаковых строк; •количество строк в таблице практически не ограничено; •последовательность строк в таблице не существенна; •при выполнении манипуляций с таблицей все строки и столбцы могут просматриваться в произвольном порядке безотносительно к их содержанию и смыслу. Один или несколько атрибутов, значения которых однозначно определяют кортеж отношения, называется его ключом, или первичным ключом, или ключевым полем. То есть ключевое поле – это такое поле, значения которого в данной таблице не повторяется. Все СУБД поддерживают в той или иной форме пять основных операций: •добавить в базу данных одну или несколько записей; •удалить одну или несколько записей; • найти в базе данных одну или несколько записей, удовлетворяющих заданному условию, •обработать эти записи, т.е. сформировать из них некоторый результат, • обновить в базе данных значения некоторых полей в одной или нескольких за¬писях. Перечисленные выше функции БД реализуются по запросам. На основе запросов могут быть сформированы отчеты. Для удобства работы с типичными в данных условиях запросами могут быть созданы специализированные приложения Важнейшим элементом любой СУБД являются средства ускоренного поиска дан¬ных — самой распространенной операции. Если прямой файл несет информацию о том, каковы свойства данных объек¬тов, то инвертированный — о том, какие объекты обладают заданным свойством. В исходном файле назначается атрибут по которому производится инверсия.

19.Базы данных. Репликации: назначение, средства реализации.

Типы репликаций.ии – это совокупность механизмов, обеспечивающих отображение изменений данных, сделанных на одном сервере, на другие серверы. Подсистема репликации организована в виде специализированных агентов, выполняемых на сервере, как самостоятельный процесс. Эти агенты подключаются к серверам — участникам репликации и выполняют создание копий данных и тиражирование их между другими серверами. Терминология репликации использует понятие издатель – Publisher, дистрибьютор – Distributor, подписчик – Subscription. Термин издатель употребляется для обозначения серверов, которые представляют информацию из своих баз данных другим серверам. Дистрибьютор — промежуточный сервер, принимающий данные от издателя и распространяющий их подписчикам. Подписчик – это сервер, копирующий информацию, предоставляемую издателем. Помимо уже упомянутых терминов при обслуживании репликации используется еще несколько: публикация – представляет собой набор статей. Подписчик может подписаться только целиком на публикацию. Одна публикация способна включать статьи, принадлежащие одной базе данных. Чтобы представить данные из нескольких баз данных придется создать отдельную публикацию в каждой из них. статья — статьей называется минимальный набор данных, рассматриваемый системой репликации как одно целое. Статья представляет собой таблицу или какую-то ее часть. Если необходимо выполнить тиражирование не всей таблицы, а только ее фрагмента, то необходимо использовать фильтрацию: — использование вертикального разделения, при которой в статью не включается одна или более колонок исходной таблицы; — использование горизонтального разделения, когда на строки, включаемые в статью, накладывается одно или более условий с помощью конструкции where. Средства репликации. Каждый из агентов репликации выполняет определенную роль. В процессе репликации участвует как минимум два агента Приведем список агентов подсистемы репликации SQL Server 2000: · Snapshot Agent;· Log Reader Agent;· Queue Reader Agent;· Distribution Agent;· Merge Agent; Типы репликации В SQL Server применяются три следующих базовых типа репликации: — Snapshot Replication – репликация моментальных снимков; — Transactional Replication – репликация транзакций; — Merge Replication – репликация сведением. Самым простым типом репликации является репликация моментальных снимков. Моментальный снимок представляет собой полную копию данных издателя, которые выбраны для репликации. Более сложным типом репликации является репликация транзакций… В основе ее работы лежит передача информации об изменениях данных. Репликация транзакций хорошо зарекомендовала себя в локальных сетях, которые обеспечивают постоянное соединение и высокую пропускную способность. В этом случае изображения могут отображаться практически мгновенно. Еще одним типом репликации является репликация сведением. Данный тип репликации позволяет подписчикам вносить изменения в данные без необходимости постоянного соединения с издателем. Репликация сведением является самым сложным типом репликации. Трудность состоит в отслеживании автономных изменений, сделанных участником репликации, и их объединение в главную копию.

20.Базы данных. Способы объединения таблиц в языке SQL.

Наиболее мощной особенностью языка SQL есть возможность сочетать различные таблицы в оперативной памяти СУБД при выполнении запросов. Объединение очень часто используются для анализа данных. Как правило, данные находятся в разных таблицах, что позволяет их более эффективно хранить (поскольку информация НЕ дублируется), упрощает обработку данных и позволяет масштабировать базу данных (возможно добавлять новые таблицы с дополнительной информацией). Таблицы баз данных, которые используются в СУБД Access являются реляционными таблицами, т.е. все таблицы можно связать между собой по общим полям. Объединение таблиц очень простая процедура. Нужно указать все таблицы, которые будут включены в объединение и «объяснить» СУБД, как они будут связаны между собой. Объединение делается с помощью слова WHERE, например: SELECT DISTINCT Seller_name, Product FROM Sellers, Sumproduct WHERE Sellers.City = Sumproduct.City Существует также и другой способ объединения таблиц, который явно указывает на тип объединения. Рассмотрим следующий пример: SELECT DISTINCT Seller_name, Product FROM Sellers INNER JOIN Sumproduct ON Sellers.City = Sumproduct.City В этом запросе вместо WHERE мы использовали конструкцию INNER JOIN … ON … , которая дала аналогичный результат. Несмотря на то, что объединение с предложением WHERE короче, все же лучше использовать INNER JOIN, поскольку она является более гибкой, о чем будет подробнее рассказано в следующих разделах. Существует несколько способов объеденения таблиц. Для каждого определенного случая, есть свой способ. Хотя бывает один и тот же случай, который можно решить разными методами объеденения таблиц. В Oracle SQL имеется следующие типы объеденения: •EQUIJOIN – объеденения по равенству •NONEQUIJOIN — объеденения по не равенству •OUTER JOIN – внешнее соединения •SELF JOIN – самообъеденение •CROSS JOINS — декартовое пересечение •NATURAL JOINS – простое объеденения таблиц по одинаковым столбцам •USING CLAUSE •Full or two sided OUTER JOINS •Arbitrary JOIN conditions for OUTER JOINS

21.Базы данных. Средства автоматизации обработки данных. Триггеры: назначение, проектирование, использование.

Правила. Механизм правил (триггеров) позволяет программировать обработку ситуаций, возникающих при любых изменениях в БД. Правило (триггер) представляет собой подпрограмму, которая придается таблице БД и активизируется при выполнении над ней операций включения, удаления или обновления строк, а также при изменении значений в столбцах таблицы. Применение правила заключается в проверке сформулированных в нем условий, при выполнении которых происходит вызов специфицированной внутри правила процедуры БД. Важно, что правило может быть применено как до, так и после выполнения операции обновления, следовательно, возможна отмена операции. Таким образом, правило позволяет определить реакцию сервера на любое изменение состояния БД. Правила (так же, как и процедуры) хранятся непосредственно в БД независимо от прикладных программ. Важнейшая цель механизма триггеров — обеспечить целостность БД Типы триггеров В SQL Server существует два параметра, определяющих поведение триггеров: •AFTER. Триггер выполняется после успешного выполнения вызвавших его команд. Если же команды по какой-либо причине не могут быть успешно завершены, триггер не выполняется. Следует отметить, что изменения данных в результате выполнения запроса пользователя и выполнение триггера осуществляется в теле одной транзакции: если произойдет откат триггера, то будут отклонены и пользовательские изменения. Можно определить несколько AFTER-триггеров для каждой операции (INSERT, UPDATE, DELETE). Если для таблицы предусмотрено выполнение нескольких AFTER-триггеров, то с помощью системной хранимой процедуры sp_settriggerorder можно указать, какой из них будет выполняться первым, а какой последним. По умолчанию в SQL Server все триггеры являются AFTER-триггерами. •INSTEAD OF. Триггер вызывается вместо выполнения команд. В отличие от AFTER-триггера INSTEAD OF-триггер может быть определен как для таблицы, так и для просмотра. Для каждой операции INSERT, UPDATE, DELETE можно определить только один INSTEAD OF-триггер. Триггеры различают по типу команд, на которые они реагируют. Сущестует три типа триггеров: •INSERT TRIGGER – запускаются при попытке вставки данных с помощью команды INSERT. •UPDATE TRIGGER – запускаются при попытке изменения данных с помощью команды UPDATE. •DELETE TRIGGER – запускаются при попытке удаления данных с помощью команды DELETE.

22.Базы данных. Средства защиты данных в базах данных.

Принято считать самой популярной системой управления базами данных для персональных компьютеров продукт, впервые появившийся в 1992 году и носящий название Microsoft Access. Microsoft Access — это полнофункциональная реляционная СУБД. В ней предусмотрены все необходимые средства для определения и обработки данных, а так же для управления ими при работе с большими объемами информации. Информация, имеющая определенную ценность, нуждается в защите, как от «дурака», так и от несанкционированного доступа. Защита паролем, сохранение базы данных в виде MDE-файла (в этом случае базу данных можно открывать для просмотра, но не для изменения) могут «закрыть» для случайного пользователя возможности, которые не разрешается использовать. Но опытный пользователь Access может открыть базу данных при нажатой клавише Shift (чтобы не запустить приложение), изучить исходные тексты процедур и определить, как «взломать» защиту. Чтобы действительно предотвратить несанкционированный доступ к объектам этой базы, необходимо использовать средства защиты, встроенные в Access. Вряд ли существует абсолютно надежная компьютерная система защиты. Хотя средства защиты Microsoft Access считаются одними из лучших для персональных компьютеров, найдутся умельцы, которые при наличии времени смогут проникнуть в вашу защищённую базу данных Access. Если нужна более надежная защита данных, подумайте о переходе к другой системе управления базами данных класса Microsoft SQL Server. 1. Архитектура защиты Access Access хранит информацию о защите в двух местах. Во время установки программа Setup создаст в папке \Program Files\Microsoft Ofice\0ffice стандартный файл рабочей группы (System.mdw), который впоследствии используется по умолчанию при запуске Access. Этот файл содержит информацию обо всех пользователях и группах. 2. Пользователи, группы и разрешения В общем случае компьютерная система защиты может быть открытой или закрытой. В открытой системе доступ, если только он не запрещен специально, предоставляется всем пользователям. В закрытой системе доступ предоставляется только тем, кому он был назначен 3. Встроенные пользователи и группы При установке Access всегда создается стандартная рабочая группа, содержащая один встроенный код пользователя и два встроенных кода групп. Код пользователя называется Admin, и для него не определен пароль. Access автоматически загружает вас с этим кодом и предоставляет вам все права к привилегии этого пользователя. Первой встроенной группой является группа Users. Все пользователи, в том числе и новые, становятся ее членами и не могут быть удалены из нее. Вторая встроенная группа называется Admins. Ее внутренний идентификатор уникален для каждого файла рабочей группы и определяется на основе информации, которую вы предоставляете программе администратора рабочих групп при создании файла. По умолчанию в эту группу включен только пользователь Admin. 4. Явные и неявные разрешения Поскольку пользователи всегда являются членами группы Users, которой по умолчанию предоставляются все права доступа к любому новому объекту, любой другой пользователь, а не только Admin, может получить полный доступ ко всем вашим объектам. Чтобы проверить разрешения пользователя или группы, сначала откройте нужную базу данных. Вы должны быть владельцем базы данных и всех объектов, которые хотите проверить, или иметь разрешение администратора на доступ к базе данных и объектам. 5. Использование мастера защиты Microsoft предоставляет мастера, помогающего установить защиту на уровне пользователя 6. Настройка защищенной базы данных После создания защищенной базы данных нужно определить новые группы и пользователей, чтобы облегчить предоставление нужных вам разрешений. Вы можете создать только новых пользователей, но в этом случае вам придется назначать разрешения каждому пользователю индивидуально. Значительно удобнее определить по одной группе для каждого уровня доступа, который вы намерены предоставить, затем определить пользователей и включить их в соответствующие группы.

23.Базы данных. Теоретико-множественные операции над отношениями

Объединением двух отношений называется отношение, содержащее множество кортежей, принадлежащих либо первому, либо второму исходным отношениям, либо обоим отношениям одновременно. Пусть заданы два отношения где r1и r2 – соответственно кортежи отношений R1 и R2, то объединение Здесь r – кортеж нового отношения, Ú – операция логического сложения «ИЛИ». Исходными отношениями являются отношения R1 и R2, которые содержат перечни деталей, изготавливаемых соответственно на первом и втором участках цеха. Отношение R3 содержит общий перечень деталей, изготавливаемых в цеху, то есть характеризует общую номенклатуру цеха. Пересечением отношений называется отношение, которое содержит множество кортежей, принадлежащих одновременно и первому и второму отношениям. R1 и R2 В отношении R4 содержатся перечень деталей, которые выпускаются одновременно на двух участках цеха (рис. 2.8). Разностью отношений R1 и R2 называется отношение, содержащее множество кортежей, принадлежащих R1 и не принадлежащих R2: Отношение R5 содержит перечень деталей, изготавливаемых только на участке 1, отношение R6 содержит перечень деталей, изготавливаемых только на участке 2 Следует отметить, что первые две операции, объединение и пересечение, являются коммутативными операциями, то есть результат операции не зависит от порядка аргументов в операции. Операция же разности является принципиально несимметричной операцией, то есть результат операции будет различным для разного порядка аргументов, что и видно из сравнения отношений R5 и R6.

24.Базы данных. Технологии OLTP и OLAP.

OLTP-технология ориентирована на оперативную обработку данных, а более современная OLAP-технология — на интерактивный анализ данных. Системы, разработанные на их основе, позволяют достигнуть понимания процессов, происходящих на объекте управления, путем оперативного доступа к разнообразным срезам данных (представлениям содержимого баз данных, организованным так, чтобы отразить различные аспекты деятельности предприятия). В частности, обеспечивая графическое представление данных, OLAP способна сделать результаты обработки данных легкими для восприятия. OLTP (Online Transaction Processing) — обработка транзакций в реальном времени. Способ организации БД, при котором система работает с небольшими по размерам транзакциями, но идущими большим потоком, и при этом клиенту требуется от системы максимально быстрое время ответа. Задачи OLTP-системы – это быстрый сбор и наиболее оптимальное размещение информации в базе данных, а также обеспечение ее полноты, актуальности и согласованности. Однако такие системы не предназначены для максимально эффективного, быстрого и многоаспектного анализа. 1. Сервер БД, фиксирующий распределенную транзакцию посылает команду «Приготовиться к фиксации» всем узлам сети, зарегистрированным для выполнения транзакций. Если хотя бы один из серверов не дает ответа о готовности, то сервер распределенной БД совершает откат локальной транзакции на всех узлах. 2. Все локальные СУБД готовы к фиксации, т.е. сервер обрабатывает распределенную транзакцию, заканчивает ее фиксацию, посылая команду зафиксировать транзакцию всем локальным серверам. OLAP — технология обработки информации, включающая составление и динамическую публикацию отчётов и документов. Используется аналитиками для быстрой обработки сложных запросов к базе данных. Служит для подготовки бизнес-отчётов по продажам, маркетингу, в целях управления, т. н. data mining — добыча данных OLAP делает мгновенный снимок реляционной БД и структурирует её в пространственную модель для запросов. Заявленное время обработки запросов в OLAP составляет около 0,1 % от аналогичных запросов в реляционную БД. Классификация OLAP: • MOLAP (Multidimensional OLAP – многомерный OLAP) • ROLAP (Relational OLAP – реляционный OLAP) • HOLAP (Hybrid OLAP – гибридный OLAP) • Real-time ROLAP (ROLAP реального времени) • DOLAP (Desktop OLAP – настольный OLAP) • WOLAP (Web-based OLAP – OLAP ориентированный наWeb) • SOLAP (Spatial OLAP – пространственный OLAP) • Mobile OLAP (OLAP для мобильных устройств) • JOLAP (Java OLAP)10 Применение OLAP на практике: • Анализ финансовых показателей деятельности предприятия • Корпоративная отчетность • Анализ бюджетных данных • Анализ клиентской базы • Анализ складских данных • Анализ продаж • Анализ закупок и цен • Анализ посещаемости Web-сайта • Публикация маркетинговых исследований • Создание информационного сервиса. Потенциально применение таких продуктов возможно везде, где происходит сбор информации и требуется ее анализ OLTP технология OLTP (оперативная транзакционная обработка данных) -способ организации базы данных, при котором система работает с транзакциями небольшими по размерам, но идущими большим потоком, и при этом клиенту требуется от системы максимально быстрое время ответа Использование OLTP: • банковские и биржевые операции • регистрация прохождения детали на конвейере • фиксация в статистике посещений очередного посетителя веб-сайта • автоматизация бухгалтерского, складского учёта и учёта документов

25.Базы данных. Физическое моделирование. Классификация файловых структур баз данных

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

26.Базы данных. Хранилище данных

Хранилище данных (ХД) – DATA WAREHOUSES (DW) – это совокупность информационно-технологических и программно-технических средств и методов, обеспечивающих единую среду хранения корпоративных данных, оптимизированных для выполнения аналитических операций. Информационные хранилища предназначены для обработки больших объемов данных в режиме реального времени. Хранилища используют для принятия тактических и стратегических решений. К информационному хранилищу присоединяют программные продукты, основанные на интеллектуальной основе. Принципы организации и особенности хранилищ данных: 1. Хранилища данных содержат информацию, собранную из нескольких оперативных баз данных. Данные, описывающие определенные области, объединяют в категории. Т.е. информационные хранилища имеют предметную ориентацию и строятся с учетом предметной ориентации данных. 2. В Хранилищах данные разделяются еще и по предназначению: отдельно данные, используемые для обработки, отдельно данные, используемые для анализа. 3. Данные в Хранилище данных поступают из нескольких источников. При хранении они не изменяются, не удаляются, только накапливаются. 4. Хранилища по размеру значительно больше оперативных баз данных (размер хранилища обычно имеет объем от сотен гигабайт до нескольких терабайт). 5. Хранилища данных создаются специально для приложений поддержки принятия решений и предоставляют накопленные за определенное время, сводные и консолидированные данные, которые более приемлемы для анализа, чем детальные индивидуальные записи. 6. Хранилища данных жестко зависят от времени. Они четко привязываются к определенному промежутку времени. Иначе данные не будут достоверными. 7. Интеграция ранее разъединенных детализированных данных (исторические архивы, данные из традиционных систем обработки документов, разрозненных баз данных, данные из внешних источников) в едином хранилище данных. 8. Информационные хранилища представляет собой базу данных с иерархической файловой системой хранения и миграцией данных. Информационные хранилища размещаются на серверах и библиотеках – автоматах. Двухуровневое хранилище данных (см. рис.23) строится централизованно для предоставления информации в рамках компании. Для поддержки такой архитектуры необходима выделенная команда профессионалов в области хранилищ данных. Такая организация хранения данных требует от компании полного согласования всех процессов обработки и преобразования данных. Преимущества: · Данные хранятся в единственном экземпляре, поэтому отсутствуют проблемы, связанные с синхронизацией нескольких копий данных. · Затраты на хранение данных сокращаются. · Данные объединяются (консолидируются) на уровне предприятия, что позволяет иметь единую картину бизнеса. Недостатки: · Данные не структурируются для поддержки потребностей отдельных пользователей или групп пользователей. · Возможны проблемы с производительностью системы. · Возможны трудности с разграничением прав пользователей на доступ к данным.

27.Базы данных. Язык SQL. Вычисления и подведение итогов в запросах.

В общем случае для создания вычисляемого (производного) поля в списке SELECT следует указать некоторое выражение языка SQL. В этих выражениях применяются арифметические операции сложения, вычитания, умножения и деления, а также встроенные функции языка SQL. Можно указать имя любого столбца (поля) таблицы или запроса, но использовать имя столбца только той таблицы или запроса, которые указаны в списке предложения FROM соответствующей инструкции. При построении сложных выражений могут понадобиться скобки. Стандарты SQL позволяют явным образом задавать имена столбцов результирующей таблицы, для чего применяется фраза AS. Использование итоговых функций С помощью итоговых (агрегатных) функций в рамках SQL-запроса можно получить ряд обобщающих статистических сведений о множестве отобранных значений выходного набора. Пользователю доступны следующие основные итоговые функции: •Count (Выражение) — определяет количество записей в выходном наборе SQL-запроса; •Min/Max (Выражение) — определяют наименьшее и наибольшее из множества значений в некотором поле запроса; •Avg (Выражение) — эта функция позволяет рассчитать среднее значение множества значений, хранящихся в определенном поле отобранных запросом записей. Оно является арифметическим средним значением, т.е. суммой значений, деленной на их количество. •Sum (Выражение) — вычисляет сумму множества значений, содержащихся в определенном поле отобранных запросом записей. Чаще всего в качестве выражения выступают имена столбцов. Выражение может вычисляться и по значениям нескольких таблиц. Все эти функции оперируют со значениями в единственном столбце таблицы или с арифметическим выражением и возвращают единственное значение. Функции COUNT, MIN и MAX применимы как к числовым, так и к нечисловым полям, тогда как функции SUM и AVG могут использоваться только в случае числовых полей, за исключением COUNT(*). При вычислении результатов любых функций сначала исключаются все пустые значения, после чего требуемая операция применяется только к оставшимся конкретным значениям столбца. Вариант COUNT(*) — особый случай использования функции COUNT, его назначение состоит в подсчете всех строк в результирующей таблице, независимо от того, содержатся там пустые, дублирующиеся или любые другие значения. Если до применения обобщающей функции необходимо исключить дублирующиеся значения, следует перед именем столбца в определении функции поместить ключевое слово DISTINCT. Оно не имеет смысла для функций MIN и MAX, однако его использование может повлиять на результаты выполнения функций SUM и AVG, поэтому необходимо заранее обдумать, должно ли оно присутствовать в каждом конкретном случае. Кроме того, ключевое слово DISTINCT может быть указано в любом запросе не более одного раза. Очень важно отметить, что итоговые функции могут использоваться только в списке предложения SELECT и в составе предложения HAVING. Во всех других случаях это недопустимо. Если список в предложении SELECT содержит итоговые функции, а в тексте запроса отсутствует фраза GROUP BY, обеспечивающая объединение данных в группы, то ни один из элементов списка предложения SELECT не может включать каких-либо ссылок на поля, за исключением ситуации, когда поля выступают в качестве аргументов итоговых функций. Предложение GROUP BY Часто в запросах требуется формировать промежуточные итоги, что обычно отображается появлением в запросе фразы «для каждого…». Для этой цели в операторе SELECT используется предложение GROUP BY. Предложение HAVING При помощи HAVING отражаются все предварительно сгруппированные посредством GROUP BY блоки данных, удовлетворяющие заданным в HAVING условиям. Это дополнительная возможность «профильтровать» выходной набор. Условия в HAVING отличаются от условий в WHERE: •HAVING исключает из результирующего набора данных группы с результатами агрегированных значений; •WHERE исключает из расчета агрегатных значений по группировке записи, не удовлетворяющие условию; •в условии поиска WHERE нельзя задавать агрегатные функции.

28.Базы данных. Язык SQL. Индексирование.

SQL (structured query language — «язык структурированных запросов») — формальный непроцедурный язык программирования, применяемый для создания, модификации и управления данными в произвольной реляционной базе данных, управляемой соответствующей системой управления базами данных (СУБД). SQL основывается на исчислении кортежей. SQL является прежде всего информационно-логическим языком, предназначенным для описания, изменения и извлечения данных, хранимых в реляционных базах данных. SQL можно назвать языком программирования, при этом он не является тьюринг-полным, но вместе с тем стандарт языка спецификацией SQL/PSM предусматривает возможность его процедурных расширений. Изначально SQL был основным способом работы пользователя с базой данных и позволял выполнять следующий набор операций: •создание в базе данных новой таблицы; •добавление в таблицу новых записей; •изменение записей; •удаление записей; •выборка записей из одной или нескольких таблиц (в соответствии с заданным условием); •изменение структур таблиц. Со временем SQL усложнился — обогатился новыми конструкциями, обеспечил возможность описания и управления новыми хранимыми объектами (например, индексы, представления, триггеры и хранимые процедуры) — и стал приобретать черты, свойственные языкам программирования. Важнейшим элементом любой СУБД являются средства ускоренного поиска данных. Данный механизм обычно реализуется с помощью индексных файлов (индексов), которые содержат упорядоченные по содержимому некоторого поля ссылки на записи основного файла. Все команда просмотра , корректировки, удаления записей перемещают указатель в соответствии с индексом, а не с физическим порядком расположения записи. Индексные файлы бывают двух типов: * Прямой. * Инвертированный Прямой файл — несёт информацию о том, каковы свойства данных объектов. Инвертированный файл — о том, какие объекты обладают заданным свойством. В исходном файле назначается атрибут, по которому производится инверсия. Область значений атрибута разбивается на диапазоны. Инвертированные списки образуются записями исходного файла, соответствующими одному диапазону атрибута

29.Базы данных. Язык SQL. Представления. Назначение и создание.

Представления, или просмотры (VIEW), представляют собой временные, производные (иначе — виртуальные) таблицы и являются объектами базы данных, информация в которых не хранится постоянно, как в базовых таблицах, а формируется динамически при обращении к ним. Обычные таблицы относятся к базовым, т.е. содержащим данные и постоянно находящимся на устройстве хранения информации. Представление не может существовать само по себе, а определяется только в терминах одной или нескольких таблиц. Применение представлений позволяет разработчику базы данных обеспечить каждому пользователю или группе пользователей наиболее подходящие способы работы с данными, что решает проблему простоты их использования и безопасности. Содержимое представлений выбирается из других таблиц с помощью выполнения запроса, причем при изменении значений в таблицах данные в представлении автоматически меняются. Представление — это фактически тот же запрос, который выполняется всякий раз при участии в какой-либо команде. Результат выполнения этого запроса в каждый момент времени становится содержанием представления. У пользователя создается впечатление, что он работает с настоящей, реально существующей таблицей. У СУБД есть две возможности реализации представлений. Если его определение простое, то система формирует каждую запись представления по мере необходимости, постепенно считывая исходные данные из базовых таблиц. В случае сложного определения СУБД приходится сначала выполнить такую операцию, как материализация представления, т.е. сохранить информацию, из которой состоит представление, во временной таблице. Затем система приступает к выполнению пользовательской команды и формированию ее результатов, после чего временная таблица удаляется. Представление — это предопределенный запрос, хранящийся в базе данных, который выглядит подобно обычной таблице и не требует для своего хранения дисковой памяти. Для хранения представления используется только оперативная память. В отличие от других объектов базы данных представление не занимает дисковой памяти за исключением памяти, необходимой для хранения определения самого представления. Параметр WITH ENCRYPTION предписывает серверу шифровать SQL-код запроса, что гарантирует невозможность его несанкционированного просмотра и использования. Если при определении представления необходимо скрыть имена исходных таблиц и столбцов, а также алгоритм объединения данных, необходимо применить этот аргумент. Параметр WITH CHECK OPTION предписывает серверу исполнять проверку изменений, производимых через представление, на соответствие критериям, определенным в операторе SELECT. Это означает, что не допускается выполнение изменений, которые приведут к исчезновению строки из представления. Такое случается, если для представления установлен горизонтальный фильтр и изменение данных приводит к несоответствию строки установленным фильтрам. Использование аргумента WITH CHECK OPTION гарантирует, что сделанные изменения будут отображены в представлении. Если пользователь пытается выполнить изменения, приводящие к исключению строки из представления, при заданном аргументе WITH CHECK OPTION сервер выдаст сообщение об ошибке и все изменения будут отклонены. Актуальность Изменения данных в любой из таблиц базы данных, указанных в определяющем запросе, немедленно отображается на содержимом представления. Повышение защищенности данных Права доступа к данным могут быть предоставлены исключительно через ограниченный набор представлений, содержащих только то подмножество данных, которое необходимо пользователю. Подобный подход позволяет существенно ужесточить контроль за доступом отдельных категорий пользователей к информации в базе данных 30.Базы данных. Язык SQL. Хранимые процедуры, их создание и использование. Хранимые процедуры представляют собой группы связанных между собой операторов SQL, применение которых делает работу программиста более легкой и гибкой, поскольку выполнить хранимую процедуру часто оказывается гораздо проще, чем последовательность отдельных операторов SQL. Хранимые процедуры представляют собой набор команд, состоящий из одного или нескольких операторов SQL или функций и сохраняемый в базе данных в откомпилированном виде. Выполнение в базе данных хранимых процедур вместо отдельных операторов SQL дает пользователю следующие преимущества: •необходимые операторы уже содержатся в базе данных; •все они прошли этап синтаксического анализа и находятся в исполняемом формате; перед выполнением хранимой процедуры SQL Server генерирует для нее план исполнения, выполняет ее оптимизацию и компиляцию; •хранимые процедуры поддерживают модульное программирование, так как позволяют разбивать большие задачи на самостоятельные, более мелкие и удобные в управлении части; •хранимые процедуры могут вызывать другие хранимые процедуры и функции; •хранимые процедуры могут быть вызваны из прикладных программ других типов; •как правило, хранимые процедуры выполняются быстрее, чем последовательность отдельных операторов; •хранимые процедуры проще использовать: они могут состоять из десятков и сотен команд, но для их запуска достаточно указать всего лишь имя нужной хранимой процедуры. Это позволяет уменьшить размер запроса, посылаемого от клиента на сервер, а значит, и нагрузку на сеть. Хранение процедур в том же месте, где они исполняются, обеспечивает уменьшение объема передаваемых по сети данных и повышает общую производительность системы. Применение хранимых процедур упрощает сопровождение программных комплексов и внесение изменений в них. Обычно все ограничения целостности в виде правил и алгоритмов обработки данных реализуются на сервере баз данных и доступны конечному приложению в виде набора хранимых процедур, которые и представляют интерфейс обработки данных. Для обеспечения целостности данных, а также в целях безопасности, приложение обычно не получает прямого доступа к данным – вся работа с ними ведется путем вызова тех или иных хранимых процедур. Создание хранимой процедуры предполагает решение следующих задач: •определение типа создаваемой хранимой процедуры: временная или пользовательская. Кроме этого, можно создать свою собственную системную хранимую процедуру, назначив ей имя с префиксом sp_ и поместив ее в системную базу данных. Такая процедура будет доступна в контексте любой базы данных локального сервера; •планирование прав доступа. При создании хранимой процедуры следует учитывать, что она будет иметь те же права доступа к объектам базы данных, что и создавший ее пользователь; •определение параметров хранимой процедуры. Подобно процедурам, входящим в состав большинства языков программирования, хранимые процедуры могут обладать входными и выходными параметрами; •разработка кода хранимой процедуры. Код процедуры может содержать последовательность любых команд SQL, включая вызов других хранимых процедур. В SQL Server имеется несколько типов хранимых процедур. •Системные хранимые процедуры предназначены для выполнения различных административных действий. Практически все действия по администрированию сервера выполняются с их помощью. Можно сказать, что системные хранимые процедуры являются интерфейсом, обеспечивающим работу с системными таблицами, которая, в конечном счете, сводится к изменению, добавлению, удалению и выборке данных из системных таблиц как пользовательских, так и системных баз данных. Системные хранимые процедуры имеют префикс sp_, хранятся в системной базе данных и могут быть вызваны в контексте любой другой базы данных. •Пользовательские хранимые процедуры реализуют те или иные действия. Хранимые процедуры – полноценный объект базы данных. Вследствие этого каждая хранимая процедура располагается в конкретной базе данных, где и выполняется. •Временные хранимые процедуры существуют лишь некоторое время, после чего автоматически уничтожаются сервером. Они делятся на локальные и глобальные. Локальные временные хранимые процедуры могут быть вызваны только из того соединения, в котором созданы. При создании такой процедуры ей необходимо дать имя, начинающееся с одного символа #. Как и все временные объекты, хранимые процедуры этого типа автоматически удаляются при отключении пользователя, перезапуске или остановке сервера. Глобальные временные хранимые процедуры доступны для любых соединений сервера, на котором имеется такая же процедура. Для ее определения достаточно дать ей имя, начинающееся с символов ##. Удаляются эти процедуры при перезапуске или остановке сервера, а также при закрытии соединения, в контексте которого они были созданы.