1. Большая безопасность и меньший сетевой трафик.

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

2. Sql можно оптимизировать

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

3. Совместное использование кода:

• меньшее количество работы;

• стандартизированная обработка;

• специализация между разработчиками.

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

31. Физическая организация БД: структура памяти ЭВМ, представление экземпляра логической записи в памяти ЭВМ, организация обмена между оперативной и внешней памятью.

32. Защита БД: проверка подлинности, проверка полномочий.

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

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

33. Защита БД: средства защиты БД.

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

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

• парольная защита;

• шифрование данных и программ;

• установление прав доступа к объектам БД;

• защита полей и записей таблиц БД.

34. Архитектура системы безопасности MS SQL Server: учетные записи, пользователи БД, режимы аутентификации.

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

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

SQL Server 2000 может использовать два режима аутентификации пользователей:

• режим аутентификации средствами Windows;

• смешанный режим аутентификации (Windows Authentication and SQL Server Authentication).

Смешанный режим позволяет пользователям регистрироваться как средствами Windows, так и средствами SQL Server.

35. Архитектура системы безопасности MS SQL Server: управление пользователями, пользователи dbо и guest, владелец объекта, обращение к таблицам БД.

Чтобы разрешить этим пользователям обращаться к серверу, создайте для них учетные записи в SQL Server либо предоставьте им доступ посредством учетных записей в домене, если вы используете систему безопасности Windows. Разрешение доступа к серверу не дает автоматически доступа к базе данных и ее объектам.

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

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

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

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

36. Архитектура системы безопасности MS SQL Server: понятие роли, стандартные роли сервера, стандартные роли БД, роли приложений.

Итак, на уровне сервера система безопасности оперирует следующими понятиями:

• аутентификация (authentication);

• учетная запись (login);

• встроенные роли сервера (fixed server roles).

На уровне базы данных используются следующие понятия:

• пользователь базы данных (database user);

• фиксированная роль базы данных (fixed database role);

• пользовательская роль базы данных (users database role);

• роль приложения (application role).

Встроенная роль сервера	Назначение
Sysadmin	Может выполнять любые действия в SQL Server
Serveradmin	Выполняет конфигурирование и выключение сервера
Setupadmin	Управляет связанными серверами и процедурами, автоматически запускающимися при старте SQL Server
Securityadmin	Управляет учетными записями и правами на создание базы данных, также может читать журнал ошибок
Processadmin	Управляет процессами, запущенными в SQL Server
Dbcreator	Может создавать и модифицировать базы данных
Diskadmin	Управляет файлами SQL Server
Bulkadmin	Члены роли Bulkadmin могут вставлять данные с использованием средств массивного копирования, не имея непосредственного доступа к таблицам

В роль базы данных можно включать:

• пользователей SQL Server;

• роли SQL Server;

• пользователей Windows;

• группы Windows, которым предварительно предоставлен доступ к нужной базе данных.

Встроенная роль баз данных	Назначение
db__owner	Имеет все права в базе данных
db_accessadmin	Может добавлять или удалять пользователей
db_securityadmin	Управляет всеми разрешениями, объектами, ролями и членами ролей
db_ddladmin	Может выполнять любые команды DDL, кроме GRANT, DENY и REVOKE
db_backupoperator	Может выполнять команды DBCC, CHECKPOINT и BACKUP
db_datareader	Может просматривать любые данные в любой таблице БД
db_datawriter	Может модифицировать любые данные в любой таблице БД
db_denydatareader	Запрещается просматривать данные в любой таблице
db_denydatawriter	Запрещается модифицировать данные в любой таблице

37. Архитектура системы безопасности MS SQL Server: права доступа к объектам БД, права доступа на выполнение команд T-SQL, неявные права (разрешения), запрещение доступа.

38. Понятие и архитектура системы поддержки принятия решений.

39. Понятие хранилища данных. Физические и виртуальные хранилища данных. Проблематика построения хранилищ данных.

Физические модели данных служат для отображения логических моделей данных. Основными понятиями логической модели данных являются поле, логическая запись, логический файл. Слово «логический» введено, чтобы отличать понятия, относящиеся к логической модели данных, от понятий, относящихся к физической модели данных. Основными понятиями физической модели данных, используемыми для представления логической модели данных, являются поле, физическая запись, физический файл. В частности, логическая запись, состоящая из полей, может быть представлена в виде физической записи (из тех же полей), логический файл – в виде физического файла. Прежде чем конкретизировать понятия, относящиеся к физической модели данных, рассмотрим структуру памяти ЭВМ.

40. Витрины данных.

41. Понятие OLAP. Категории данных в хранилище данных (ХД). Информационные потоки в ХД.

42. Структура OLAP-куба. Иерархия измерений OLAP-кубов. Операции, выполняемые над гиперкубом.

43. Технология OLAP: таблица фактов, типы фактов, таблицы измерений.

44. Архитектура OLAP-систем. Клиентские и серверные OLAP-средства. Технические аспекты многомерного хранения данных: MOLAP, HOLAP.

45. Технические аспекты многомерного хранения данных: ROLAP, схема «звезда», схема «снежинка».

46. Параллельная обработка данных: необходимость в атомарных транзакциях

В большинстве приложений баз данных работа пользователей организована в фор­ме транзакций (transactions), известных также как логические единицы работы (logical units of work, LUW). Транзакция - это последовательность действий с базой данных, в которой либо все действия выполняются успешно, либо не вы­полняется ни одно из них (в последнем случае база данных остается без измене­ний). Такая транзакция иногда называется атомарной (atomic), поскольку она выполняется как единое целое.

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

47. Параллельная обработка данных: проблема потерянного обновления, проблема несогласованного чтения.

Данные обоих пользователей были верными на момент считывания. Но когда пользователь В считывал запись, у пользователя А уже была ее копия, которую он вот-вот собирался изменить. Эта ситуация носит название проблемы потерян­ного обновления (lost update problem), или проблемы параллельного обновления (concurrent update problem).

Существует другая, схожая проблема, называемая проблемой несогласованного чтения (inconsistent read problem). В этом случае пользователь А читает данные, которые были обработаны некоторым фрагмен­том транзакции пользователя В. Как следствие, у пользователя А оказываются ошибочные данные.

48. Блокировка ресурсов. Неявные и явные блокировки. Глубина детализации блокировки. Монопольная и коллективная блокировки.

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

Блокировка может налагаться либо автоматически, по инициативе СУБД, либо по команде, которая передается СУБД прикладной программой или запросом пользователя. Блокировка, налагаемая СУБД, называется неявной блокиров­кой (implicit locks), а блокировка, налагаемая по команде, — явной блокировкой (explicit locks).

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

Блокировки различаются также по типу. При монопольной блокировке (exclusive lock) блокируются все виды доступа к элементу. Ни одна другая транзакция не может читать или изменять данные. Коллективная блокировка (shared lock) защи­щает элемент от изменения, но не от чтения. То есть другие транзакции могут свободно читать данный элемент, если они не пытаются изменить его.

49. Блокировка ресурсов: сериализуемые транзакции.

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

Сериализуемость может быть достигнута несколькими способами. Один из способов — обработка транзакций с использованием двухфазной блокировки (two-phase locking). При этой стратегии транзакциям позволяется налагать блоки­ровки по мере необходимости, но как только первая блокировка снимается, данная транзакция уже не может наложить никаких других блокировок. Таким образом, транзакции имеют фазу нарастания (growing phase), на которой блокировки на­лагаются, и фазу сжатия (shrinking phase), на которой блокировки снимаются.

50. Блокировка ресурсов: взаимная блокировка.

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

Карандаш А

Бумага Б

Бумага А

Карандаш Б

На этом рисунке пользователи А и В оказываются в ситуации, которая носит название взаимной блокировки (deadlock), или «смертельного объятия» (deadly embrace). Каждый из них ожидает освобождения ресурса, заблокированного дру­гим пользователем. Есть два распространенных способа решения этой проблемы: не допускать возникновения взаимных блокировок либо позволять им возникать, а затем распутывать их.

51. Блокировка ресурсов: оптимистическая и пессимистическая блокировки.

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

52. Блокировка ресурсов: объявление характеристик блокировки.

Управление параллельной обработкой – предмет слож­ный; некоторые решения о типах и стратегиях блокировки должны делаться ме­тодом проб и ошибок. По этой и другим причинам прикладные программы базы данных обычно не налагают явных блокировок. Вместо этого они указывают рам­ки транзакций, а затем объявляют, какого рода поведение им требуется от СУБД. Таким образом, если поведение при блокировке нужно изменить, то нет необходи­мости переписывать приложение, чтобы налагать блокировки на других участках транзакции. Вместо этого просто меняется объявление характеристик блокировки. В листинге 3 изображена транзакция с карандашами, рамки которой обозна­чены с помощью операторов BEGIN TRANSACTION, COMMIT TRANSACTION и ROLLBACK TRANSACTION. Рамки транзакции – это та информация, которая жизненно необходима СУБД, чтобы реализовывать различные стратегии блокировки. Если разработчик объявит теперь (через системный параметр или каким-либо дру­гим способом), что ему нужна оптимистическая блокировка, СУБД неявным образом наложит блокировки, соответствующие этой стратегии, в правильном месте. Если после этого разработчик сменит тактику и запросит пессимистиче­скую блокировку, СУБД неявно наложит свои блокировки в другом месте.

53. Свойства транзакций: атомарность, долговечность, согласованность.

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

Транзакция обладает четырьмя важными свойствами, известными как свойства ACID (atomicity, consistency, isolation, durability):

1. Атомарность.

2. Согласованность.

3. Изолированность.

4. Долговечность или устойчивость.