Система управления базой данных

1) БД и файловые системы С самого начала развития вычислительной техники образовалось 2 направления ее использования. ^ Первое направление - применение вычислительной техники для выполнения численных расчетов, которые слишком долго или вообще невозможно производить вручную. Становление этого направления способствовало интенсификации методов численного решения сложных математических задач, развитию класса языков программирования, ориентированных на удобную запись численных алгоритмов.  ^ Второе направление, которое непосредственно касается темы нашего курса, это использование средств вычислительной техники в автоматических или автоматизированных информационных системах.  ^ Информационная система - программный комплекс, функции которого состоят в поддержке надежного хранения информации в памяти компьютера, выполнении специфических для данного приложения преобразований информации и/или вычислений, предоставлении пользователям удобного и легко осваиваемого интерфейса. На самом деле, второе направление возникло несколько позже первого. Это связано с тем, что на заре вычислительной техники компьютеры обладали ограниченными возможностями в части памяти. Использовались запоминающие устройства  - магнитные ленты  - барабаны не удовлетворяли требованиям: достаточный объем памяти, быстрота выполнения операций. С появлением магнитных дисков началась история систем управления данными во внешней памяти. До этого каждая прикладная программа, которой требовалось хранить данные во внешней памяти, сама определяла расположение каждой порции данных на магнитной ленте или барабане и выполняла обмены между оперативной и внешней памятью с помощью программно-аппаратных средств низкого уровня (машинных команд или вызовов соответствующих программ операционной системы). ^ Историческим шагом явился переход к использованию централизованных систем управления файлами. С точки зрения прикладной программы файл - это именованная область внешней памяти, в которую можно записывать и из которой можно считывать данные. Правила именования файлов, способ доступа к данным, хранящимся в файле, и структура этих данных зависят от конкретной системы управления файлами и, возможно, от типа файла. Система управления файлами берет на себя распределение внешней памяти, отображение имен файлов в соответствующие адреса во внешней памяти и обеспечение доступа к данным.  ^ Недостатки при работе с файловой системой: 1. обеспечение авторизации доступа к файлам Поскольку файловые системы являются общим хранилищем файлов, принадлежащих, вообще говоря, разным пользователям, системы управления файлами должны обеспечивать авторизацию доступа к файлам. В общем виде подход состоит в том, что по отношению к каждому зарегистрированному пользователю данной вычислительной системы для каждого существующего файла указываются действия, которые разрешены или запрещены данному пользователю. Существовали попытки реализовать этот подход в полном объеме. Но это вызывало слишком большие накладные расходы как по хранению избыточной информации, так и по использованию этой информации для контроля правомочности доступа.  Поэтому в большинстве современных систем управления файлами применяется подход к защите файлов, впервые реализованный в ОС UNIX. В этой системе каждому зарегистрированному пользователю соответствует пара целочисленных идентификаторов: идентификатор группы, к которой относится этот пользователь, и его собственный идентификатор в группе. Соответственно, при каждом файле хранится полный идентификатор пользователя, который создал этот файл, и отмечается, какие действия с файлом может производить он сам, какие действия с файлом доступны для других пользователей той же группы, и что могут делать с файлом пользователи других групп. Эта информация очень компактна, при проверке требуется небольшое количество действий, и этот способ контроля доступа удовлетворителен в большинстве случаев.  2. режим многопользовательского доступа Если операционная система поддерживает многопользовательский режим, вполне реальна ситуация, когда два или более пользователей одновременнопытаются работать с одним и тем же файлом. Если все эти пользователи собираются только читать файл, ничего страшного не произойдет. Но если хотя бы один из них будет изменять файл, для корректной работы этой группы требуется взаимная синхронизация. Заметим, что в ранних версиях файловой системы ОС UNIX вообще не были реализованы какие бы то ни было средства синхронизации параллельного доступа к файлам. В современных реализациях файловых систем ОС UNIX по желанию пользователя поддерживается синхронизация при открытии файлов. Кроме того, существует возможность синхронизации нескольких процессов, параллельно модифицирующих один и тот же файл. ^ 3. проблема синхронизации данных Области применения файлов Прежде всего, конечно, файлы применяются для хранения текстовых данных: документов, текстов программ и т.д. Такие файлы обычно образуются и модифицируются с помощью различных текстовых редакторов. Структура текстовых файлов обычно очень проста: это либо последовательность записей, содержащих строки текста, либо последовательность байтов, среди которых встречаются специальные символы (например, символы конца строки).  Одним словом, файловые системы обычно обеспечивают хранение слабо структурированной информации, оставляя дальнейшую структуризацию прикладным программам.  База данных (БД) – совместно используемый набор логически связанных данных (и их описание), предназначенный для удовлетворения информационных потребностей организации. ^ Потребности информационных систем Эти системы главным образом ориентированы на хранение, выбор и модификацию постоянно существующей информации. Структура информации зачастую очень сложна, и хотя структуры данных различны в разных информационных системах, между ними часто бывает много общего. На начальном этапе использования вычислительной техники для управления информацией проблемы структуризации данных решались индивидуально в каждой информационной системе. Производились необходимые надстройки над файловыми системами (библиотеки программ), подобно тому, как это делается в компиляторах, редакторах и т.д.  Но поскольку информационные системы требуют сложных структур данных, эти дополнительные индивидуальные средства управления данными являлись существенной частью информационных систем и практически повторялись от одной системы к другой.  Стремление выделить и обобщить общую часть информационных систем, ответственную за управление сложно структурированными данными, явилось первой побудительной причиной создания СУБД. Очень скоро стало понятно, что невозможно обойтись общей библиотекой программ, реализующей над стандартной базовой файловой системой более сложные методы хранения данных.  Понятие согласованности данных является ключевым понятием баз данных. Фактически, если информационная система (даже такая простая, как в нашем примере) поддерживает согласованное хранение информации в нескольких файлах, можно говорить о том, что она поддерживает базу данных. Если же некоторая вспомогательная система управления данными позволяет работать с несколькими файлами, обеспечивая их согласованность, можно назвать ее системой управления базами данных. Уже только требование поддержания согласованности данных в нескольких файлах не позволяет обойтись библиотекой функций: такая система должна иметь некоторые собственные данные (метаданные) и даже знания, определяющие целостность данных.  Но это еще не все, что обычно требуют от СУБД. Необходимо, чтобы СУБД позволяла сформулировать некоторый запрос к данным на близком пользователям языке. Такие языки называются языками запросов к базам данных.  Таким образом, СУБД решают множество проблем, которые затруднительно или вообще невозможно решить при использовании файловых систем. При этом существуют приложения, для которых вполне достаточно файлов; приложения, для которых необходимо решать, какой уровень работы с данными во внешней памяти для них требуется, и приложения, для которых безусловно нужны базы данных.  Функции СУБД.  1. Непосредственное управление данными во внешней памяти 2. Управление буферами оперативной памяти  3. Управление транзакциями  4. Журнализация 5. Поддержка языков БД Непосредственное управление данными во внешней памяти Эта функция включает обеспечение необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД, так и для служебных целей, например, для убыстрения доступа к данным в некоторых случаях (обычно для этого используются индексы). ^ Управление буферами оперативной памяти СУБД обычно работают с БД значительного размера; по крайней мере этот размер обычно существенно больше доступного объема оперативной памяти. Понятно, что если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти. Практически единственный способ увеличить скорость является буферизация данных оперативной памяти, выполняемая самой СУБД, а не ОС. Управление транзакциями Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД. Поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). Но понятие транзакции гораздо более важно в многопользовательских СУБД.  То свойство, что каждая транзакция начинается при целостном состоянии БД и оставляет это состояние целостным после своего завершения, делает очень удобным использование понятия транзакции как единицы активности пользователя по отношению к БД. При соответствующем управлении параллельно выполняющимися транзакциями со стороны СУБД каждый из пользователей может в принципе ощущать себя единственным пользователем СУБД (на самом деле, это несколько идеализированное представление, поскольку в некоторых случаях пользователи многопользовательских СУБД могут ощутить присутствие своих коллег).  С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации транзакций и сериального плана выполнения смеси транзакций Под сериализаций параллельно выполняющихся транзакций понимается такой порядок планирования их работы, при котором суммарный эффект смеси транзакций эквивалентен эффекту их некоторого последовательного выполнения. Сериальный план выполнения смеси транзакций - это такой план, который приводит к сериализации транзакций. Понятно, что если удается добиться действительно сериального выполнения смеси транзакций, то для каждого пользователя, по инициативе которого образована транзакция, присутствие других транзакций будет незаметно (если не считать некоторого замедления работы по сравнению с однопользовательским режимом).  Существует несколько базовых алгоритмов сериализации транзакций. В централизованных СУБД наиболее распространены алгоритмы, основанные на синхронизационных захватах объектов БД. При использовании любого алгоритма сериализации возможны ситуации конфликтов между двумя или более транзакциями по доступу к объектам БД. В этом случае для поддержания сериализации необходимо выполнить откат (ликвидировать все изменения, произведенные в БД) одной или более транзакций. Это один из случаев, когда пользователь многопользовательской СУБД может реально (и достаточно неприятно) ощутить присутствие в системе транзакций других пользователей.  Журнализация СУБД должна обеспечивать надежность хранения данных, т.е. быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев могут быть: аварийное завершение работы СУБД (по причине ошибки в программе или в результате некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции.  Понятно, что в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД.  ^ Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД.  В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (например, операции удаления строки из таблицы реляционной БД), иногда - минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода.  Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.  Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Архивная копия - это полная копия БД к моменту начала заполнения журнала.  Поддержка языков БД Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language). SDL служил главным образом для определения логической структуры БД, т.е. той структуры БД, какой она представляется пользователям. DML содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные.  В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language).  Язык SQL включает язык определения данных, язык манипулирования данными, язык запросов, язык управления данными. ^ 2) СУБД определение, функции Система Управления Базой Данных (СУБД) - комплекс языков и программ, позволяющий создавать БД и управлять ее функционированием.  СУБД обрабатывает обращения к базе данных, поступающие от пользователей, прикладных процессов и выдает необходимые им сведения.  СУБД характеризуется используемой моделью и средствами администрирования, разработки прикладных процессов, работы в информационной сети.  ^ Типовая организация СУБД - ядро, которое отвечает за управление данными во внешней и оперативной памяти, управление транзакциями и журнализацию. При использовании архитектуры "клиент-сервер" ядро является основной составляющей серверной части системы. - компилятор языка SQL - подсистема поддержки времени исполнения, которая интерпретирует программы манипуляции данными, создающие пользовательский интерфейс с СУБД - сервисные программы (внешние утилиты), обеспечивающие ряд дополнительных возможностей по обслуживанию информационной системы. ^ Функции СУБД 1. управление данными во внешней памяти – обеспечение необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД, так и для служебных целей. 2. управление буферами оперативной памяти – обычно СУБД работает с БД значительного размера, по крайней мере этот размер обычно существенно больше доступного объема оперативной памяти. Если при обращении к элементу будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройств внешней памяти, поэтому единственный способ увеличить скорость является буферизация данных оперативной памяти, выполняемая самой СУБД, а не ОС.  3. управление транзакциями. Транзакция – последовательность операций над БД, рассматриваемых как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД. Поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). Но понятие транзакции гораздо более важно в многопользовательских СУБД.  То свойство, что каждая транзакция начинается при целостном состоянии БД и оставляет это состояние целостным после своего завершения, делает очень удобным использование понятия транзакции как единицы активности пользователя по отношению к БД. При соответствующем управлении параллельно выполняющимися транзакциями со стороны СУБД каждый из пользователей может в принципе ощущать себя единственным пользователем СУБД (на самом деле, это несколько идеализированное представление, поскольку в некоторых случаях пользователи многопользовательских СУБД могут ощутить присутствие своих коллег).  С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации транзакций и сериального плана выполнения смеси транзакций Под сериализаций параллельно выполняющихся транзакций понимается такой порядок планирования их работы, при котором суммарный эффект смеси транзакций эквивалентен эффекту их некоторого последовательного выполнения. Сериальный план выполнения смеси транзакций - это такой план, который приводит к сериализации транзакций. Понятно, что если удается добиться действительно сериального выполнения смеси транзакций, то для каждого пользователя, по инициативе которого образована транзакция, присутствие других транзакций будет незаметно (если не считать некоторого замедления работы по сравнению с однопользовательским режимом).  Существует несколько базовых алгоритмов сериализации транзакций. В централизованных СУБД наиболее распространены алгоритмы, основанные на синхронизационных захватах объектов БД. При использовании любого алгоритма сериализации возможны ситуации конфликтов между двумя или более транзакциями по доступу к объектам БД. В этом случае для поддержания сериализации необходимо выполнить откат (ликвидировать все изменения, произведенные в БД) одной или более транзакций. Это один из случаев, когда пользователь многопользовательской СУБД может реально (и достаточно неприятно) ощутить присутствие в системе транзакций других пользователей.  4. журнализация. СУБД должна обеспечивать надежность хранения данных, т.е. быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного/программного сбоя, для этого БД нужно располагать некоторой дополнительной информацией, обеспечивающей эту цель.Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД.  ^ 5. поддержка языков БД  Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language). В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language).  Язык SQL включает язык определения данных, язык манипулирования данными, язык запросов, язык управления данными. ^ 3) СУБД определение, классификация Система Управления Базой Данных (СУБД) - комплекс языков и программ, позволяющий создавать БД и управлять ее функционированием.  СУБД обрабатывает обращения к базе данных, поступающие от пользователей, прикладных процессов и выдает необходимые им сведения.  СУБД характеризуется используемой моделью и средствами администрирования, разработки прикладных процессов, работы в информационной сети. ^ Типовая организация СУБД - ядро, которое отвечает за управление данными во внешней и оперативной памяти, управление транзакциями и журнализацию. При использовании архитектуры "клиент-сервер" ядро является основной составляющей серверной части системы. - компилятор языка SQL - подсистема поддержки времени исполнения, которая интерпретирует программы манипуляции данными, создающие пользовательский интерфейс с СУБД - сервисные программы (внешние утилиты), обеспечивающие ряд дополнительных возможностей по обслуживанию информационной системы. ^ Классификация СУБД 1. По модели данных - иерархические - сетевые - реляционные - объектно-ориентированные - объектно-реляционные - пост-реляционные 2. По степени распределенности - локальные СУБД - распределенные СУБД 3. По способу доступа к БД - файл-серверные - клиент-серверные - встраеваемые Иерархическая БД Иерархическая модель базы данных состоит из объектов с указателями от родительских объектов к потомкам, соединяя вместе связанную информацию. Иерархические базы данных могут быть представлены как дерево, состоящее из объектов различных уровней. Сетевая БД К основным понятиям сетевой модели базы данных относятся: уровень, элемент (узел), связь. Реляционная БД - база данных, логически организованная в виде набора отношений ее компонентов. Характерной особенностью РБД является структура, выполненная в виде таблиц. Строки таких таблиц соответствуют записям, столбцы - атрибутам (признакам хранимых данных).  ^ Объектно-ориентированные базы данных (ООБД) появились совсем недавно как естественное развитие объектно-ориентированных языков программирования.  Данные представлены в виде объектов различных классов.  Как правило, имеются возможности создавать новые классы, наследовать их от уже имеющихся, задавать произвольные атрибуты и методы для классов.  Для доступа к объектам, в каждой ООБД обычно предусматривается свой собственный язык, либо расширение другого языка. Пока еще ООБД недостаточно развиты и не представляют серьезной конкуренции SQL-серверам. Примеры, Cache, FastObjects,GemStone/S, Jasmine, ObjectStore и др ^ Объектно-реляционные БД Разработчики многих реляционных БД включают в свои базы средства работы с объектными типами данных. Такие базы данных получили название объектно-реляционных.  По этому пути, в частности, развивается и Oracle. Бывшая ранее чисто реляционной базой, Oracle начиная с 8 версии поддерживает возможность хранения и обработки объектов и безо всякой натяжки может быть отнесена к объектно-реляционному классу баз данных.  Пост-реляционными, часто называют многомерные базы данных.  Данные в многомерных базах, представляются в виде разреженных многомерных массивов, а не плоских таблиц, как в реляционных базах. Для определенных задач, многомерные базы могут давать значительный выигрыш в быстродействии, по сравнению с реляционными.  Примеры, Cache, Teradata  ^ Файл-серверные СУБД В файл-серверных СУБД файлы данных располагаются централизованно на файл-сервере. СУБД располагается на каждом клиентском компьютере (рабочей станции). Доступ СУБД к данным осуществляется через локальную сеть. На данный момент файл-серверные СУБД считаются устаревшими. Примеры: Microsoft Access, Paradox, dBase. ^ Клиент-серверные СУБД Клиент-серверная СУБД располагается на сервере вместе с БД и осуществляет доступ к БД непосредственно, в монопольном режиме. Все клиентские запросы на обработку данных обрабатываются клиент-серверной СУБД централизованно. Примеры: Oracle, Firebird, Interbase, IBM DB2, MS SQL Server, Sybase, PostgreSQL, MySQL, ЛИНТЕР, MDBS. ^ Встраиваемая СУБД — библиотека, которая позволяет унифицированным образом хранить большие объёмы данных на локальной машине. Доступ к данным может происходить через SQL либо через особые функции СУБД. Встраиваемые СУБД быстрее обычных клиент-серверных и не требуют установки сервера, поэтому востребованы в локальном ПО, которое имеет дело с большими объёмами данных (например, геоинформационные системы). Примеры: OpenEdge, SQLite, BerkeleyDB, один из вариантов Firebird, MySQL, Sav Zigzag, Microsoft SQL Server Compact, ЛИНТЕР. ^ 4) БД основные определения, классификация Базой данных является специальным образом организованные один либо группа файлов.  Для работы с ними используется Система Управления Базой Данных (СУБД).  БД определена по схеме, не зависящей от программ, которые к ней обращаются. БД характеризуется ее концепцией - совокупностью требований, определяемых представлениями пользователей о необходимой им информации.  На основе БД создаются разнообразные информационные системы. Классификация БД 1. В зависимости от размера БД и ее расположения можно выделить - портативные БД, небольшие БД, находящихся в персональных компьютерах - сетевые БД, крупные БД, расположенные на серверах, доступ к которым осуществляется по сети. - распределенные БД и создаваемые на их основе информационные хранилища. БД, распределенные на нескольких серверах.  2. В зависимости от хранимых данных: - фактографические БД: содержат краткие сведения об описываемых объектах, представленные в строго определенном формате.  - документальные БД: содержат обширную информацию самого разного типа: текстовую, графическую, звуковую, мультимедийную. - текстовая база данных - база данных, записи в которой содержат (главным образом) текст на естественном языке.  - гипертекстовая база данных - текстовая база данных, записи в которой содержат связи с другими записями, позволяющими компоновать ансамбли записей на основе их логической связанности.  - полнотекстовая база данных - текстовая база, содержащая полные тексты документов или их частей.  - численно-текстовая база данных - база данных, содержащая числовые данные и текстовую информацию. 3. В зависимости от модели данных - иерархическая состоит из объектов с указателями от родительских объектов к потомкам, соединяя вместе связанную информацию. - сетевая - реляционная - база данных, логически организованная в виде набора отношений ее компонентов. - многомерная (пост-реляционная) - объектная - объектно-ориентированная - база данных, в которой данные оформлены в виде моделей объектов, включающих прикладные программы, которые управляются внешними событиями. - объектно-реляционная 4. В зависимости от технологии хранения: - БД во вторичной памяти (традиционные) - БД в оперативной памяти (in-memory databases) - БД в третичной памяти (tertiary databases) ^ 5) Объекты базы данных Выделяют следующие объекты БД: - таблицы - типы данных (также определенные пользователем типы данных) - ограничения - значения по умолчанию - правила - ключи - индексы - представления - хранимые процедуры - определенные пользователем функции - триггеры - пользователи  - роли Понятие тип данных в реляционной модели данных полностью адекватно понятию типа данных в языках программирования.  Обычно в современных реляционных БД допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких как "деньги"), а также специальных "темпоральных" данных (дата, время, временной интервал).  Понятие домена более специфично для баз данных, хотя и имеет некоторые аналогии с подтипами в некоторых языках программирования.  Домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных. Если вычисление этого логического выражения дает результат "истина", то элемент данных является элементом домена.  ^ Наиболее правильной интуитивной трактовкой понятия домена является понимание домена как допустимого потенциального множества значений данного типа.  Пользовательские типы данных – это типы данных, которые создает пользователь на основе системных типов данных, когда в нескольких таблицах необходимо хранить однотипные значения; причем нужно гарантировать, что столбцы в таблице будут иметь одинаковый размер, тип данных и чувствительность к значениям NULL. Таблица – отношение – множество кортежей, соответствующих схеме. Все данные в SQL содержатся в объектах, называемых таблицами. Таблицы представляют собой совокупность каких-либо сведений об объектах, явлениях, процессах реального мира. Никакие другие объекты не хранят данные, но они могут обращаться к данным в таблице. Таблицы в SQL имеют такую же структуру, что и таблицы всех других СУБД и содержат: - cтроки; каждая строка (или запись) представляет собой совокупность атрибутов (свойств) конкретного экземпляра объекта;  - cтолбцы; каждый столбец (поле) представляет собой атрибут или совокупность атрибутов. Поле строки является минимальным элементом таблицы. Каждый столбец в таблице имеет определенное имя, тип данных и размер. ^ Схема отношения - это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)}.  Степень или "арность" схемы отношения - мощность этого множества. Степень отношения СОТРУДНИКИ равна четырем, то есть оно является 4-арным.  ^ Схема БД (в структурном смысле) - это набор именованных схем отношений.  Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения.  "Значение" является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень или "арность" кортежа, т.е. число элементов в нем, совпадает с "арностью" соответствующей схемы отношения.  Попросту говоря, кортеж - это набор именованных значений заданного типа.  ^ Ограничения целостности – механизм, обеспечивающий автоматический контроль соответствия данных установленным условиям (или ограничениям). Ограничения целостности имеют приоритет над триггерами, правилами и значениями по умолчанию. К ограничениям целостности относятся: ограничение на значение NULL, проверочные ограничения, ограничение уникальности (уникальный ключ), ограничение первичного ключа и ограничение внешнего ключа. Последние три ограничения тесно связаны с понятием ключей.  ^ Значение по умолчания – самостоятельный объект базы данных, представляющий значение, которое будет присвоено элементу таблицы при вставке строки, если в команде вставки явно не указано значение для этого столбца. Правила используются для ограничения значений, хранимых в столбце таблицы или в пользовательском типе данных. Они существуют как самостоятельные объекты базы данных, которые связываются со столбцами таблиц и пользовательскими типами данных. Контроль значений данных может быть реализован и с помощью ограничений целостности. ^ Ключи – один из видов ограничений целостности данных. Различают первичный ключи и внешние ключи. Первичный ключ – набор атрибутов, значения которых однозначно определяют кортеж отношений (минимальный набор атрибутов). ^ Индекс представляет собой средство, помогающее ускорить поиск необходимых данных за счет физического или логического их упорядочивания.  Индекс представляет собой набор ссылок, упорядоченных по определенному столбцу таблицы, который в данном случае будет называться индексированным столбцом.  ^ Индексы это наборы уникальных значений для некоторой таблицы с соответствующими ссылками на данные.  Представления, или просмотры (VIEW), представляют собой временные, производные (иначе - виртуальные) таблицы и являются объектами базы данных, информация в которых не хранится постоянно, как в базовых таблицах, а формируется динамически при обращении к ним.  ^ Представлениями (просмотрами) называют виртуальные таблицы, содержимое которых определяется запросом. Подобно реальным таблицам, представления содержат именованные столбцы и строки с данными. Для конечных пользователей представление выглядит как таблица, но в действительности оно не содержит данных, а лишь представляет данные, расположенные в одной или нескольких таблицах. Информация, которую видит пользователь через представление, не сохраняется в базе данных как самостоятельный объект. ^ Хранимые процедуры представляют собой группы связанных между собой операторов SQL, применение которых делает работу программиста более легкой и гибкой, поскольку выполнить хранимую процедуру часто оказывается гораздо проще, чем последовательность отдельных операторов SQL.  Хранимые процедуры представляют собой набор команд, состоящий из одного или нескольких операторов SQL или функций и сохраняемый в базе данных в откомпилированном виде.  ^ Пользовательские функции сходны с хранимыми процедурами, но, в отличие от них, могут применяться в запросах так же, как и системные встроенные функции.  Триггер – это откомпилированная SQL-процедура, исполнение которой обусловлено наступлением определенных событий внутри реляционной базы данных.  Триггеры – особый инструмент SQL-сервера, используемый для поддержания целостности данных в базе данных. Триггерами называется специальный класс хранимых процедур, автоматически запускаемых при добавлении, изменении или удалении данных из таблицы.  ^ Пользователи – лица, обладающие доступом к БД Роли позволяют объединять пользователей в группы 6) Физическая структура базы данных Физически база данных SQL Server 2000 хранится в самостоятельном, уникальном для каждой БД наборе файлов. Журнал транзакций и сами данные обязательно хранятся отдельно. Это повышает отказоустойчивость базы данных в случае сбоев системы. ^ Файлы данных и группы файлов Для хранения базы данных предназначен набор файлов, персональный для любой базы данных. Каждый файл может принадлежать только одной базе данных. В SQL Server 2000 существует два типа файлов базы данных: - файлы данных; - файлы журнала транзакций. Файлы данных (data file) предназначены для хранения информации, находящейся в таблицах базы данных. Кроме того, в этих файлах также размещены процедуры, ограничения, триггеры, индексы и другая информация. В файлы журнала транзакций (transaction log file) SQL Server 2000 записывает информацию о ходе выполнения транзакций. В них размешается информация о состоянии данных перед началом транзакции, о выполняемых изменениях, блокированных ресурсах и другая сопутствующая информация. Любая база данных должна содержать как минимум один файл данных и один файл журнала транзакций, т.е. минимальное количество файлов, составляющих базу данных, равно 2. При необходимости администратор может добавлять новые файлы данных или файлы журнала транзакций. Файлы данных бывают двух типов: - Primary File (основной, или главный, файл); - Secondary File (вторичный, или дополнительный, файл). Каждая база данных имеет один и только один основной или главный файл (Primary File). Если база данных включает в себя только один файл данных, то этот файл будет основным. Основной файл предназначен для хранения всех системных таблиц, присутствующих в любой базе данных. В основном файле хранится информация о структуре базы данных, созданных в ней объектах, параметрах дополнительных файлов и файлов журнала транзакций. По умолчанию основному файлу базы данных присваивается расширение mdf (Master Data File). В отличие от основного файла база данных может содержать множество вторичных или дополнительных файлов (Secondary File) или не содержать их вовсе. В дополнительных файлах может храниться только пользовательская информация. Хранение любой системной информации не допускается. В ходе эксплуатации базы данных администратор может добавлять новые или удалять уже существующие дополнительные файлы. Файлы журнала транзакций бывают только одного типа – Transaction Log File, служащего для хранения журнала транзакций. В базе данных должен быть как минимум один файл журнала транзакций. Для ускорения обработки транзакций можно использовать несколько журналов транзакций, расположенных на разных физических дисках. Для каждого файла базы данных можно задать свойство автоматического роста и шаг прироста в мегабайтах или в процентах от первоначального роста, а также максимальный размер, до которого возможен рост файла. Каждый файл, используемый в базе данных, имеет два имени: - Logical File Name – логическое имя файла, которое используется в командах Transact-SQL при ссылке на конкретный файл; - OS File Name – имя файла в операционной системе, которое используется для обращения к файлу в операционной системе. Сложные базы данных могут иметь несколько файлов для данных и для журнала транзакций. В этом случае файлы БД объединяются в группы для упрощения администрирования базы данных. SQL Server 2000 обеспечивает создание групп следующих трех типов: - Primary File Group – основная группа файлов, которая включает первичный файл и все файлы, не включенные в другие группы, база данных может иметь только одну основную группу файлов; - User-defined File Group – пользовательская группа файлов, создаваемая командой CREATE DATEBASE или командой ALTER DATABASE, если в них используется параметр FILEGROUP, в базе данных можно создать несколько пользовательских групп файлов с произвольным набором файлов; - Default File Group – группа файлов по умолчанию, в качестве которой назначается одна из групп файлов, созданных в базе данных. Только одна группа файлов может быть группой по умолчанию. Если не указано явно, группой по умолчанию становится основная группа. Если при создании объекта базы данных не указано явно, к какой группе файлов он будет принадлежать, то этот объект создается в группе файлов по умолчанию. Когда какие-то данные записываются в группу файлов, они распределяются между файлами этой группы равномерно, т.е. производится распараллеливание записи данных. Для этих целей можно использовать и возможности файловой системы NTFS: чередующийся набор дисков с контролем четности и без него. Любая группа файлов, в том числе и основная, может быть установлена в режим только для чтения, что позволяет защитить данные, записанные на файлы этой группы. ^ 7) Структурная часть реляционной модели Хотя понятие реляционной модели данных первым ввел основоположник реляционного подхода Эдгар Кодд, наиболее распространенная трактовка реляционной модели данных принадлежит известному популяризатору идей Кодда Кристоферу Дейту Согласно трактовке Дейта, реляционная модель состоит из трех частей, описывающих разные аспекты реляционного подхода: - структурной части, - манипуляционной части, - целостной части. ^ В структурной части модели фиксируется, что единственной структурой данных, используемой в реляционных БД, является нормализованное n-арное отношение. Определяются понятия доменов, атрибутов, кортежей, заголовка, тела и переменной отношения. Домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных. Если вычисление этого логического выражения дает результат "истина", то элемент данных является элементом домена.  Наиболее правильной интуитивной трактовкой понятия домена является понимание домена как допустимого потенциального множества значений данного типа.  ^ Схема отношения - это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)}.  Степень или "арность" схемы отношения - мощность этого множества. Степень отношения СОТРУДНИКИ равна четырем, то есть оно является 4-арным.  Схема БД (в структурном смысле) - это набор именованных схем отношений. Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения.  ^ Кортеж - это набор именованных значений заданного типа.  Отношение - это множество кортежей, соответствующих одной схеме отношения (аналог – таблица).  ^ 8) Фундаментальные свойства отношений Отношение - это множество кортежей, соответствующих одной схеме отношения (аналог – таблица).  Фундаментальные свойства отношений: 1. Отсутствие кортежей-дубликатов То свойство, что отношения не содержат кортежей-дубликатов, следует из определения отношения как множества кортежей. В классической теории множеств по определению каждое множество состоит из различных элементов. Из этого свойства вытекает наличие у каждого отношения так называемого первичного ключа - набора атрибутов, значения которых однозначно определяют кортеж отношения (минимальный набор атрибутов). Для каждого отношения по крайней мере полный набор его атрибутов обладает этим свойством.  2. Отсутствие упорядоченности кортежей Отсутствие требования к поддержанию порядка на множестве кортежей отношения дает дополнительную гибкость СУБД при хранении баз данных во внешней памяти и при выполнении запросов к базе данных.  Это не противоречит тому, что при формулировании запроса к БД, например, на языке SQL можно потребовать сортировки результирующей таблицы в соответствии со значениями некоторых столбцов. Такой результат, вообще говоря, не отношение, а некоторый упорядоченный список кортежей.  3. Отсутствие упорядоченности атрибутов Атрибуты отношений не упорядочены, поскольку по определению схема отношения есть множество пар {имя атрибута, имя домена}.  Для ссылки на значение атрибута в кортеже отношения всегда используется имя атрибута. Это свойство теоретически позволяет, например, модифицировать схемы существующих отношений не только путем добавления новых атрибутов, но и путем удаления существующих атрибутов.  4. Атомарность значений атрибутов Значения всех атрибутов являются атомарными. Это следует из определения домена как потенциального множества значений простого типа данных, т.е. среди значений домена не могут содержаться множества значений (отношения).  ^ 9) Реляционная алгебра Кодда Реляционная алгебра Кодда включает в себя теоретико-множественные операторы и специальные реляционные операторы. Теоретико-множественные операторы 1. Объединение – отношение с тем же заголовком, что и у совместимых по типу отношений A и B, и телом, состоящим из кортежей, принадлежащих или A, или B, или обоим отношениям. (A UNION B) 2. Пересечение - отношение с тем же заголовком, что и у отношений A и B, и телом, состоящим из кортежей, принадлежащих одновременно обоим отношениям A и B. (A INTERSECT B) 3. Вычитание - отношение с тем же заголовком, что и у совместимых по типу отношений A и B, и телом, состоящим из кортежей, принадлежащих отношению A и не принадлежащих отношению B. (A MINUS B) 4. Декартово произведение отношение (A1, A2, …, Am, B1, B2, …, Bm), заголовок которого является сцеплением заголовков отношений A(A1, A2, …, Am) и B(B1, B2, …, Bm), а тело состоит из кортежей, являющихся сцеплением кортежей отношений A и B: (a1, a2, …, am, b1, b2, …, bm), таких, что (a1, a2, …, am)∈ A, (b1, b2, …, bm)∈ B. Т.е. каждый кортеж первого отношения объединяется с каждым кортежем второго отношения. (A TIMES B) ^ Специальные реляционные операторы 1. Ограничение (выборка) - отношение с тем же заголовком, что и у отношения A, и телом, состоящим из кортежей, значения атрибутов которых удовлетворяет некому условию С. С представляет собой логическое выражение, в которое могут входить атрибуты отношения A и/или скалярные выражения. (A WHERE С) 2. Проекция – отношение, кортежи которого являются соответствующими подмножествами отношения операнда. Отношение с заголовком (X, Y, …, Z) и телом, содержащим множество кортежей вида (x, y, …, z), таких, для которых в отношении A найдутся кортежи со значением атрибута X равным x, значением атрибута Y равным y, …, значением атрибута Z равным z. При выполнении проекции выделяется «вертикальная» вырезка отношения-операнда с естественным уничтожением потенциально возникающих кортежей-дубликатов. A[X, Y, …, Z] или PROJECT A {x, y, …, z} 3. Соединение – отношение, кортежи которого производятся путем объединения кортежей первого и второго отношения и удовлетворяют некому условию. ((A TIMES B) WHERE С = A JOIN B WHERE С Соединение – есть результат последовательного применения операций декартового произведения и выборки. Если в отношениях и имеются атрибуты с одинаковыми наименованиями, то перед выполнением соединения такие атрибуты необходимо переименовать. 4. Реляционное деление - отношение с заголовком (X1, X2, …, Xn) и телом, содержащим множество кортежей (x1, x2, …, xn), таких, что для всех кортежей (y1, y2, …, ym) ∈ B в отношении A(X1, X2, …, Xn, Y1, Y2, …, Ym) найдется кортеж (x1, x2, …, xn, y1, y2, …, ym). (A DIVIDEBY B) ^ Зависимость реляционных операторов Не все реляционные операторы являются независимыми, то есть некоторые из реляционных операторов могут быть выражены через другие реляционные операторы. ^ 1. Оператор соединения Оператор соединения определяется через операторы декартового произведения и выборки следующим образом: (A TIMES B) WHERE X=Y где X и Y атрибуты соответственно отношений A и B с первоначально равными именами. ^ 2. Оператор пересечения Оператор пересечения выражается через вычитание следующим образом: A INTERSECT B = A MINUS (A MINUS B) 3. Оператор деления Оператор деления выражается через операторы вычитания, декартового произведения и проекции следующим образом: A DIVIDEBY B = A[X] MINUS ((A[X] TIMES B) MINUS A)[X] ^ Примитивные реляционные операторы Оставшиеся реляционные операторы (объединение, вычитание, декартово произведение, выборка, проекция) являются примитивными операторами — их нельзя выразить друг через друга. ^ 1. Оператор декартового произведения Оператор декартового произведения — это единственный оператор, увеличивающий количество атрибутов, поэтому его нельзя выразить через объединение, вычитание, выборку, проекцию. ^ 2. Оператор проекции Оператор проекции — единственный оператор, уменьшающий количество атрибутов, поэтому его нельзя выразить через объединение, вычитание, декартово произведение, выборку. ^ 3. Оператор выборки Оператор выборки — единственный оператор, позволяющий проводить сравнения по атрибутам отношения, поэтому его нельзя выразить через объединение, вычитание, декартово произведение, проекцию. ^ 4. Операторы объединения и вычитания 10) Целостность реляционных данных, стратегии поддержания ссылочной целостности Целостность реляционных данных фиксирует два базовых требования целостности: - требование целостности сущности - требование целостности внешних ключей ^ Целостность сущности У любой переменной отношения должен существовать первичный ключ, и никакое значение первичного ключа в кортежах значения-отношения переменной отношения не должно содержать неопределенных значений (NULL). Неопределенное значение не принадлежит никакому типу данных и может присутствовать среди значений любого атрибута, определенного на любом типе данных (если это явно не запрещено при определении атрибута). Таким образом, требование означает, что первичный ключ должен полностью идентифицировать каждую сущность, а поэтому в составе любого значения первичного ключа не допускается наличие неопределенных значений.  ^ Правило целостности внешних ключей Внешние ключи не должны быть несогласованными, т.е. для каждого значения внешнего ключа должно существовать соответствующее значение первичного ключа в родительском отношении.  Ссылочная целостность может нарушиться в результате операций, изменяющих состояние базы данных. Таких операций три: - вставка - обновление  - удаление кортежей в отношениях.  Т.к. в определении ссылочной целостности участвуют два отношения - родительское и дочернее, а в каждом из них возможны три операции, то нужно рассмотреть шесть различных вариантов.  ^ Для родительского отношения: 1. Вставка кортежа в родительском отношении. При вставке кортежа в родительское отношение возникает новое значение потенциального ключа. Т.к. допустимо существование кортежей в родительском отношении, на которые нет ссылок из дочернего отношения, то вставка кортежей в родительское отношение не нарушает ссылочной целостности.  2. Обновление кортежа в родительском отношении. При обновлении кортежа в родительском отношении может измениться значение потенциального ключа. Если есть кортежи в дочернем отношении, ссылающиеся на обновляемый кортеж, то значения их внешних ключей станут некорректными. Обновление кортежа в родительском отношении может привести к нарушению ссылочной целостности, если это обновление затрагивает значение потенциального ключа.  3. Удаление кортежа в родительском отношении. При удалении кортежа в родительском отношении удаляется значение потенциального ключа. Если есть кортежи в дочернем отношении, ссылающиеся на удаляемый кортеж, то значения их внешних ключей станут некорректными. Удаление кортежей в родительском отношении может привести к нарушению ссылочной целостности.  ^ Для дочернего отношения: 1. Вставка кортежа в дочернее отношение. Нельзя вставить кортеж в дочернее отношение, если вставляемое значение внешнего ключа некорректно. Вставка кортежа в дочернее отношение привести к нарушению ссылочной целостности.  2. Обновление кортежа в дочернем отношении. При обновлении кортежа в дочернем отношении можно попытаться некорректно изменить значение внешнего ключа. Обновление кортежа в дочернем отношении может привести к нарушению ссылочной целостности.  3. Удаление кортежа в дочернем отношении. При удалении кортежа в дочернем отношении ссылочная целостность не нарушается. Таким образом, ссылочная целостность в принципе может быть нарушена при выполнении одной из четырех операций:  1. Обновление кортежа в родительском отношении.  2. Удаление кортежа в родительском отношении.  3. Вставка кортежа в дочернее отношение.  4. Обновление кортежа в дочернем отношении.  Существуют две основные стратегии поддержания ссылочной целостности:  ^ RESTRICT (ОГРАНИЧИТЬ) - не разрешать выполнение операции, приводящей к нарушению ссылочной целостности.  CASCADE (КАСКАДИРОВАТЬ) - разрешить выполнение требуемой операции, но внести при этом необходимые поправки в других отношениях так, чтобы не допустить нарушения ссылочной целостности и сохранить все имеющиеся связи. Изменение начинается в родительском отношении и каскадно выполняется в дочернем отношении.  Эти стратегии являются стандартными и присутствуют во всех СУБД, в которых имеется поддержка ссылочной целостности.  Дополнительные стратегии: ^ SET NULL (УСТАНОВИТЬ В NULL) - разрешить выполнение требуемой операции, но все возникающие некорректные значения внешних ключей изменять на null-значения.  SET DEFAULT (УСТАНОВИТЬ ПО УМОЛЧАНИЮ) - разрешить выполнение требуемой операции, но все возникающие некорректные значения внешних ключей изменять на некоторое значение, принятое по умолчанию.  ^ IGNORE (ИГНОРИРОВАТЬ) - выполнять операции, не обращая внимания на нарушения ссылочной целостности.  11) Этапы разработки БД При разработке базы данных обычно выделяется несколько уровней моделирования, при помощи которых происходит переход от предметной области к конкретной реализации базы данных средствами конкретной СУБД. Можно выделить следующие уровни:  1. Сама предметная область  2. Модель предметной области  3. Логическая модель данных  4. Физическая модель данных  5. Собственно база данных и приложения  Предметная область - это часть реального мира, данные о которой мы хотим отразить в базе данных.  Предметная область бесконечна и содержит как существенно важные понятия и данные, так и малозначащие или вообще не значащие данные. Таким образом, важность данных зависит от выбора предметной области.  ^ Модель предметной области - это наши знания о предметной области. Знания могут быть как в виде неформальных знаний в мыслях эксперта, так и выражены формально при помощи каких-либо средств.  В качестве таких средств могут выступать текстовые описания предметной области, наборы должностных инструкций, правила ведения дел в компании и т.п. Опыт показывает, что текстовый способ представления модели предметной области крайне неэффективен. Более эффективны описания предметной области, выполненные при помощи специализированных графических нотаций. Одной из методик описания предметной области является методика объектно-ориентированного анализа UML. Модель предметной области описывает скорее процессы, происходящие в предметной области и данные, используемые этими процессами.  От того, насколько правильно смоделирована предметная область, зависит успех дальнейшей разработки приложений.  ^ Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью.  Логическая модель данных является начальным прототипом будущей базы данных.  Логическая модель строится в терминах информационных единиц, но без привязки к конкретной СУБД.  Логическая модель данных необязательно должна быть выражена средствами именно реляционной модели данных. Основным средством разработки логической модели данных в настоящий момент являются различные варианты ER-диаграмм (Entity-Relationship, диаграммы сущность-связь).  ^ Физическая модель данных описывает данные средствами конкретной СУБД.  Отношения, разработанные на стадии формирования логической модели данных, преобразуются в таблицы, атрибуты становятся столбцами таблиц, для ключевых атрибутов создаются уникальные индексы, домены преображаются в типы данных, принятые в конкретной СУБД.  Ограничения, имеющиеся в логической модели данных, реализуются различными средствами СУБД. При этом решения, принятые на уровне логического моделирования определяют некоторые границы, в пределах которых можно развивать физическую модель данных.  ^ 12) Нормальные формы отношений Нормальная форма — свойство отношения в реляционной модели данных, характеризующее его с точки зрения избыточности, которая потенциально может привести к логически ошибочным результатам выборки или изменения данных. Нормальная форма определяется как совокупность требований, которым должно удовлетворять отношение. Процесс преобразования базы данных к виду, отвечающему нормальным формам, называется нормализацией. Нормализация предназначена для приведения структуры базы данных к виду, обеспечивающему минимальную избыточность, то есть нормализация не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение объёма БД. Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в БД информации. Устранение избыточности производится, как правило, за счёт декомпозиции отношений таким образом, чтобы в каждом отношении хранились только первичные факты (то есть факты, не выводимые из других хранимых фактов). ^ Функциональные зависимости Для правильного проектирования модели данных применяется метод нормализации отношений. Нормализация основана на понятии функциональной зависимости атрибутов отношения.  Пусть R - отношение. Множество атрибутов Y функционально зависимо от множества атрибутов X (X функционально определяет Y) тогда и только тогда, когда для любого состояния отношения R для любых кортежей r1,r2R из того, что r1X=r2X следует что r1Y=r2YY (т.е. во всех кортежах, имеющих одинаковые значения атрибутов X, значения атрибутов Y также совпадают в любом состоянии отношения R). Символически функциональная зависимость записывается X Множество атрибутов X называется детерминантом функциональной зависимости, а множество атрибутов Y называется зависимой частью. Замечание. Если атрибуты X составляют потенциальный ключ отношения R, то любой атрибут отношения R функционально зависит от X.  Замечание. Функциональные зависимости отражают взаимосвязи, обнаруженные между объектами предметной области и являются дополнительными ограничениями, определяемыми предметной областью. Таким образом, функциональная зависимость - семантическое понятие. Она возникает, когда по значениям одних данных в предметной области можно определить значения других данных. Например, зная табельный номер сотрудника, можно определить его фамилию, по номеру отдела можно определить телефона.  ^ Типы нормальных форм Первая нормальная форма (1НФ) - это обычное отношение. Любое отношение автоматически уже находится в 1НФ.  Свойства отношений (это и будут свойства 1НФ):  - в отношении нет одинаковых кортежей.  - кортежи не упорядочены.  - атрибуты не упорядочены и различаются по наименованию.  - все значения атрибутов атомарны.  ^ Вторая нормальная форма (2НФ) Отношение находится во второй нормальной форме (2НФ) тогда и только тогда, когда отношение находится в 1НФ и нет неключевых атрибутов, зависящих от части сложного ключа.  Неключевой атрибут - это атрибут, не входящий в состав никакого потенциального ключа.  Замечание. Если потенциальный ключ отношения является простым, то отношение автоматически находится в 2НФ.  Для устранения функциональной зависимости атрибута от части сложного ключа производят декомпозицию отношений на несколько. Те атрибуты, которые зависят от части сложного ключа выносятся в отдельное отношение. ^ Третья нормальная форма (3НФ) Отношение находится в третьей нормальной форме (3НФ) тогда и только тогда, когда отношение находится в 2НФ и все неключевые атрибуты взаимно независимы.  Атрибуты называются взаимно независимыми, если ни один из них не является функционально зависимым от другого.  Нормализация: неключевые атрибуты, которые являются зависимыми, выносятся в отдельное отношение. ^ Нормальная форма Бойса-Кодда (BCNF) Отношение находится в нормальной форме Бойса-Кодда, если оно находится в третьей нормальной форме и каждый детерминант отношения является потенциальными ключами отношения (отсутствуют функциональные зависимости атрибутов первичного ключа от неключевых атрибутов.) ^ Четвертая нормальная форма (4НФ) Многозначные зависимости – случаи, когда одному значению некоторого атрибута устойчиво соответствует постоянное множество значений другого атрибута.  Отношение находится в 4НФ, если она находится в BCNF и не содержит нетривиальных многозначных зависимостей, то есть, отношение находится в 4NF, если все ее многозначные зависимости являются функциональными. ^ Пятая нормальная форма (5НФ) Отношение находится в 5НФ только в том случае, если оно находится в 4НФ и если любая зависимость соединения в отношении следует из существования некоторого потенциального ключа в отношении. ^ Алгоритм нормализации Шаг 1 (Приведение к 1НФ). На первом шаге задается одно или несколько отношений, отображающих понятия предметной области. По модели предметной области (не по внешнему виду полученных отношений!) выписываются обнаруженные функциональные зависимости. Все отношения автоматически находятся в 1НФ.  ^ Шаг 2 (Приведение к 2НФ). Если в некоторых отношениях обнаружена зависимость атрибутов от части сложного ключа, то проводим декомпозицию этих отношений на несколько отношений следующим образом: те атрибуты, которые зависят от части сложного ключа выносятся в отдельное отношение вместе с этой частью ключа. В исходном отношении остаются все ключевые атрибуты ^ Шаг 3 (Приведение к 3НФ). Если в некоторых отношениях обнаружена зависимость некоторых неключевых атрибутов других неключевых атрибутов, то проводим декомпозицию этих отношений следующим образом: те неключевые атрибуты, которые зависят других неключевых атрибутов выносятся в отдельное отношение. В новом отношении ключом становится детерминант функциональной зависимости ^ 13) Модель сущность-связь Сущность – множество экземпляров реальных или абстрактных объектов, обладающих общими атрибутами или характеристиками. Сущность – класс однотипных объектов. Атрибут сущности – именованная характеристика, являющаяся некоторым свойством сущности. ^ Ключ сущности – неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности. Связь – некоторая ассоциация между двумя сущностями: - один-к-одному - один-ко-многим -много-ко-многим ^ Модальности связи: - может  - должен  Модель Сущность-Связь (ER-модель) (англ. entity-relationship model или entity-relationship diagram) — это модель данных, позволяющая описывать концептуальные схемы. Она предоставляет графическую нотацию, основанную на блоках и соединяющих их линиях, с помощью которых можно описывать объекты и отношения между ними какой-либо другой модели данных. В этом смысле ER-модель является средством описания моделей данных. ER-модель удобна при прототипировании (проектировании) информационных систем, баз данных, архитектур компьютерных приложений, и других систем (далее, моделей). С её помощью можно выделить ключевые сущности, присутствующие в модели, и обозначить отношения, которые могут устанавливаться между этими сущностями. Важно отметить, что сами отношения также являются сущностями (выделяются в отдельные графические блоки), что позволяет устанавливать отношения на множестве самих отношений. ER-модель является одной из самых простых визуальных моделей данных (графических нотаций). Она позволяет обозначить структуру «крупными мазками», в общих чертах. Это общее описание структуры называется ER-диаграммой или онтологией выбранной предметной области (area of interest). На этапе перехода к реализации данной ER-диаграммы в виде реальной информационной системы или программы, происходит отображение ER-модели в более детальную модель данных реляционной (объектной, сетевой, логической, или др.) базы данных, которая называется физической моделью данных по отношению к исходной ER-диаграмме. Существует несколько графических нотаций описания ER-диаграм (несколько похожих ER-моделей данных). Есть несколько типичных примеров использования ER-модели данных: IDEF1x (ICAM DEFinition Language) и dimensional modelling.-0 ^ 14) Технология "клиент-сервер" В сфере обработки данных сегодня существует множество противоречий в вопросах реализации архитектуры приложения, взаимодействующего с базой данных. У каждого может существовать собственное мнение идея о наилучшей архитектуре для всех существующих систем. Какая-либо определенная архитектура может быть идеальной только для конкретной задачи.  Не возможно найти единственное правильное решение для всех возможных систем.  Существует три группы сервисов: User Services (Сервисы пользователя). Как правило, эти сервисы отвечают за пользовательский интерфейс, базисное форматирование и правила полей. Сервисы пользователя могут поддерживать, например, корректное форматирование даты: определять соответствующее поле как поле даты и проверять то, что каждое заносимое в это поле значение является датой. В принципе, основное назначение пользовательских сервисов - это управление способом представления каждого поля и проверка, по крайней мере, его типа данных. ^ Business Services (Бизнес-сервисы). Это группа отвечает за различные бизнес-правила. Примером бизнес-сервисов, может быть сервис, который связывается с компанией кредитной карты клиента, чтобы подтвердить покупку по кредитной карте.  ^ Data services (Сервисы данных). Все сервисы данного типа отвечают за хранение и поиск данных. Сервисы данных следят за выполнением правил целостности данных (например, объем товарно-материальных запасов не может быть меньше нуля), но в то же время не обращают внимания на то, откуда пришло подтверждение кредитной карты. (Здесь и находится SQL Server.)  ^ Одноуровневые (хост) системы Это старая архитектура на основе универсальной машины (мэйнфрейма). В данной архитектуре все три группы сервисов выполняются в одном месте. В таких системах на рабочем столе находился только терминал, то есть фактически не было локальных вычислительных средств. На терминал пересылалась только выходная информация, которая включала данные для изображения на экране. Преимущества: - не требует высокой пропускной способности сети для хорошей скорости ответа, что является положительным фактором для международных или глобальных сетей, в которых высокая пропускная способность обходится очень дорого - такие системы обладают исключительной надежностью. Можно найти универсальные машины, которые не имели ни одного сбоя в течение нескольких лет - очень легко устанавливать новое программное обеспечение. Его необходимо установить только на хост-системе и каждый пользователь будет иметь новую версию без переустановки на каждой локальной машине. Недостатки: - очень дорогое аппаратное обеспечение.  - передача информации от одной системы к другой часто является трудной задачей, так как форматы данных таких систем, как правило, запатентованы. - очень ограничено количество уже готовых к использованию пакетов программного обеспечения. Стоимость таких пакетов очень высокая в связи с ограниченным количеством потенциальных покупателей. ^ Двухуровневая архитектура (клиент-сервер) Клиент-сервер (англ. Client-server) — сетевая архитектура, в которой устройства являются либо клиентами, либо серверами.  Клиентом (front end) является запрашивающая машина (обычно ПК), сервером (back end) — машина, которая отвечает на запрос. Оба термина (клиент и сервер) могут применяться как к физическим устройствам, так и к программному обеспечению. Двухуровневые или клиент-серверные системы начали завоевывать популярность в начале 90-х.  Технология клиент-сервер означает такой способ взаимодействия программных компонентов, при котором они образуют единую систему.  Как видно из самого названия, существует некий клиентский процесс, требующий определенных ресурсов, а также серверный процесс, эти ресурсы предоставляющий. Совсем необязательно, чтобы они находились на одном компьютере. Обычно принято размещать сервер на одном узле локальной сети, а клиентов – на других узлах. Существовали две разновидности такой архитектуры: - клиентоцентрическая (Client-centric - разумный клиент)  - сервероцентрическая (server-centric — разумный сервер). ^ Клиентоцентрическая версия клиент-серверной архитектуры была основана на двух основных посылках: - персональные компьютеры достаточно дешевы (это явилось основной движущей силой развития клиент-серверной технологии); - максимальная мощность достигается путем максимального распределения необходимых вычислений. В такой системе на сервере по возможности исполнялись только сервисы данных. А бизнес-сервисы и пользовательский интерфейс исполнялись наклиенте. Таким образом, объем работы распределялся между клиентом и сервером. Каждый компьютер делал свою долю. Преимущества: - распределяет объем работы между большим количеством сравнительно дешевых клиентов. - если одному из пользователей нужна большая скорость, есть возможность приобрести для него более мощную систему. Это значительно легче, чем покупать большую дорогую хост-систему, мощность которой разделится между всеми клиентами. - при вложении средств в увеличение вычислительной мощности клиента увеличивается мощность и других его программных средств, таких как текстовый процессор и редактор таблиц. Недостатки: - наибольшей проблемой клиентоцентрической архитектуры является ее пропускная способность. Если вся бизнес-логика находится на клиенте, то, скорей всего, трафик между клиентом и сервером будет достаточно большим. Клиенту посылается много необработанной информации, что очень быстро засоряет сеть и снижает скорость работы всех остальных клиентов.  - инсталляция занимает много времени и очень сложна. Новое программное обеспечение или его новая версия должны быть установлены на все машины. Обновление версий может быть достаточно проблематичным из-за того, что старые клиенты не всегда совместимы с новыми компонентами сервера и наоборот. Достаточно серьезные проблемы могут быть связаны с тем, что все клиенты должны обновляться одновременно. - каждый клиент, в зависимости от его поставщика, может нуждаться в отдельной лицензии для каждого местонахождения или подключения. Это может увеличить стоимость. ^ Сервероцентрическая архитектура основана на той посылке, что вычислительная мощность персональных компьютеров дешевле хост-системы, однако в то же время сделана попытка получить некоторые преимущества от централизации. ^ На клиенте работают только пользовательские сервисы. По существу, клиенту передается только та информация, которая будет выводиться на экран.  Бизнес-сервисы и сервисы данных выполняются на сервере. Загруженность сети у такой архитектуры почти такая же, как у обычных хост-систем. Преимущества: - некоторые обновления можно делать непосредственно на сервере. - доступно большое количество уже готовых программных продуктов, причем готовое программное обеспечение стоит дешево. - так как по сети пересылается только та информация, которую нужно отображать на экране, трафик в такой системе меньше по сравнению с клиентоцентрической архитектурой. Недостатки: - многие обновления все еще требуют непосредственной работы с каждым клиентом, очень утомительно и трудно (с точки зрения учета и контроля) обновлять и устанавливать новое программное обеспечение. - продолжительные и трудоемкие задания одного из клиентов влияют на возможность использования ресурсов сервера всеми остальными клиентами. - цена больших серверов растет экспоненциально. Некоторые из них сравнимы по цене с хост-системами. ^ Трехуровневая архитектура Трехуровневая модель и близкая ей N-уровневая являются наиболее перспективными на сегодняшний день.  В этой модели все три уровня сервисов рассматриваются как разделенные и логически независимые. Клиенты отвечают только за пользовательский интерфейс, так же как это имеет место в сервероцентрической клиент-серверной модели.  Отличие состоит в том, что бизнес-сервисы и сервисы данных тоже логически разделены.  Такое представление делает независимыми друг от друга логическую и физическую модели. Преимущества: - некоторые обновления могут быть сделаны непосредственно на сервере. - доступно большое количество уже готовых программных продуктов, а готовое программное обеспечение стоит значительно дешевле. - так как по сети пересылается только та информация, которую необходимо отображаться на экране, то трафик сети в таких системах намного меньше по сравнению с клиентоцентрической моделью. Хотя, если системы бизнес-логики и сервисов данных находятся на разных серверах, загруженность сети между ними может быть достаточно большой. - предусматривается (фактически поощряется) разработка систем на основе компонентов, что может увеличить степень повторного использования. - два средних сервера, как правило, дешевле, чем один большой. Разделение бизнес-сервисов и сервисов данных делает возможным выбор между одним или двумя серверами. Недостатки: - многие обновления все еще предполагают непосредственную работу с каждым клиентом, поэтому обновление и установка нового программного обеспечения трудоемки и требуют тщательного учета. - возникает острая необходимость в системе безопасности и инфраструктуре.  - неработоспособность сервера может сделать неработоспособной сеть. - администрирование данной системы требует квалифицированного профессионала. - высокая стоимость оборудования. ^ 15) Обзор MS SQL Server, клиентские приложения, системные таблицы SQL-сервер - сервер для управления реляционными БД.  Microsoft SQL Server 2000 - это система управления базами данных и анализа, предназначенная для быстрой разработки современных масштабируемых бизнес-приложений, систем электронной коммерции и информационных хранилищ; мощная СУБД, в полной мере отвечающая потребностям современных сложных систем типа клиент/сервер. Масштабируемость Механизм баз данных SQL Server представляет собой надежный сервер, способный управлять базами данных терабайтного объема, к которым одновременно обращаются тысячи пользователей. В то же время при работе с параметрами по умолчанию SQL Server 2000 поддерживает такие функции, как динамическая самонастройка, что позволяет не обременять пользователей решением административных задач. Именно эта возможность делает его чрезвычайно привлекательным для применения в настольных системах.  В сервер SQL Server 2000 включена поддержка языка XML и протокола HTTP, средства повышения быстродействия и доступности, позволяющие распределить нагрузку и обеспечить бесперебойную работу, функции для улучшения управления и настройки, снижающие совокупную стоимость владения.  Кроме того, SQL Server 2000 полностью использует все возможности операционной системы Windows 2000, включая поддержку до 32 процессоров и 64 ГБ ОЗУ. SQL Server 2000 работает с базами данных в OLTP-окружении (on-line transaction processing – оперативная обработка транзакций) и в окружении OLAP(on- line analytical processing аналитическая обработка в реальном времени) Существует семь различных редакций сервера SQL 2000: - Enterprise Edition – эта редакция является полной версией сервера SQL. - Standard Edition – эта редакция разработана для малых и средних предприятий.  - Personal Edition – эта редакция основывается на Standard Edition, но оптимизирована для индивидуального использования.  - Developer Edition -такая же как Enterprise Edition, только имеет ограниченную лицензию, которая не может быть использована в производственных средах. - Enterprise Evaluation Edition – такая же как Enterprise Edition, но имеющая лицензию для «демонстрации, тестирования, изучения и оценки» и имеет 120-дневное ограничение использования. - Windows CE Edition – эта редакция разработана для использования на устройствах, работающих под Windows CE. - Desktop Engine (MSDE) – эта редакция представляет из себя только процессор базы данных сервера SQL 2000.  Службы SQL Server  ^ 1. MSSQL Server Service - управление базами данных, обработка транзакций и запросов, обеспечение целостности данных. 2. SQLServerAgent Service - выполнение заданий по расписанию, создание и управление предупреждений (alerts) b операторов. ^ 3. Microsoft Distributed Transaction Coordinator (координатор распределенных транзакций) управление распределенными транзакциями. 4. Microsoft Search - полнотекстовый поиск Визуальные средства администрирования: 1. SQL Server Service Manager - диспетчер служб SQL Server ^ 2. SQL Server Enterprise Manager - позволяет управлять несколькими серверами баз данных с помощью одного интерфейса 3. SQL Query Analyzer (координатор распределенных транзакций) управление распределенными транзакциями. ^ 4. SQL Server Network Utility позволяет конфигурировать подключения в клиентской части, узнать версию используемых сетевых библиотек 5. SQL Profiler – графическое средство отображения активности выбранного сервера. Сопутствующие продукты SQL Server ^ 1. Microsoft English Query - инструмент, позволяющий преобразовать фразу на английском языке в набор операторов SQL. 2. Службы анализа данных позволяют создать базы данных OLAP, используемые для выполнения многомерного анализа информации. ^ 3. Утилиты командной строки  BCP программа массового копирования ISQL – позволяет выполнять запросы с командной строки (использует DB-library для взаимодействия SQL Server) OSQL – позволяет выполнять запросы с командной строки (использует ODBC для взаимодействия SQL Server) ^ Типы баз данных в SQL Server В процессе установки SQL Server создаются системные базы данных master, model, tempdb, msdb, distribution и двепользовательские базы данных в качестве примера Northwind и pubs. 1. Master содержит специальный набор системных таблиц, которые отслеживают целиком всю систему 2. Model является моделью, по которой создается новая база данных 3. Tempdb содержит временные объекты  4. Msdb содержит системные задачи SQL Agent 5. Distribution содержит историю и транзакции данных, используемых при репликации  16) Основы языка SQL, типы команд SQL (англ. Structured Query Language — язык структурированных запросов) — универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных базах данных.  SQL основывается на реляционной алгебре. ^ Основные категории команд языка SQL: - DDL (Data Definition Language) – язык определения данных. Основными командами языка DDL являются следующие: CREATE TABLE, ALTER TABLE, DROP TABLE, CREATE INDEX, ALTER INDEX, DROP INDEX. - DML (Data Manipulation Language) – язык манипулирования данными. Основными командами языка DML являются следующие: INSERT, UPDATE, DELETE.  - DQL (Data Query Language) – язык запросов. Единственная команда языка DQL: SELECT.  - DCL – язык управления данными. Команды управления данными следующие: GRANT, REVOKE - команды администрирования данных. С помощью команд администрирования данных пользователь осуществляет контроль за выполняемыми действиями и анализирует операции базы данных; они также могут оказаться полезными при анализе производительности системы.  - команды управления транзакциями. Существуют следующие команды, позволяющие управлять транзакциями базы данных: COMMIT, ROLLBACK, SAVEPOINT, SET TRANSACTION. ^ Запись SQL-операторов Оператор SQL состоит из зарезервированных слов, а также из слов, определяемых пользователем.  Зарезервированные слова являются постоянной частью языка SQL и имеют фиксированное значение. Их следует записывать в точности так, как это установлено, нельзя разбивать на части для переноса с одной строки на другую. Слова, определяемые пользователем, задаются им самим (в соответствии с синтаксическими правилами) и представляют собой идентификаторы или имена различных объектов базы данных. Слова в операторе размещаются также в соответствии с установленными синтаксическими правилами. Стандарт SQL задает набор символов, который используется по умолчанию, – он включает строчные и прописные буквы латинского алфавита (A-Z, a-z), цифры (0-9) и символ подчеркивания (_).  На формат идентификатора накладываются следующие ограничения: - идентификатор может иметь длину до 128 символов;  - идентификатор должен начинаться с буквы;  - идентификатор не может содержать пробелы.  Символ Обозначение ::= равно по определению | необходимость выбора одного из нескольких значений <…> описанная с помощью метаязыка структура языка {…} обязательный выбор некоторой конструкции из списка […] необязательный выбор некоторой конструкции из списка [,…n] необязательная возможность повторения конструкции от нуля до нескольких раз 17) Основной синтаксис оператора SELECT ^ Оператор SELECT – один из наиболее важных и самых распространенных операторов SQL. Он позволяет производить выборки данных из таблиц и преобразовывать к нужному виду полученные результаты. Будучи очень мощным, он способен выполнять действия, эквивалентные операторам реляционной алгебры, причем в пределах единственной выполняемой команды. При его помощи можно реализовать сложные и громоздкие условия отбора данных из различных таблиц. ^ Оператор SELECT – средство, которое полностью абстрагировано от вопросов представления данных, что помогает сконцентрировать внимание на проблемах доступа к данным.  Операции над данными производятся в масштабе наборов данных, а не отдельных записей. Основной синтаксис ^ SELECT [ALL | DISTINCT ]  {* | [имя_столбца [AS новое_имя]]} [,...n] FROM имя_таблицы [[AS] псевдоним] [,...n]  [WHERE <условие_поиска>]  [GROUP BY имя_столбца [,...n]]  [HAVING <критерии выбора групп>]  [ORDER BY имя_столбца [,...n]]  Оператор SELECT определяет поля (столбцы), которые будут входить в результат выполнения запроса.  В списке они разделяются запятыми и приводятся в такой очередности, в какой должны быть представлены в результате запроса.  Если используется имя поля, содержащее пробелы или разделители, его следует заключить в квадратные скобки.  Символом * можно выбрать все поля. Если обрабатывается ряд таблиц, то (при наличии одноименных полей в разных таблицах) в списке полей используется полная спецификация поля, т.е. Имя_таблицы.Имя_поля.  Обработка элементов оператора SELECT выполняется в следующей последовательности: ^ FROM – определяются имена используемых таблиц;  WHERE – выполняется фильтрация строк объекта в соответствии с заданными условиями;  GROUP BY – образуются группы строк , имеющих одно и то же значение в указанном столбце;  ^ HAVING – фильтруются группы строк объекта в соответствии с указанным условием;  SELECT – устанавливается, какие столбцы должны присутствовать в выходных данных;  ORDER BY – определяется упорядоченность результатов выполнения операторов.  ^ Предложение FROM задает имена таблиц и представлений, которые содержат поля, перечисленные в операторе SELECT. Необязательный параметр псевдонима – это сокращение, устанавливаемое для имени таблицы. ^ Параметр WHERE определяет критерий отбора записей из входного набора. Но в таблице могут присутствовать повторяющиеся записи (дубликаты). Предикат ALL задает включение в выходной набор всех дубликатов, отобранных по критерию WHERE (это значение действует по умолчанию). Предикат DISTINCT следует применять в тех случаях, когда требуется отбросить блоки данных, содержащие дублирующие записи в выбранных полях.  С помощью WHERE-параметра пользователь определяет, какие блоки данных из приведенных в списке FROM таблиц появятся в результате запроса.  За ключевым словом WHERE следует перечень условий поиска, определяющих те строки, которые должны быть выбраны при выполнении запроса.  Существует пять основных типов условий поиска (или предикатов): 1. Сравнение: сравниваются результаты вычисления одного выражения с результатами вычисления другого.  2. Диапазон: проверяется, попадает ли результат вычисления выражения в заданный диапазон значений.  3. Принадлежность множеству: проверяется, принадлежит ли результат вычислений выражения заданному множеству значений.  4. Соответствие шаблону: проверяется, отвечает ли некоторое строковое значение заданному шаблону.  5. Значение NULL: проверяется, содержит ли данный столбец определитель NULL (неизвестное значение).  В языке SQL можно использовать следующие операторы сравнения:  • = – равенство;  • < – меньше;  • >– больше;  • <= – меньше или равно; • >= – больше или равно;  • <>,!= – не равно. Более сложные предикаты могут быть построены с помощью логических операторов AND, OR или NOT, а также скобок, используемых для определения порядка вычисления выражения. Вычисление выражения в условиях выполняется по следующим правилам: Выражение вычисляется слева направо.  Первыми вычисляются подвыражения в скобках.  Операторы NOT выполняются до выполнения операторов AND и OR.  Операторы AND выполняются до выполнения операторов OR.  Для устранения любой возможной неоднозначности рекомендуется использовать скобки. ^ Оператор BETWEEN используется для поиска значения внутри некоторого интервала, определяемого своими минимальным и максимальным значениями. При этом указанные значения включаются в условие поиска. При использовании отрицания NOT BETWEEN требуется, чтобы проверяемое значение лежало вне границ заданного диапазона. Оператор IN используется для сравнения некоторого значения со списком заданных значений, при этом проверяется, соответствует ли результат вычисления выражения одному из значений в предоставленном списке. При помощи оператора IN может быть достигнут тот же результат, что и в случае применения оператора OR, однако оператор IN выполняется быстрее. NOT IN используется для отбора любых значений, кроме тех, которые указаны в представленном списке. С помощью оператора LIKE можно выполнять сравнение выражения с заданным шаблоном, в котором допускается использование символов-заменителей: Символ % – вместо этого символа может быть подставлено любое количество произвольных символов.  Символ _ заменяет один символ строки.  [] – вместо символа строки будет подставлен один из возможных символов, указанный в этих ограничителях.  [^] – вместо соответствующего символа строки будут подставлены все символы, кроме указанных в ограничителях.  ^ Оператор IS NULL используется для сравнения текущего значения со значением NULL – специальным значением, указывающим на отсутствие любого значения.  IS NOT NULL используется для проверки присутствия значения в поле. Параметр ORDER BY сортирует данные выходного набора в заданной последовательности.  Сортировка может выполняться по нескольким полям, в этом случае они перечисляются за ключевым словом ORDER BY через запятую.  Способ сортировки задается ключевым словом, указываемым в рамках параметра ORDER BY следом за названием поля, по которому выполняется сортировка.  По умолчанию реализуется сортировка по возрастанию. Явно она задается ключевым словом ASC. Для выполнения сортировки в обратной последовательности необходимо после имени поля, по которому она выполняется, указать ключевое слово DESC.  ^ Построение вычисляемых полей В общем случае для создания вычисляемого (производного) поля в списке SELECT следует указать некоторое выражение языка SQL.  В этих выражениях применяются арифметические операции сложения, вычитания, умножения и деления, а также встроенные функции языка SQL.  Можно указать имя любого столбца (поля) таблицы или запроса, но использовать имя столбца только той таблицы или запроса, которые указаны в списке предложения FROM соответствующей инструкции. При построении сложных выражений могут понадобиться скобки. Стандарты SQL позволяют явным образом задавать имена столбцов результирующей таблицы, для чего применяется фраза AS. ^ Использование итоговых функций С помощью итоговых (агрегатных) функций в рамках SQL-запроса можно получить ряд обобщающих статистических сведений о множестве отобранных значений выходного набора. Пользователю доступны следующие основные итоговые функции: Count (Выражение) - определяет количество записей в выходном наборе SQL-запроса;  Min/Max (Выражение) - определяют наименьшее и наибольшее из множества значений в некотором поле запроса;  Avg (Выражение) - эта функция позволяет рассчитать среднее значение множества значений, хранящихся в определенном поле отобранных запросом записей.  Sum (Выражение) - вычисляет сумму множества значений, содержащихся в определенном поле отобранных запросом записей. Чаще всего в качестве выражения выступают имена столбцов. Выражение может вычисляться и по значениям нескольких таблиц. ^ 18) Построение нетривиальных запросов с использованием оператора SELECT Параметр Join При работе в нормализованном окружении часто возникает ситуация, когда не вся необходимая информация находится в одной таблице. Именно в таких ситуациях необходимо применять параметр JOIN. Параметр JOIN помещает (объединяет) информацию из двух таблиц в одно результирующее множество, которое можно представить в виде “виртуальной таблицы”. С этим множеством можно работать как с обычной таблицей и использовать его для других подзапросов. Способ объединения таблиц задается выбором одного из четырех различных видов JOIN. Общим для всех видов JOIN является то, что они для одной записи некоторой таблицы находят одну или более соответствующих записей в других таблицах чтобы создать запись-супермножество, которая будет содержать поля обеих записей. ^ Базовый синтаксис JOIN выглядит следующим образом.  SELECT  FROM <первая_таблица> <тип_объединения> <вторая_таблица> [ON <условие_объединения>]  Параметр INNER JOIN является наиболее распространенным видом JOIN, он объединяет записи на основе одного или более общих полей, но возвращает только те записи, для которых имеет место соответствие по полям, указанным в JOIN. SELECT  FROM <первая_таблица> ^ INNER JOIN <вторая_таблица> ON <условие_объединения> Если использовать * в списке полей вывода, тогда будут возвращены все столбцы таблиц. Для того чтобы * использовать для отдельной таблицы, нужно указать следующим образом: SELECT Orders.*, CompanyName  FROM Orders INNER JOIN Customers ON Orders.CustomerID=Customers.CustomerID  Если необходимо обратиться к столбцу, имя которого присутствует более одного раза в JOIN-результате, нужно полностью определить имя столбца:  Таблица.ИмяСтолбца, Псевдоним.ИмяСтолбца ^ OUTER JOIN SELECT  FROM <первая_таблица (считается левой)> {LEFT|RIGHT|FULL} [OUTER] JOIN <вторая_таблица (считается правой)> ON <условие_объединения> OUTER JOIN является включающим объединением. Объединение происходит по совпадающим данным, но также в случае LEFT включается вся информация из левой таблицы, RIGHT- из правой, FULL включает всю информацию из обеих таблиц. ^ CROSS JOIN (перекрестное объединение) объединяет каждую запись с одной стороны JOIN с каждой записью с другой стороны JOIN. SELECT  FROM <первая_таблица > ^ CROSS JOIN <вторая_таблица > UNION – специальный оператор, с помощью которого можно построить из двух или более запросов одно результирующее множество. По сути работа этого параметра похожа на присоединение выходных данных одного запроса к выходным данным другого запроса: - Все запросы, объединенные этим оператором должны иметь одинаковое количество столбцов в SELECT-списке. - В качестве заголовков столбцов результирующего множества будут использоваться заголовки столбцов первого запроса. - Тип данных каждого столбца должен быть хотя бы неявно совместим с типом данных соответствующего столбца другого запроса. - По умолчанию используется режим вывода DISTINCT, а не ALL.  ^ Использование в объединении производных таблиц Производная таблица создается из столбцов и строк, полученных в результате запроса.  Для её создания необходимо заключить запрос в скобки и задать для результата запроса псевдоним.  Затем эту производную таблицу можно использовать в операторе JOIN как обычную. Вывести названия компаний, заказавших ‘Chocolade’ и ‘Tofu’ SELECT DISTINCT c.CompanyName FROM dbo.Customers c ^ INNER JOIN (SELECT CustomerID FROM dbo.Orders o  INNER JOIN dbo.[Order Details] od ON o.OrderID=od.OrderID INNER JOIN dbo.Products p ON p.ProductID=od.ProductID WHERE p.ProductName='Chocolade') AS choc ON c.CustomerID=choc.CustomerID ^ INNER JOIN (SELECT CustomerID FROM dbo.Orders o  INNER JOIN dbo.[Order Details] od ON o.OrderID=od.OrderID INNER JOIN dbo.Products p ON p.ProductID=od.ProductID WHERE p.ProductName='Tofu') AS T ON c.CustomerID=T.CustomerID ^ Понятие подзапроса Часто невозможно решить поставленную задачу путем одного запроса. Это особенно актуально, когда при использовании условия поиска в предложении WHERE значение, с которым надо сравнивать, заранее не определено и должно быть вычислено в момент выполнения оператора SELECT.  В таком случае приходят на помощь законченные операторы SELECT, внедренные в тело другого оператора SELECT.  Внутренний подзапрос представляет собой также оператор SELECT, а кодирование его предложений подчиняется тем же правилам, что и основного оператора SELECT.  Внешний оператор SELECT использует результат выполнения внутреннего оператора для определения содержания окончательного результата всей операции. Внутренние запросы могут быть помещены непосредственно после оператора сравнения (=, <, >, <=, >=, <>) в списке полей вывода оператора SELECT, в предложения WHERE и HAVING внешнего оператора SELECT – они получают название подзапросов или вложенных запросов.  Подзапрос – это инструмент создания временной таблицы, содержимое которой извлекается и обрабатывается внешним оператором.  Текст подзапроса должен быть заключен в скобки.  К подзапросам применяются следующие правила и ограничения: - фраза ORDER BY не используется, хотя и может присутствовать во внешнем подзапросе;  - список в предложении SELECT состоит из имен отдельных столбцов или составленных из них выражений – за исключением случая, когда в подзапросе присутствует ключевое слово EXISTS;  - по умолчанию имена столбцов в подзапросе относятся к таблице, имя которой указано в предложении FROM. Однако допускается ссылка и на столбцы таблицы, указанной во фразе FROM внешнего запроса, для чего применяются квалифицированные имена столбцов (т.е. с указанием таблицы);  - если подзапрос является одним из двух операндов, участвующих в операции сравнения, то запрос должен указываться в правой части этой операции. Можно выделить типы подзапросов: 1. Скалярный подзапрос возвращает единственное значение. В принципе, он может использоваться везде, где требуется указать единственное значение.  ^ 2. Табличный подзапрос возвращает множество значений, т.е. значения одного или нескольких столбцов таблицы, размещенные в более чем одной строке. Он возможен везде, где допускается наличие таблицы. Определить Номер компании, сделавшей самый последний заказ SELECT CustomerID FROM Orders WHERE OrderDate=(SELECT MAX(OrderDate) FROM Orders) Указать для каждого заказа номер, стоимость, и отклонение стоимости данного заказа от максимальной стоимости заказа SELECT OrderID, SUM(UnitPrice*Quantity*(1-Discount)) as Summ, SUM(UnitPrice*Quantity*(1-Discount))- (SELECT TOP 1 SUM(UnitPrice*Quantity*(1-Discount)) FROM [Order Details] GROUP BY OrderID ORDER BY SUM(UnitPrice*Quantity*(1-Discount))DESC)  FROM [Order Details] GROUP BY OrderID ^ Подзапросы, возвращающие множество значений Во многих случаях значение, подлежащее сравнению в предложениях WHERE или HAVING, представляет собой не одно, а несколько значений.  Вложенные подзапросы генерируют непоименованное промежуточное отношение, временную таблицу. Оно может использоваться только в том месте, где появляется в подзапросе. К такому отношению невозможно обратиться по имени из какого-либо другого места запроса. Применяемые к подзапросу операции основаны на тех операциях, которые, в свою очередь, применяются к множеству, а именно: - { WHERE | HAVING } выражение [ NOT ] IN (подзапрос);  - { WHERE | HAVING } выражение оператор_сравнения { ALL | SOME | ANY }(подзапрос); - {WHERE | HAVING } [ NOT ] EXISTS (подзапрос); ^ Использование операций IN и NOT IN Оператор IN используется для сравнения некоторого значения со списком значений, при этом проверяется, входит ли значение в предоставленный список или сравниваемое значение не является элементом представленного списка. Определить номера заказов, сделанных клиентами из Berlin SELECT OrderID FROM Orders  WHERE CustomerID IN  (SELECT CustomerID FROM Customers WHERE City=‘Berlin’)  ^ Использование ключевых слов ANY и ALL Ключевые слова ANY и ALL могут использоваться с подзапросами, возвращающими один столбец чисел.  Если подзапросу будет предшествовать ключевое слово ALL, условие сравнения считается выполненным, только когда оно выполняется для всех значений в результирующем столбце подзапроса.  Если записи подзапроса предшествует ключевое слово ANY, то условие сравнения считается выполненным, когда оно выполняется хотя бы для одного из значений в результирующем столбце подзапроса.  Если в результате выполнения подзапроса получено пустое значение, то для ключевого слова ALL условие сравнения будет считаться выполненным, а для ключевого слова ANY – невыполненным. Ключевое слово SOME является синонимом слова ANY. Все эти операторы применяется с любыми операторами сравнения Найти номера заказов, сделанных в 1996 году, в которых количество товара с номером 36, превышает хотя бы раз такой же показатель в заказах 1998 на этот товар. SELECT [Order Details].OrderID,Quantity FROM [Order Details] INNER JOIN Orders ON [Order Details].OrderID=Orders.OrderID WHERE Quantity>SOME (SELECT Quantity FROM [Order Details] INNER JOIN Orders ON [Order Details].OrderID=Orders.OrderID WHERE ProductID=36 AND YEAR(OrderDate)=1998)  AND ProductID=36 AND YEAR(OrderDate)=1996 ^ Использование операций EXISTS и NOT EXISTS Ключевые слова EXISTS и NOT EXISTS предназначены для использования только совместно с подзапросами.  Результат их обработки представляет собой логическое значение TRUE или FALSE.  Для ключевого слова EXISTS результат равен TRUE в том и только в том случае, если в возвращаемой подзапросом результирующей таблице присутствует хотя бы одна строка.  Если результирующая таблица подзапроса пуста, результатом обработки операции EXISTS будет значение FALSE.  Для ключевого слова NOT EXISTS используются правила обработки, обратные по отношению к ключевому слову EXISTS.  Поскольку по ключевым словам EXISTS и NOT EXISTS проверяется лишь наличие строк в результирующей таблице подзапроса, то эта таблица может содержать произвольное количество столбцов. Определить названия компаний, разместивших по крайней мере один заказ SELECT CompanyName FROM Customers cu ^ WHERE EXISTS (SELECT OrderID FROM Orders o WHERE o.CustomerID=cu.CustomerID ) Коррелированные подзапросы Коррелированные подзапросы от обычных вложенных отличает то, что обмен информацией между коррелированными подзапросами и основными запросами осуществляется в обоих направлениях. Вложенные запросы обычно обрабатываются только один раз, затем информация возвращается во внешний запрос, который затем тоже выполняется один раз. В коррелированных подзапросах внутренний запрос выполняется на основе информации, переданной из внешнего запроса, и наоборот. Коррелированные запросы в параметре WHERE: Определить Номер заказа и дату заказа для первого заказа каждого из клиентов SELECT o1.CustomerID, o1.OrderID,o1.OrderDate FROM Orders o1 WHERE o1.OrderDate=(SELECT MIN(o2.OrderDate) FROM Orders o2 WHERE o2.CustomerID=o1.CustomerID) ORDER BY CustomerID Коррелированные запросы в списке полей оператора SELECT: Получить название компании и дату заказа, сделанного этой компанией в первый раз SELECT cu.CompanyName, (SELECT MIN(OrderDate) FROM Orders o WHERE o.CustomerID=cu.CustomerID) FROM Customers cu ^ 19) Операторы DML DML (Data Manipulation Language) - язык манипулирования данными, который используется для манипулирования информацией внутри объектов реляционной базы данных посредством трех основных команд: INSERT, UPDATE, DELETE. ^ Оператор вставки Оператор INSERT вставляет новые строки в таблицу. При этом значения столбцов могут представлять собой константы либо являться результатом выполнения подзапроса.  INSERT INTO <имя_таблицы> [(имя_столбца [,...n])]  {VALUES (значение[,...n]) | }  При вставке строки в таблицу проверяются все ограничения, наложенные на данную таблицу. Это могут быть ограничения первичного ключа или уникального индекса, проверочные ограничения типа CHECK, ограничения ссылочной целостности. В случае нарушения какого-либо ограничения вставка строки будет отвергнута. Первая форма оператора INSERT с параметром VALUES предназначена для вставки единственной строки в указанную таблицу.  Список столбцов указывает столбцы, которым будут присвоены значения в добавляемых записях.  Список может быть опущен, тогда подразумеваются все столбцы таблицы (кроме автоинкрементных), причем в определенном порядке, установленном при создании таблицы.  Если в операторе INSERT указывается конкретный список имен полей, то любые пропущенные в нем столбцы должны быть объявлены при создании таблицы как допускающие значение NULL, за исключением тех случаев, когда при описании столбца использовался параметр DEFAULT.  Список значений должен следующим образом соответствовать списку столбцов: • количество элементов в обоих списках должно быть одинаковым;  • должно существовать прямое соответствие между позицией одного и то же элемента в обоих списках, поэтому первый элемент списка значений должен относиться к первому столбцу в списке столбцов, второй – ко второму столбцу и т.д.  • типы данных элементов в списке значений должны быть совместимы с типами данных  Преодолеть ограничение на вставку одной строки в операторе INSERT при использовании VALUES позволяет искусственный прием использования подзапроса, формирующего строку с предложением ^ UNION ALL. Так если нам требуется вставить несколько строк при помощи одного оператора INSERT, можно написать: INSERT INTO Products    SELECT ‘Стул’, 1200    UNION ALL     SELECT ‘Стол', 3000    UNION ALL     SELECT ‘Шкаф', 5000 Вторая форма оператора INSERT с параметром SELECT позволяет скопировать множество строк из одной таблицы в другую.  Предложение SELECT может представлять собой любой допустимый оператор SELECT. Вставляемые в указанную таблицу строки в точности должны соответствовать строкам результирующей таблицы, созданной при выполнении вложенного запроса.  Все ограничения, указанные выше для первой формы оператора SELECT, применимы и в этом случае. Поскольку оператор SELECT в общем случае возвращает множество записей, то оператор INSERT в такой форме приводит к добавлению в таблицу аналогичного числа новых записей. ^ Оператор удаления Оператор DELETE предназначен для удаления группы записей из таблицы. DELETE FROM <имя_таблицы>[WHERE <условие_отбора>]  Здесь параметр имя_таблицы представляет собой либо имя таблицы базы данных. Если предложение WHERE присутствует, удаляются записи из таблицы, удовлетворяющие условию отбора. Если опустить предложение WHERE, из таблицы будут удалены все записи, однако сама таблица сохранится.  Для удаления всех записей из таблицы также может использоваться оператор TRUNCATE TABLE <имя_таблицы> ^ Оператор обновления Оператор UPDATE применяется для изменения значений в группе записей или в одной записи указанной таблицы. UPDATE имя_таблицы  SET имя_столбца=<выражение>[,...n]  [WHERE <условие_отбора>]  Параметр имя_таблицы – это либо имя таблицы базы данных. В предложении SET указываются имена одного и более столбцов, данные в которых необходимо изменить.  Предложение WHERE является необязательным. Если оно опущено, значения указанных столбцов будут изменены во всех строках таблицы. Если предложение WHERE присутствует, то обновлены будут только те строки, которые удовлетворяют условию отбора. Выражение представляет собой новое значение соответствующего столбца и должно быть совместимо с ним по типу данных. ^ 20) Операторы DDL  DDL (Data Definition Language, DDL) - язык определения данных, который позволяет создавать и изменять структуру объектов базы данных. Создание базы данных  Процесс создания базы данных в системе SQL-сервера состоит из двух этапов:  • сначала организуется сама база данных,  • а затем принадлежащий ей журнал транзакций.  Информация размещается в соответствующих файлах, имеющих расширения *.mdf (для базы данных) и *.ldf. (для журнала транзакций). В файле базы данных записываются сведения об основных объектах (таблицах, индексах, просмотрах и т.д.), а в файле журнала транзакций – о процессе работы с транзакциями (контроль целостности данных, состояния базы данных до и после выполнения транзакций). Создание базы данных в системе SQL-сервер осуществляется командой ^ CREATE DATABASE CREATE DATABASE имя_базы_данных  [ON [PRIMARY] [ <определение_файла> [,...n] ] [,<определение_группы> [,...n] ] ]  [ LOG ON {<определение_файла>[,...n] } ]  [ FOR LOAD | FOR ATTACH ]  При выборе имени базы данных следует руководствоваться общими правилами именования объектов. Если имя базы данных содержит пробелы или любые другие недопустимые символы, оно заключается в ограничители (двойные кавычки или квадратные скобки). Имя базы данных должно быть уникальным в пределах сервера и не может превышать 128 символов. Параметр ^ ON определяет список файлов на диске для размещения информации, хранящейся в базе данных. Параметр PRIMARY определяет первичный файл. Если он опущен, то первичным является первый файл в списке. Параметр LOG ON определяет список файлов на диске для размещения журнала транзакций. Имя файла для журнала транзакций генерируется на основе имени базы данных, и в конце к нему добавляются символы _log. При создании базы данных можно определить набор файлов, из которых она будет состоять. Файл определяется с помощью следующей конструкции: <определение_файла>::= ( [ NAME=логическое_имя_файла,]  FILENAME='физическое_имя_файла'  [,SIZE=размер_файла ]  [,MAXSIZE={max_размер_файла |UNLIMITED } ]  [, FILEGROWTH=величина_прироста ] )[,...n]  Здесь логическое имя файла – это имя файла, под которым он будет опознаваться при выполнении различных SQL-команд.  Физическое имя файла предназначено для указания полного пути и названия соответствующего физического файла, который будет создан на жестком диске. Это имя останется за файлом на уровне операционной системы.  Параметр SIZE определяет первоначальный размер файла; минимальный размер параметра – 512 Кб, если он не указан, по умолчанию принимается 1 Мб. Параметр MAXSIZE определяет максимальный размер файла базы данных. При значении параметра UNLIMITED максимальный размер базы данных ограничивается свободным местом на диске. При создании базы данных можно разрешить или запретить автоматический рост ее размера (это определяется параметром FILEGROWTH) и указать приращение с помощью абсолютной величины в Мб или процентным соотношением. Дополнительные файлы могут быть включены в группу: <определение_группы>::=FILEGROUP имя_группы_файлов <определение_файла>[,...n]  ^ Изменение базы данных Большинство действий по изменению конфигурации базы данных выполняется с помощью следующей конструкции: ALTER DATABASE имя_базы_данных  { ADD FILE <определение_файла>[,...n] [TO FILEGROUP имя_группы_файлов ]  | ADD LOG FILE <определение_файла>[,...n]  | REMOVE FILE логическое_имя_файла  | ADD FILEGROUP имя_группы_файлов  | REMOVE FILEGROUP имя_группы_файлов  | MODIFY FILE <определение_файла>  | MODIFY FILEGROUP имя_группы_файлов <свойства_группы_файлов>}  Как видно из синтаксиса, за один вызов команды может быть изменено не более одного параметра конфигурации базы данных. Если необходимо выполнить несколько изменений, придется разбить процесс на ряд отдельных шагов. В базу данных можно добавить (ADD) новые файлы данных (в указанную группу файлов или в группу, принятую по умолчанию) или файлы журнала транзакций. Параметры файлов и групп файлов можно изменять (MODIFY). Для удаления из базы данных файлов или групп файлов используется параметр REMOVE. Однако удаление файла возможно лишь при условии его освобождения от данных. В противном случае сервер не разрешит удаление. В качестве свойств группы файлов используются следующие: READONLY – группа файлов используется только для чтения; READWRITE – в группе файлов разрешаются изменения; DEFAULT – указанная группа файлов принимается по умолчанию. Удаление базы данных Удаление базы данных осуществляется командой: DROP DATABASE имя_базы_данных [,...n] Удаляются все содержащиеся в базе данных объекты, а также файлы, в которых она размещается.  ^ 21) Операторы DDL (определение структуры таблицы) DDL (Data Definition Language, DDL) - язык определения данных, который позволяет создавать и изменять структуру объектов базы данных. ^ Создание таблицы Таблица – основной объект для хранения информации в реляционной базе данных. Она состоит из содержащих данные строк и столбцов, занимает в базе данных физическое пространство и может быть постоянной или временной.  Поле, также называемое в реляционной базе данных столбцом, является частью таблицы, за которой закреплен определенный тип данных. Каждая таблица базы данных должна содержать хотя бы один столбец.  Строка данных – это запись в таблице базы данных, она включает поля, содержащие данные из одной записи таблицы. ^ CREATE TABLE      [ имя_базы_данных.[ владелец ] . | владелец. ] имя_таблицы     ( { < определение_столбца >          | название_столбца AS выражение_для вычисляемого_столбца          | < табличное_ограничение > ::= [ CONSTRAINT имя_ограничения ] }         | [ { PRIMARY KEY | UNIQUE } [ ,...n ]      )  [ ON { файловая_группа | DEFAULT } ]  < определение_столбца > ::= { название_столбца тип_данных }      [ [ DEFAULT выражение_для_значения_по_умолчанию ]      | [ IDENTITY [ ( первоначальное_значение , инкремент )] ]     [ < ограничение_для_столбца > ] [ ...n ]  < ограничение_для_столбца > ::= [ CONSTRAINT имя_ограничения]      { [ NULL | NOT NULL ]       | [ { PRIMARY KEY | UNIQUE }  [ CLUSTERED | NONCLUSTERED ]                [ON {filegroup | DEFAULT} ] ]       | [ [ FOREIGN KEY ]  REFERENCES имя_родительской_таьлицы [ ( назв_столбца ) ]              [ ON DELETE { CASCADE | NO ACTION } ]              [ ON UPDATE { CASCADE | NO ACTION } ] ]       | CHECK     ( логическое_выражение )      }  < табличное_ограничение > ::= [ CONSTRAINT имя_ограничения ]      { [ { PRIMARY KEY | UNIQUE } [ CLUSTERED | NONCLUSTERED ]          { ( имя_столбца [ ASC | DESC ] [ ,...n ] ) }          [ ON {файловая_группа | DEFAULT } ] ]       | FOREIGN KEY          [ (имя_столбца [ ,...n ] ) ]          REFERENCES имя_родительской_таьлицы [ ( назв_столбца [ ,...n ] ) ]          [ ON DELETE { CASCADE | NO ACTION } ]          [ ON UPDATE { CASCADE | NO ACTION } ]          [ NOT FOR REPLICATION ]       | CHECK  ( условие_проверки )      }  Изменение таблицы ALTER TABLE имя_таблицы  {[ALTER COLUMN имя_столбца  {новый_тип_данных [(точность[,масштаб])] [ NULL | NOT NULL ]}]  | ADD { [имя_столбца тип_данных]  | имя_столбца AS выражение } [,...n]  | DROP {COLUMN имя_столбца}[,...n] }  Команда позволяет добавлять и удалять столбцы, изменять их определения. При изменении определений столбцов следует принимать во внимание некоторые общепринятые правила: • размер столбца может быть увеличен до максимального значения, допускаемого соответствующим типом данных;  • размер столбца может быть уменьшен только в том случае, если содержащееся в нем наибольшее значение не будет превосходить его нового размера;  • количество разрядов числового типа данных всегда может быть увеличено;  • количество разрядов числового типа данных может быть уменьшено только в том случае, если количество разрядов наибольшего значения в соответствующем столбце не будет превосходить нового числа разрядов, определенного для этого столбца;  • количество десятичных знаков числового типа данных может быть уменьшено или увеличено;  • тип данных столбца, как правило, может быть изменен. ^ Удаление таблицы DROP TABLE имя_таблицы [RESTRICT | CASCADE]  Следует отметить, что эта команда удалит не только указанную таблицу, но и все входящие в нее строки данных.  Если в операторе указано ключевое слово RESTRICT, то при наличии в базе данных хотя бы одного объекта, существование которого зависит от удаляемой таблицы, выполнение оператора DROP TABLE будет отменено.  Если указано ключевое слово CASCADE, автоматически удаляются и все прочие объекты базы данных, чье существование зависит от удаляемой таблицы, а также другие объекты, зависящие от удаляемых объектов.  Чаще всего оператор DROP TABLE используется для исправления ошибок, допущенных при создании таблицы.  ^ 22) Индексы в среде MS SQL Server Индекс представляет собой средство, помогающее ускорить поиск необходимых данных за счет физического или логического их упорядочивания.  Индекс представляет собой набор ссылок, упорядоченных по определенному столбцу таблицы, который в данном случае будет называться индексированным столбцом.  Индексы это наборы уникальных значений для некоторой таблицы с соответствующими ссылками на данные.  Расположенные в самой таблице, они являются удобным внутренним механизмом системы SQL-сервера, с помощью которого осуществляется доступ к данным наиболее оптимальным способом. В среде SQL Server реализованы эффективные алгоритмы поиска нужного значения в строго определенной последовательности данных.  ^ Когда нужно создавать индексы  Если выборка данных из таблицы требует значительного времени, это означает, что для нее необходимо создать индекс. Индексы могут существенно повысить производительность выполнения операций поиска и выборки данных.  При выборе столбца для индекса следует проанализировать, какие типы запросов чаще всего выполняются пользователями и какие столбцы являются ключевыми, т.е. задающими критерии выборки данных, например, порядок сортировки. ^ Типы индексов • Кластерные индексы  При определении такого индекса в таблице физическое расположение данных перестраивается в соответствии со структурой индекса.  • ^ Некластерные индексы  – наиболее типичные представители семейства индексов. В отличие от кластерных, они не перестраивают физическую структуру таблицы, а лишь организуют ссылки на соответствующие строки.  ^ Кластерные индексы Кластерные индексы могут дать существенное увеличение производительности поиска данных даже по сравнению с обычными индексами.  При определении такого индекса в таблице физическое расположение данных перестраивается в соответствии со структурой индекса.  В таблице может быть определен только один кластерный индекс. В качестве такового следует выбирать наиболее часто используемые столбцы. При этом стоит следовать общим рекомендациям создания индексов и не индексировать слишком длинные столбцы. Кластерный индекс может включать несколько столбцов. Однако количество таких столбцов рекомендуется по возможности свести к минимуму. Необходимо избегать создания кластерного индекса для часто изменяемых столбцов, поскольку сервер должен будет выполнять физическое перемещение всех данных в таблице, чтобы они находились в упорядоченном состоянии, как того требует кластерный индекс.  Для интенсивно изменяемых столбцов лучше подходит некластерный индекс. При создании в таблице первичного ключа (PRIMARY KEY) сервер автоматически создает для него кластерный индекс, если его не существовало ранее или если при определении ключа не был явно указан другой тип индекса. Когда же в таблице определен еще и некластерный индекс, то его указатель ссылается не на физическое положение строки в базе данных, а на соответствующий элемент кластерного индекса, описывающего эту строку, что позволяет не перестраивать структуру некластерных индексов всякий раз, когда кластерный индекс меняет физический порядок строк в таблице. ^ Некластерные индексы Для идентификации нужной строки в таблице некластерный индекс организует специальные указатели, включающие в себя: •информацию об идентификационном номере файла, в котором хранится строка;  •идентификационный номер страницы соответствующих данных;  •номер искомой строки на соответствующей странице;  •содержимое столбца. В большинстве случаев следует ограничиваться 4-5 индексами. ^ Создание индекса Индекс создается в случаях: •автоматическое создание индекса при создании первичного ключа;  •автоматическое создание индекса при определении ограничения целостности UNIQUE;  •создание индекса с помощью команды CREATE INDEX. ^ CREATE [ UNIQUE ] [ CLUSTERED | NONCLUSTERED ] INDEX имя_индекса ON имя_таблицы(имя_столбца [ASC|DESC][,...n]) [[,] DROP_EXISTING] [ON имя_группы_файлов ] Параметр UNIQUE используется при необходимости ввода в определенное поле только уникальных значений. При указании этого ключевого слова будет создан уникальный индекс. В индексируемом столбце желательно запретить хранение значений NULL, чтобы избежать проблем, связанных с уникальностью значений. Параметр DROP_EXISTING при использовании кластерного индекса определяет его повторное создание, что позволяет предотвратить нежелательное обновление кластерных индексов. Параметр STATISTICS_NORECOMPUTE определяет функции автоматического обновления статистики для таблицы. Параметр имя_группы_файлов позволяет осуществить выбор файловой группы, в которой будет находиться создаваемый индекс.  Использование индекса из другой файловой группы повышает производительность некластерных индексов в связи с параллельностью выполнения процессов ввода/вывода и работы с самим индексом. ^ Удаление индекса DROP INDEX 'имя_индекса'[,...n] 23) Представления Представления, или просмотры (VIEW), представляют собой временные, производные (иначе - виртуальные) таблицы и являются объектами базы данных, информация в которых не хранится постоянно, как в базовых таблицах, а формируется динамически при обращении к ним.  Обычные таблицы относятся к базовым, т.е. содержащим данные и постоянно находящимся на устройстве хранения информации.  Представление не может существовать само по себе, а определяется только в терминах одной или нескольких таблиц.  Представление - это предопределенный запрос, хранящийся в базе данных, который выглядит подобно обычной таблице и не требует для своего хранения дисковой памяти.  Для хранения представления используется только оперативная память.  В отличие от других объектов базы данных представление не занимает дисковой памяти за исключением памяти, необходимой для хранения определения самого представления.  Создание представлений (просмотров) <определение_просмотра> ::= { CREATE| ALTER} VIEW имя_просмотра [(имя_столбца [,...n])] ^ [WITH ENCRYPTION] AS SELECT_оператор [WITH CHECK OPTION] Параметры оператора CREATE • По умолчанию имена столбцов в представлении соответствуют именам столбцов в исходных таблицах. Явное указание имени столбца требуется для вычисляемых столбцов или при объединении нескольких таблиц, имеющих столбцы с одинаковыми именами. Имена столбцов перечисляются через запятую, в соответствии с порядком их следования в представлении. • Параметр ^ WITH ENCRYPTION предписывает серверу шифровать SQL-код запроса, что гарантирует невозможность его несанкционированного просмотра и использования. Если при определении представления необходимо скрыть имена исходных таблиц и столбцов, а также алгоритм объединения данных, необходимо применить этот аргумент. • Параметр ^ WITH CHECK OPTION предписывает серверу исполнять проверку изменений, производимых через представление, на соответствие критериям, определенным в операторе SELECT.  Это означает, что не допускается выполнение изменений, которые приведут к исчезновению строки из представления.  Такое случается, если для представления установлен горизонтальный фильтр и изменение данных приводит к несоответствию строки установленным фильтрам.  Использование аргумента WITH CHECK OPTION гарантирует, что сделанные изменения будут отображены в представлении. Если пользователь пытается выполнить изменения, приводящие к исключению строки из представления, при заданном аргументе WITH CHECK OPTION сервер выдаст сообщение об ошибке и все изменения будут отклонены. ^ Использование представлений Обращение к представлению осуществляется с помощью оператора SELECT как к обычной таблице. Представление можно использовать в команде так же, как и любую другую таблицу.  К представлению можно строить запрос, модифицировать его (если оно отвечает определенным требованиям), соединять с другими таблицами.  Содержание представления не фиксировано и обновляется каждый раз, когда на него ссылаются в команде. Представления значительно расширяют возможности управления данными. В частности, это прекрасный способ разрешить доступ к информации в таблице, скрыв часть данных. ^ Модифицируемые представления •основывается только на одной базовой таблице;  •содержит первичный ключ этой таблицы;  •не содержит DISTINCT в своем определении;  •не использует GROUP BY или HAVING в своем определении;  •по возможности не применяет в своем определении подзапросы;  •не использует константы или выражения значений среди выбранных полей вывода;  •в просмотр должен быть включен каждый столбец таблицы, имеющий атрибут NOT NULL;  •оператор SELECT просмотра не использует агрегирующие (итоговые) функции, соединения таблиц, хранимые процедуры и функции, определенные пользователем;  •основывается на одиночном запросе, поэтому объединение UNION не разрешено.  ^ Если просмотр удовлетворяет этим условиям, к нему могут применяться операторы INSERT, UPDATE, DELETE.  Преимущества и недостатки представлений Механизм представления - мощное средство СУБД, позволяющее скрыть реальную структуру БД от некоторых пользователей за счет определения представлений. Наличие представлений в БД необходимо для обеспечения логической независимости данных ( при изменении логической структуры данных не должно оказываться влияние на пользовательские программы). С увеличением количества данных, хранимых в БД, возникает необходимость ее расширения за счет добавления новых атрибутов или отношений - это называется ростом БД.  Реструктуризация данных подразумевает сохранение той же самой информации, но изменяется ее расположение, например, за счет перегруппировки атрибутов в отношениях.  Предположим, некоторое отношение в силу каких-либо причин необходимо разделить на два. Соединение полученных отношений в представлении воссоздает исходное отношение, а у пользователя складывается впечатление, что никакой реструктуризации не производилось. Помимо этого представление можно применять для просмотра одних и тех же данных разными пользователями и в различных вариантах.  С помощью представлений пользователь имеет возможность ограничить объем данных для удобства работы.  Наконец, механизм представлений позволяет скрыть служебные данные, не интересные пользователям. ^ Независимость от данных С помощью представлений можно создать согласованную, неизменную картину структуры базы данных, которая будет оставаться стабильной даже в случае изменения формата исходных таблиц. Актуальность Изменения данных в любой из таблиц базы данных, указанных в определяющем запросе, немедленно отображается на содержимом представления. ^ Повышение защищенности данных Права доступа к данным могут быть предоставлены исключительно через ограниченный набор представлений, содержащих только то подмножество данных, которое необходимо пользователю. Подобный подход позволяет существенно ужесточить контроль за доступом отдельных категорий пользователей к информации в базе данных. ^ Дополнительные удобства Создание представлений может обеспечивать пользователей дополнительными удобствами - например, возможностью работы только с действительно нужной частью данных. В результате можно добиться максимального упрощения той модели данных, которая понадобится каждому конечному пользователю. ^ Возможность настройки Представления являются удобным средством настройки индивидуального образа базы данных. В результате одни и те же таблицы могут быть предъявлены пользователям в совершенно разном виде. ^ Обеспечение целостности данных Если в операторе CREATE VIEW будет указана фраза WITH CHECK OPTION, то СУБД станет осуществлять контроль за тем, чтобы в исходные таблицы базы данных не была введена ни одна из строк, не удовлетворяющих предложению WHERE в определяющем запросе. Этот механизм гарантирует целостность данных в представлении. ^ Ограниченные возможности обновления В некоторых случаях представления не позволяют вносить изменения в содержащиеся в них данные. Структурные ограничения Структура представления устанавливается в момент его создания. Если впоследствии в исходную таблицу базы данных добавятся новые столбцы, то они не появятся в данном представлении до тех пор, пока это представление не будет удалено и вновь создано. ^ Снижение производительности Использование представлений связано с определенным снижением производительности. В одних случаях влияние этого фактора совершенно незначительно, тогда как в других оно может послужить источником существенных проблем. Например, представление, определенное с помощью сложного многотабличного запроса, может потребовать значительных затрат времени на обработку. ^ 24) Сценарии Сценарий – набор операторов SQL, сохраненный в файле. В общем случае сценарий пишется для решения от начала до конца какой-то определенной задачи.  Сценарий рассматривается как единое целое и выполняется целиком. В сценарии могут присутствовать системные функции, локальные переменные, операторы языка. ^ Объявление переменных  DECLARE @<имя_переменной> <тип_переменной> [,…]  После объявления переменной её значение будет равно null до тех пор, пока её не будет присвоенозначение. Для присвоения значений используются операторы SET и SELECT. SET используется в случае, если переменной присваивается известное на момент операции значение или же одной переменной присваевается значение другой. Select – когда переменной необходимо присвоить результат выполнения запроса. Print выводить текстовую информацию. ^ Системные функции Оператор select @<имя_переменной> позволяет вывести значение переменной. Системные функции. Существует около 30 сист. Ф. без параметров @@identity – возвращает последнее identity-значение, которое было вставлено в результате последнего оператора вставки. Оператор изменяется сразу же после очередного insert оператора, если этот оператор применяется к таблице, в которой нет identity столбца, тогда его значение null.  @@error –возвращает номер ошибки последнего оператора SQL, выполненного в текущем подключении. При отсутствии ошибки возвращает 0. @@rowcount – возвращает число строк, полученных в результате выполнения последнего оператора. Присваивается новое значение каждый раз, когда выполняется очередной оператор. Пакеты Пакет(batch) – это несколько, объединенных в одну логическую группу операторов t-sql. Все операторы в рамках пакета комбинируются в единый план исполнения т.о., что пока все операторы не будут успешно проанализированны синтаксическим образом, ни один из операторов пакета не будет исполняться. Однако, это не гарантирует того, что ошибки не возникнут во время выполнения программы. В случае возникновения ошибки, все операторы, выполненные до ошибки, останутся выполненными. Для разделения сценария на отдельные пакеты используется оператор GO.(должен находиться на отдельной строке, не является командой t-sql, его распознают только утилиты с командным интерфейсом SQL server). Каждый пакет обрабатывается отдельно, поэтому ошибка в одном пакете, не мешает выполнению другого пакета. Пакеты используются: Для задания предшествования Операторы, требующие создания отдельного пакета Create default, procedure, rule, trigger, view ^ Управляющие конструкции SQL Язык SQL является непроцедурным, но тем не менее в среде SQL Server предусмотрен ряд различных управляющих конструкций, без которых невозможно написание эффективных алгоритмов. Группировка двух и более команд в единый блок осуществляется с использованием ключевых слов BEGIN и END: <блок_операторов>::=BEGIN { sql_оператор | блок_операторов }END Сгруппированные команды воспринимаются интерпретатором SQL как одна команда. Подобная группировка требуется для конструкций поливариантных ветвлений, условных и циклических конструкций. Блоки BEGIN...END могут быть вложенными. Некоторые команды SQL не должны выполняться вместе с другими командами (речь идет о командах резервного копирования, изменения структуры таблиц, хранимых процедур и им подобных), поэтому их совместное включение в конструкцию BEGIN...END не допускается.  Нередко определенная часть программы должна выполняться только при реализации некоторого логического условия. Синтаксис условного оператора показан ниже: <условный_оператор>::=IF лог_выражение { sql_оператор | блок_операторов } [ ELSE {sql_оператор | блок_операторов } ] Циклы организуются с помощью следующей конструкции: <оператор_цикла>::=WHILE лог_выражение { sql_оператор | блок_операторов } [ BREAK ] { sql_оператор | блок_операторов } [ CONTINUE ] Цикл можно принудительно остановить, если в его теле выполнить команду BREAK. Если же нужно начать цикл заново, не дожидаясь выполнения всех команд в теле, необходимо выполнить команду CONTINUE.  Для замены множества одиночных или вложенных условных операторов используется следующая конструкция: <оператор_поливариантных_ветвлений>::=CASE входное_значение WHEN {значение_для_сравнения | лог_выражение } THEN вых_выражение [,...n] [ ELSE иначе_вых_значение ] END Если входное значение и значение для сравнения совпадают, то конструкция возвращает выходное значение. Если же значение входного параметра не найдено ни в одной из строк WHEN...THEN, то тогда будет возвращено значение, указанное после ключевого слова ELSE. ^ Динамический sql Sql server предоставляет возможность формировать sql-операторы на лету, манипулируя кодом в строке. Это используется тогда, когда мы не знаем каких-либо деталей до момента запуска запроса. Exec[ute] ({<строчная_переменная>|<константа_командной строки>}) Declare @TableName varchar(50)  Set @tablename=‘Customers’ Exec(‘Select * from’+@tablename) ^ 25) Хранимые процедуры Хранимые процедуры представляют собой группы связанных между собой операторов SQL, применение которых делает работу программиста более легкой и гибкой, поскольку выполнить хранимую процедуру часто оказывается гораздо проще, чем последовательность отдельных операторов SQL.  Хранимые процедуры представляют собой набор команд, состоящий из одного или нескольких операторов SQL или функций и сохраняемый в базе данных в откомпилированном виде.  Выполнение в базе данных хранимых процедур вместо отдельных операторов SQL дает пользователю следующие преимущества: - необходимые операторы уже содержатся в базе данных;  - все они прошли этап синтаксического анализа и находятся в исполняемом формате; перед выполнением хранимой процедуры SQL Server генерирует для нее план исполнения, выполняет ее оптимизацию и компиляцию;  - хранимые процедуры поддерживают модульное программирование, так как позволяют разбивать большие задачи на самостоятельные, более мелкие и удобные в управлении части;  - хранимые процедуры могут вызывать другие хранимые процедуры и функции;  - хранимые процедуры могут быть вызваны из прикладных программ других типов;  - как правило, хранимые процедуры выполняются быстрее, чем последовательность отдельных операторов;  - хранимые процедуры проще использовать: они могут состоять из десятков и сотен команд, но для их запуска достаточно указать всего лишь имя нужной хранимой процедуры. Это позволяет уменьшить размер запроса, посылаемого от клиента на сервер, а значит, и нагрузку на сеть.  - применение хранимых процедур упрощает сопровождение программных комплексов и внесение изменений в них. Обычно все ограничения целостности в виде правил и алгоритмов обработки данных реализуются на сервере баз данных и доступны конечному приложению в виде набора хранимых процедур, которые и представляют интерфейс обработки данных.  ^ Реализация в MS SQL Server 2000 При работе с SQL Server пользователи могут создавать собственные процедуры, реализующие те или иные действия.  Хранимые процедуры являются полноценными объектами базы данных, а потому каждая из них хранится в конкретной базе данных. Непосредственный вызов хранимой процедуры возможен, только если он осуществляется в контексте той базы данных, где находится процедура. ^ Типы хранимых процедур Системные хранимые процедуры предназначены для выполнения различных административных действий. Практически все действия по администрированию сервера выполняются с их помощью.  Можно сказать, что системные хранимые процедуры являются интерфейсом, обеспечивающим работу с системными таблицами, которая, в конечном счете, сводится к изменению, добавлению, удалению и выборке данных из системных таблиц как пользовательских, так и системных баз данных.  Системные хранимые процедуры имеют префикс sp_, хранятся в системной базе данных и могут быть вызваны в контексте любой другой базы данных.  Пользовательские хранимые процедуры реализуют те или иные действия. Хранимые процедуры – полноценный объект базы данных.  ^ Временные хранимые процедуры существуют лишь некоторое время, после чего автоматически уничтожаются сервером.  Они делятся на локальные и глобальные.  Локальные временные хранимые процедуры могут быть вызваны только из того соединения, в котором созданы (имя, начинающееся с одного символа #). Хранимые процедуры этого типа автоматически удаляются при отключении пользователя, перезапуске или остановке сервера.  Глобальные временные хранимые процедуры доступны для любых соединений сервера, на котором имеется такая же процедура. Для ее определения достаточно дать ей имя, начинающееся с символов ##. Удаляются эти процедуры при перезапуске или остановке сервера, а также при закрытии соединения, в контексте которого они были созданы.  Создание Создание хранимой процедуры предполагает решение следующих задач: - определение типа создаваемой хранимой процедуры: временная или пользовательская. Кроме этого, можно создать свою собственную системную хранимую процедуру, назначив ей имя с префиксом sp_ и поместив ее в системную базу данных.  - планирование прав доступа. При создании хранимой процедуры следует учитывать, что она будет иметь те же права доступа к объектам базы данных, что и создавший ее пользователь;  - определение параметров хранимой процедуры. Подобно процедурам, входящим в состав большинства языков программирования, хранимые процедуры могут обладать входными и выходными параметрами;  - разработка кода хранимой процедуры.  Код процедуры может содержать последовательность любых команд SQL, включая вызов других хранимых процедур.  {CREATE | ALTER } PROC[EDURE] имя_процедуры [;номер] [{@имя_параметра тип_данных } [=default] [OUTPUT] ][,...n] ^ [WITH { RECOMPILE | ENCRYPTION | RECOMPILE, ENCRYPTION }] AS sql_оператор [...n]  Используя префиксы sp_, #, ##, создаваемую процедуру можно определить в качестве системной или временной.  ^ Номер в имени – это идентификационный номер хранимой процедуры, однозначно определяющий ее в группе процедур. Для удобства управления процедурами логически однотипные хранимые процедуры можно группировать, присваивая им одинаковые имена, но разные идентификационные номера. Для передачи входных и выходных данных в создаваемой хранимой процедуре могут использоваться параметры, имена которых, как и имена локальных переменных, должны начинаться с символа @. В одной хранимой процедуре можно задать множество параметров, разделенных запятыми. В теле процедуры не должны применяться локальные переменные, чьи имена совпадают с именами параметров этой процедуры. Наличие ключевого слова OUTPUT означает, что соответствующий параметр предназначен для возвращения данных из хранимой процедуры. Однако это вовсе не означает, что параметр не подходит для передачи значений в хранимую процедуру. Указание ключевого слова OUTPUT предписывает серверу при выходе из хранимой процедуры присвоить текущее значение параметра локальной переменной, которая была указана при вызове процедуры в качестве значения параметра.  Ключевое слово DEFAULT представляет собой значение, которое будет принимать соответствующий параметр по умолчанию. Таким образом, при вызове процедуры можно не указывать явно значение соответствующего параметра. Так как сервер кэширует план исполнения запроса и компилированный код, при последующем вызове процедуры будут использоваться уже готовые значения. Однако в некоторых случаях все же требуется выполнять перекомпиляцию кода процедуры. Указание ключевого слова RECOMPILEпредписывает системе создавать план выполнения хранимой процедуры при каждом ее вызове. Ключевое слово ENCRYPTION предписывает серверу выполнить шифрование кода хранимой процедуры. Ключевое слово AS размещается в начале собственно тела хранимой процедуры, т.е. набора команд SQL, с помощью которых и будет реализовываться то или иное действие. В теле процедуры могут применяться практически все команды SQL и вызываться другие хранимые процедуры. Выход из хранимой процедуры можно осуществить посредством команды RETURN. Удаление Удаление хранимой процедуры осуществляется командой: DROP PROCEDURE {имя_процедуры} [,...n]  Выполнение [[ EXEC [ UTE] имя_процедуры [;номер][[@имя_параметра=]{значение | @имя_переменной} [OUTPUT ]|[DEFAULT ]][,...n]  Если вызов хранимой процедуры не является единственной командой в пакете, то присутствие команды EXECUTE обязательно. Более того, эта команда требуется для вызова процедуры из тела другой процедуры или триггера. Использование ключевого слова OUTPUT при вызове процедуры разрешается только для параметров, которые были объявлены при создании процедуры с ключевым словом OUTPUT. Когда же при вызове процедуры для параметра указывается ключевое слово DEFAULT, то будет использовано значение по умолчанию. Естественно, указанное слово DEFAULT разрешается только для тех параметров, для которых определено значение по умолчанию. Из синтаксиса команды EXECUTE видно, что имена параметров могут быть опущены при вызове процедуры. Однако в этом случае пользователь должен указывать значения для параметров в том же порядке, в каком они перечислялись при создании процедуры.  Присвоить параметру значение по умолчанию, просто пропустив его при перечислении нельзя. Если же требуется опустить параметры, для которых определено значение по умолчанию, достаточно явного указания имен параметров при вызове хранимой процедуры. Более того, таким способом можно перечислять параметры и их значения в произвольном порядке. ^ 26) Понятие функции  При реализации на языке SQL сложных алгоритмов, которые могут потребоваться более одного раза, сразу встает вопрос о сохранении разработанного кода для дальнейшего применения.  Эту задачу можно было бы реализовать с помощью хранимых процедур, однако их архитектура не позволяет использовать процедуры непосредственно в выражениях, т.к. они требуют промежуточного присвоения возвращенного значения переменной, которая затем и указывается в выражении.  Пользовательские функции сходны с хранимыми процедурами, но, в отличие от них, могут применяться в запросах так же, как и системные встроенные функции.  ^ Классы функции  Scalar – функции возвращают обычное скалярное значение, каждая может включать множество команд, объединяемых в один блок с помощью конструкции BEGIN...END;  Inline – функции содержат всего одну команду SELECT и возвращают пользователю набор данных в виде значения типа данных TABLE;  Multi-statement – функции также возвращают пользователю значение типа данных TABLE, содержащее набор данных, однако в теле функции находится множество команд SQL (INSERT, UPDATE и т.д.). Именно с их помощью и формируется набор данных, который должен быть возвращен после выполнения функции. Функции Scalar {CREATE | ALTER } FUNCTION [владелец.] имя_функции ( [ { @имя_параметра скаляр_тип_данных [=default]}[,...n]]) RETURNS скаляр_тип_данных ^ [WITH ENCRIPTION ] [AS] BEGIN<тело_функции> RETURN скаляр_выражение END  Пример CREATE FUNCTION dbo.KolData (@data DATETIME) RETURNS INT AS BEGIN DECLARE @c INT SET @c=(SELECT SUM(Quantity*Price) FROM Orders O INNER JOIN [Order Details] OD ON O.OrderID=OD.OrderID WHERE OrderDate=@data) RETURN (@c) END DECLARE @kol INT SET @kol= dbo.KolData ('02.11.01') SELECT @kol  SELECT DISTINCT OrderDate, dbo.KolData(OrderDate) FROM Orders Функции Inline {CREATE | ALTER } FUNCTION [владелец.] имя_функции ( [ { @имя_параметра скаляр_тип_данных [=default]}[,...n]]) ^ RETURNS TABLE [ WITH ENCRIPTION] [AS] RETURN [(] SELECT_оператор [)]  Особенность функции данного типа заключается в том, что структура значения TABLE создается автоматически в ходе выполнения запроса, а не указывается явно при определении типа после ключевого слова RETURNS.  Возвращаемое функцией значение типа TABLE может быть использовано непосредственно в запросе, т.е. в разделе FROM. ^ Функции Multi-statement {CREATE | ALTER }FUNCTION [владелец.] имя_функции ( [ { @имя_параметра скаляр_тип_данных [=default]}[,...n]]) RETURNS @имя_параметра TABLE <определение_таблицы> ^ [WITH ENCRIPTION] [AS] BEGIN <тело_функции> RETURN END  В отличие от табличных функций, при создании функций Multi-statement необходимо явно задать структуру возвращаемого значения. Она указывается непосредственно после ключевого слова TABLE и, таким образом, является частью определения возвращаемого типа данных. Синтаксис конструкции <определение_таблицы> полностью соответствует одноименным структурам, используемым при создании обычных таблиц с помощью команды CREATE TABLE. Набор возвращаемых данных должен формироваться с помощью команд INSERT, выполняемых в теле функции. Кроме того, в теле функции допускается использование различных конструкций языка SQL, которые могут контролировать значения, размещаемые в выходном наборе строк.  При работе с командой INSERT требуется явно указать имя того объекта, куда необходимо вставить строки. Поэтому в функциях типа Multi-statement, в отличие от табличных, необходимо присвоить какое-то имя объекту с типом данных TABLE – оно и указывается как возвращаемое значение.  ^ 27) Триггеры Триггер – это откомпилированная SQL-процедура, исполнение которой обусловлено наступлением определенных событий внутри реляционной базы данных.  Применение триггеров большей частью весьма удобно для пользователей базы данных. И все же их использование часто связано с дополнительными затратами ресурсов на операции ввода/вывода. В том случае, когда тех же результатов (с гораздо меньшими непроизводительными затратами ресурсов) можно добиться с помощью хранимых процедур или прикладных программ, применение триггеров нецелесообразно. Триггеры – особый инструмент SQL-сервера, используемый для поддержания целостности данных в базе данных. С помощью ограничений и значений по умолчанию не всегда можно добиться нужного уровня функциональности. Часто требуется реализовать сложные алгоритмы проверки данных, гарантирующие их достоверность и реальность. Кроме того, иногда необходимо отслеживать изменения значений таблицы, чтобы нужным образом изменить связанные данные.  Триггеры можно рассматривать как своего рода фильтры, вступающие в действие после выполнения всех операций в соответствии с ограничениями, стандартными значениями и т.д. Триггер представляет собой весьма полезное и в то же время опасное средство. Так, при неправильной логике его работы можно легко уничтожить целую базу данных, поэтому триггеры необходимо очень тщательно отлаживать. В отличие от обычной подпрограммы, триггер выполняется неявно в каждом случае возникновения триггерного события, к тому же он не имеет аргументов.  Приведение его в действие иногда называют запуском триггера.  С помощью триггеров достигаются следующие цели: - проверка корректности введенных данных и выполнение сложных ограничений целостности данных, которые трудно, если вообще возможно, поддерживать с помощью ограничений целостности, установленных для таблицы;  - выдача предупреждений, напоминающих о необходимости выполнения некоторых действий при обновлении таблицы, реализованном определенным образом;  - накопление аудиторской информации посредством фиксации сведений о внесенных изменениях и тех лицах, которые их выполнили;  Создание триггера {CREATE | ALTER} TRIGGER имя_триггера ON  {имя_таблицы | имя_просмотра } ^ [WITH ENCRYPTION ] { { FOR | AFTER | INSTEAD OF } { [ DELETE] [,] [ INSERT] [,] [ UPDATE] } [ WITH APPEND ]  AS sql_оператор[...n]} Триггер может быть создан только в текущей базе данных, но допускается обращение внутри триггера к другим базам данных, в том числе и расположенным на удаленном сервере. ^ Типы триггеров В SQL Server существует два параметра, определяющих поведение триггеров: - AFTER. Триггер выполняется после успешного выполнения вызвавших его команд. Если же команды по какой-либо причине не могут быть успешно завершены, триггер не выполняется. Следует отметить, что изменения данных в результате выполнения запроса пользователя и выполнение триггера осуществляется в теле одной транзакции: если произойдет откат триггера, то будут отклонены и пользовательские изменения. По умолчанию в SQL Server все триггеры являются AFTER-триггерами.  - INSTEAD OF. Триггер вызывается вместо выполнения команд. В отличие от AFTER-триггера INSTEAD OF-триггер может быть определен как для таблицы, так и для просмотра. Для каждой операции INSERT, UPDATE, DELETE можно определить только один INSTEAD OF-триггер.  Существует три типа триггеров: - INSERT TRIGGER – запускаются при попытке вставки данных с помощью команды INSERT.  - UPDATE TRIGGER – запускаются при попытке изменения данных с помощью команды UPDATE.  - DELETE TRIGGER – запускаются при попытке удаления данных с помощью команды DELETE.  Конструкции [ DELETE] [,] [ INSERT] [,] [ UPDATE] и FOR | AFTER | INSTEAD OF } { [INSERT] [,] [UPDATE] определяют, на какую команду будет реагировать триггер. При его создании должна быть указана хотя бы одна команда. Допускается создание триггера, реагирующего на две или на все три команды. Аргумент ^ WITH APPEND позволяет создавать несколько триггеров каждого типа. Конструкция AS sql_оператор[...n] определяет набор SQL- операторов и команд, которые будут выполнены при запуске триггера. Внутри триггера не допускается выполнение ряда операций, таких, например, как: - создание, изменение и удаление базы данных;  - восстановление резервной копии базы данных или журнала транзакций.  Аргумент ^ WITH APPEND позволяет создавать несколько триггеров каждого типа. Конструкция AS sql_оператор[...n] определяет набор SQL- операторов и команд, которые будут выполнены при запуске триггера. Внутри триггера не допускается выполнение ряда операций, таких, например, как: - создание, изменение и удаление базы данных;  - восстановление резервной копии базы данных или журнала транзакций.  ^ Программирование триггеров При выполнении команд добавления, изменения и удаления записей сервер создает две специальные таблицы: inserted и deleted. В них содержатся списки строк, которые будут вставлены или удалены по завершении транзакции. Структура таблиц inserted и deleted идентична структуре таблиц, для которой определяется триггер. Для каждого триггера создается свой комплект таблиц inserted и deleted, поэтому никакой другой триггер не сможет получить к ним доступ.  В зависимости от типа операции, вызвавшей выполнение триггера, содержимое таблиц inserted и deleted может быть разным: - команда INSERT – в таблице inserted содержатся все строки, которые пользователь пытается вставить в таблицу; в таблице deleted не будет ни одной строки; после завершения триггера все строки из таблицы inserted переместятся в исходную таблицу; - команда DELETE – в таблице deleted будут содержаться все строки, которые пользователь попытается удалить; триггер может проверить каждую строку и определить, разрешено ли ее удаление; в таблице inserted не окажется ни одной строки;  - команда UPDATE – при ее выполнении в таблице deleted находятся старые значения строк, которые будут удалены при успешном завершении триггера. Новые значения строк содержатся в таблице inserted. Эти строки добавятся в исходную таблицу после успешного выполнения триггера.  Для получения информации о количестве строк, которое будет изменено при успешном завершении триггера, можно использовать функцию @@ROWCOUNT; она возвращает количество строк, обработанных последней командой.  Следует подчеркнуть, что триггер запускается не при попытке изменить конкретную строку, а в момент выполнения команды изменения. Одна такая команда воздействует на множество строк, поэтому триггер должен обрабатывать все эти строки. Для получения списка столбцов, измененных при выполнении команд INSERT или UPDATE, вызвавших выполнение триггера, можно использовать функцию COLUMNS_UPDATED().  Для удаления триггера используется команда DROP TRIGGER {имя_триггера} [,...n]  ^ 28) Курсоры Запрос к реляционной базе данных обычно возвращает несколько записей данных, но приложение за один раз обрабатывает лишь одну запись. Даже если оно имеет дело одновременно с несколькими рядами (например, выводит данные в форме электронных таблиц), их количество по-прежнему ограниченно. Кроме того, при модификации, удалении или добавлении данных рабочей единицей является запись.  Курсор в SQL – это область в памяти базы данных, которая предназначена для хранения последнего оператора SQL. Если текущий оператор – запрос к базе данных, в памяти сохраняется и строка данных запроса, называемая текущим значением, или текущей строкой курсора. Указанная область в памяти поименована и доступна для прикладных программ.  Обычно курсоры используются для выбора из базы данных некоторого подмножества хранимой в ней информации. В каждый момент времени прикладной программой может быть проверена одна строка курсора. Курсоры часто применяются в операторах SQL, встроенных в написанные на языках процедурного типа прикладные программы. Некоторые из них неявно создаются сервером базы данных, в то время как другие определяются программистами. В соответствии со стандартом SQL при работе с курсорами можно выделить следующие основные действия: ^ Действия над курсорами - создание или объявление курсора;  - открытие курсора, т.е. наполнение его данными, которые сохраняются в многоуровневой памяти;  - выборка из курсора и изменение с его помощью строк данных;  - закрытие курсора, после чего он становится недоступным для пользовательских программ;  - освобождение курсора, т.е. удаление курсора как объекта, поскольку его закрытие необязательно освобождает ассоциированную с ним память.