Базы данных на больших эвм

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

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

Характерные черты этого периода:

• СУБД базируются на мощных мультипрограммных ОС (в основном поддерживается работа с централизованной БД в режиме распределенного доступа).

• Функции управления распределением ресурсов в основном осуществляются операционной системой.

• Поддерживаются языки низкого уровня манипулирования данными.

• Значительная роль отводится администрированию данных.

• Проводятся серьезные работы по обоснованию и формализации реляционной модели данных (была создана первая система System R с идеологией реляционной модели данных).

• Проводятся теоретические работы по оптимизации запросов и управлению распределенным доступом к централизованной БД, было введено понятие транзакции.

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

Эпоха персональных компьютеров

Персональные компьютеры (ПК) перевернули наше представление о роли и месте вычислительной техники в жизни общества.

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

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

Особенности этого периода:

• СУБД рассчитаны на создание БД в основном с монопольным доступом. Лишь иногда предполагалась последовательная работа нескольких пользователей (бухгалтер-главбух).

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

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

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

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

• Наличие монопольного режима работы фактически привело к вырождению функций администрирования БД и к отсутствию инструментальных средств администрирования БД.

• Относительно скромные требования к аппаратному обеспечению со стороны настольных СУБД. Вполне приличные приложения иногда могли работать даже на РС-286 (например, на Clipper).

12. Зеркалирование и кластеризация баз данных.

Зеркалирование баз данных — одна из наиболее ожидаемых функций SQL Server 2005. В двух словах, она позволяет иметь на другом сервере актуальную копию вашей рабочей БД. При сбое все будет выглядеть так, словно БД с отказавшего сервера была восстановлена на другом и готова обслуживать подключения. В некоторых сценариях зеркалирование можно настроить таким образом, чтобы автоматическое переключение на копию БД занимало меньше трех секунд. Сервер с копией БД не обязательно должен находиться поблизости от оригинала в географическом смысле; это, конечно, способствует повышению производительно­сти, но в данном случае все зависит от особенностей среды и ваших нужд. Еще одним плюсом этой технологии является отсутствие особого списка совместимого оборудования (Hardware Compatibility List, HCL), которому должно отвечать аппаратное обеспечение сервера, чтобы пользоваться новой функционально­стью. Минимальные требование к оборудованию те же, что и для SQL Server 2005. При зеркалировании можно даже смешивать 32­ и 64­разрядные компьютеры. В отличие от кластеризации, эта функция работает на уровне БД, а не системы в целом. Выбирая серверы, помните, что если база была восстановлена на сервере с более скромными характеристиками, производительность, скорее всего, тоже пострадает. Поскольку технология совсем новая, пока еще не опубликовано готовых рецептов ее применения, но здравый смысл подсказывает, что нельзя что­то получить, не отдав ничего взамен.

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

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

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

В SQL Server 7.0 создание кластеров было довольно утомительной задачей. Если вы могли создать кластер и поддерживать его в стабильном состоянии, то были очень востребованным специалистом и возможность потери работы вас волновала даже меньше, чем президента компании. Боюсь, что с выходом Windows 2003 и SQL Server 2005 ситуация изменилась. Когда я рассказываю, как создать кластер на базе Windows 2003, первое, что я слышу: «И это все?!». Благодаря мастерам от Microsoft я был свидетелем, как прежнее восхищение моих коллег сменилось этим ужасающим вопросом. Неплохой удар по самолюбию для тех, кто считал себя незаменимым, потому что мог объединять серверы в кластеры.

Прежде чем углубиться в кластеризацию SQL Server, нужно познакомиться с базовой терминологией. Когда я впервые имел дело с кластеризацией компьютера на базе Windows, терминология вызывала у меня панику, поскольку была мне совершенно чужой. Посмотрим, смогу ли я объяснить все лучше. Кластеризация позволяет иметь набор серверов, которые делят между собой набор дисков. Если один из серверов выходит из строя, его ресурсы, такие как SQL Server, переносятся с текущего сервера на один из оставшихся. В правильно сконфигурированном кластере весь процесс занимает меньше минуты. Бывает и так, что SQL Server требуется около 5 минут для переноса ресурсов с одного сервера на другой. Время варьируется в зависимости от применяемого аппаратного обеспечения и в значительной мере от времени, необходимого для останова служб на одном сервере и запуска на другом.

Самое распространенное заблуждение, связанное с кластерами на базе Windows, заключается в том, что их применение повышает производительность, но это не так. Кластеризация — это не механизм для масштабирования или распределения трафика. Идея в том, что, если один из серверов выходит из строя, его службы и разделяемые данные переносятся на другой сервер в кластере. А для масштабирования трафика предназначены распределенные разделенные представления и репликация. Основное ПО для управления кластеризацией в Windows — это Microsoft Cluster Service (MSCS). Для создания кластера вы должны использовать как минимум Windows 2003 Enterprise Edition. Windows 2003 Data Center предоставляет гораздо лучшую защиту от сбоев, но по очень высокой цене. Можно купить ПО и оборудование сторонних разработчиков, но MSCS становится все надежнее, что приводит к вытеснению с этого рынка многих производителей. Например, HP/Compaq недавно отказались от своего решения для кластеризации под названием RSO, и их персонал по продажам теперь продвигает MSCS.

Каждый участвующий в кластеризации сервер называют узлом (node). Windows 2003 Server Enterprise Edition и DataCenter Edition поддерживают до восьми узлов в кластере. В Windows 2000 Enterprise Edition вы могли создавать кластеры лишь из двух узлов. Инструмент под названием Cluster Administrator управляет в Windows ресурсами кластера, в том числе ресурсами SQL Server, например такими, как SQL Server Agent. В Cluster Administrator можно задать, какой сервер будет предпочтительным владельцем ресурса (вроде SQL Server), а также кто может владеть ресурсом кроме него. То есть, имея возможность создавать кластеры из восьми узлов, вы можете возложить задачу отказоустойчивости данной службы на конкретный узел. Кроме того, можно указать, что одна служба зависит от другой. Указав зависимую службу, можно гарантировать, что SQL Server не запустится, пока не готовы диски.

13. Типовая организация современной СУБД.

Организация типичной СУБД и состав ее компонентов соответствует набору функций.

- управление данными во внешней памяти;

- управление буферами оперативной памяти;

- управление транзакциями;

- журнализация и восстановление БД после сбоев;

- поддержание языков БД.

Логически в современной реляционной СУБД можно выделить наиболее внутреннюю часть:

- ядро СУБД (часто его называют Data Base Engine),

- компилятор языка БД (обычно SQL),

- подсистему поддержки времени выполнения,

- набор утилит.

В некоторых системах эти части выделяются явно, в других - нет, но логически такое разделение можно провести во всех СУБД.

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

- как менеджер данных,

- менеджер буферов,

- менеджер транзакций

- менеджер журнала.

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

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

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

14. Администрирование. Важнейшие задачи администрирования.

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

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

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

1) Обеспечение доступности данных

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

Сервер MySQL работает в виде демона, обычно круглосуточно. Сценарий safe_mysqld, входящий в состав дистрибутива, отслеживает те редкие случаи, когда демон зависает, и перезапускает его. Время от времени необходимо приостанавливать сервер и отменять все соединения, чтобы можно было выполнить плановые проверки и восстановить целостность базы данных. Это лучше всего делать в периоды отсутствия активности со стороны пользователей, как правило, ночью. Если база данных на Web-узле, то рекомендуется проанализировать журнальные файлы Web-сервера и определить часы наименьшей активности, когда количество подключений минимально.

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

Язык SQL настолько прост, что он легко может быть освоен большинством пользователей. Администратору есть смысл потратить время на то, чтобы научить пользователей работать с утилитами MySQL или другими приложениями, допускающими ввод запросов. Если пользователи смогут самостоятельно создавать отчеты, администратор освободится для решения более важных задач.

2) Поддержание целостности данных

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

Не надо выдавать учетные записи пользователям БД без особой необходимости.

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

Надо задать список узлов, от которых можно принимать запросы. Должен быть задан перечень разрешенных IP-адресов.

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

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

3) Подготовка к катастрофе

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

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

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

-Регулярно проверяйте архивы, чтобы защитить себя от неприятных сюрпризов.

4) Поддержка пользователей

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

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

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

Администратор может потребовать от пользователей составлять отчеты о замеченных аномалиях.

5) Разработка и внедрение стандартов

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

О хранении данных

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

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

Двоичный журнал

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

Утилита mysqlbinlog читает двоичный журнал и записывает извлеченные из него инструкции в поток stdout. Их можно направить утилите MySQL чтобы воспроизвести все изменения. Это хороший способ восстановления после краха.

Журнал отладки

Журнал отладки начинает вестись, если при компиляции клиента или сервера подключить средства отладки. По умолчанию отладочная информация записывается в файл /tmp/mysql.trace.

Журнал ошибок

В журнале ошибок хранится информация о запуске и остановке сервера.

Здесь же регистрируются сообщения об ошибках и предупреждения. Журнал ошибок находится в каталоге данных. Его имя соответствует имени компьютера с добавлением расширения .err.

Журнал MyISAM

Журнал используется для отладки обработчика таблиц MyISAM. Существует утилита myisamlog, предназначенная для сбора статистической информации из этого файла. Информация представляет интерес только для разработчиков MySQL.

Журнал запросов

Журнал запросов регистрирует все запросы, посылаемые базе данных. Журнал находится в каталоге данных. Его имя соответствует имени компьютера с добавлением расширения .log. Журнал разрастается наиболее быстро, поэтому он не должен быть постоянно активен.

Журнал медленных запросов

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

Безопасность

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

15. Модели данных: от систем управления файлами до объектно-реляционных баз данных.

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

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

В 1968 г. компаниями Rockwell и IBM была разработана специальная автоматизированная система IMS (Information Management System), заложившая основу концепции СУБД.

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

Другое новшество - создание специализированного языка составления нерегламентированных запросов к базе данных.

В СУБД IMS была реализована иерархическая модель данных, в которой существует один-единственный путь к каждой записи. Недостатки такой модели подтолкнули разработки в этом направлении. Появились разработки, обеспечившие возможность использования сетевой, а далее и реляционной моделей данных. Одновременно были начаты и реализованы разработки в части стандартизации по разработке языков запросов. В 1986 г. организация ANSI опубликовала официальный стандарт языка SQL.

Системы управления файлами

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

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

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

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

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

Иерархические базы данных

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

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

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

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

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

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

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

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

Сетевые базы данных

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

Следуя спецификации CODASYL (Conference on Data Systems Languages - конференции по языкам обработки данных) сетевая модель поддерживает DDL (Data Definition Language? язык определения данных) и DML (Data Manipulation Language - язык обработки данных). Это специальные языки, предназначенные для определения структуры данных и составления запросов. И, однако, программист по-прежнему должен знать структуру базы данных.

В сетевой модели допускаются отношения "многие ко многим", а записи не зависят друг от друга. При удалении записи удаляются и все ее связи, но не сами связанные записи.

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

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

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

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

Реляционные базы данных

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

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

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

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

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

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

Объектно-ориентированные базы данных

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

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

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

С помощью ООБД:

-сложные информационные структуры выражаются лучше, чем в реляционных БД,

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

Если отношения между данными очень сложны,

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

Для ООБД язык составления запросов не обязательно SQL. Если логическое представление не соответствует SQL, то применение SQL становится бессмысленным, и есть смысл составлять нерегламентированные запросы, используя язык описания объекта ООБД. И именно это же является большим недостатком ООБД то, что последние оказываются тесно связанными с применяемыми языками программирования, ибо к ним могут обратиться далеко не все приложения (а только те, которые работают с соответствующими языками программирования.

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

Объектно-реляционные СУБД объединяют в себе черты реляционной и объектной моделей. Реляционные БД хорошо работают со встроенными типами данных и гораздо хуже - с нестандартными.

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

16. Возможности MSSQL.

Краткий обзор СУБД MS SQL 2000

Рассмотрим более подробно конфигурацию MS SQL по умолчанию. В данной СУБД есть несколько служебных баз данных, создаваемых в процессе его установки (master, tempdb, model, msdb, pubs) и тестовая база данных (Northwind).

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

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

Расширенные хранимые процедуры - это разновидность обычных хранимых процедур, но в них можно использовать обращения к подпрограммам, написанным на языке С или С++, что позволяет расширить возможности T-SQL. Обычно расширеннные хранимые процедуры представляются в виде динамических библиотек. Имена этих процедур как правило начинаются с префикса xp (eXtended Procedure). Вместе с MS SQL поставляется большой набор расширенных хранимых процедур. Наиболее интересная из них - xp_cmdshell. Она предоставляет доступ к командной строке операционной системы. Так как данная хранимая процедура обладает широкими возможностями, то по умолчанию доступ к ней разрешен только владельцу базы данных master, то есть пользователю, наделенному ролью "Администратор базы данных".

Теперь рассмотрим способы аутентификации в MS SQL. Первый вариант - аутентификация средствами Windows, второй - аутентификация средствами самой СУБД (в том случае если при установке MS SQL был выбран смешанный режим аутентификации).

В первом варианте аутентификация пользователя проводится средствами операционной системы, и вход осуществляется с использованием учетных данных пользователя ОС Windows. Стоит отметить, что в этом случае при установке MS SQL всем пользователям операционной системы, входящим в группу "Администраторы", автоматически назначается роль "Администратор базы данных".

Во втором случае аутентификацию проводит СУБД, используя собственную базу учетных записей пользователей. При установке MS SQL будет создана учетная запись "sa" с ролью "Администратор базы данных".

Проникновение

Рассмотрим сценарий атаки на сервер с установленным MS SQL Server 2000. Потенциальному нарушителю необходимо получить доступ к MS SQL с ролью "Администратор базы данных", а это может легко произойти если:

* пароль учетной записи "sa" пустой или может быть легко подобран, что часто встречается, когда СУБД используется в тестовой эксплуатации, либо как платформа для разработчиков;

* неправильно назначены роли пользователей в самой СУБД: учетная запись обычного пользователя СУБД обладает ролью "Владелец базы данных" master, либо ролью "Администратор базы данных".

* пароль некоторой учетной записи, входящей в группу "Администраторы", пустой или может быть легко подобран или определен (задача получения доступа к серверу, зная пароль администратора, на первый взгляд может показаться странной, но, например, если к серверу разрешено подключение только к портам MS SQL, описываемый в статье способ позволяет выполнять команды ОС).

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

Для этого необходимо запустить SQL Server Enterprise Manager, входящий в состав MS SQL Server (ссылка на данную оснастку находится в Пуск->Программы->Microsoft SQL Server). Далее в Enterprise Manager требуется создать новое поключение к SQL-серверу, и, после установления связи с сервером, создать новое представление (view) для базы данных master.

В появившемся окне, предназначенном для ввода SQL-запросов, можно ввести и выполнить следующие команды для создания нового пользователя операционной системы с правами администратора:

* EXEC xp_cmdshell 'net user test_user test_passW0rd /add' - вызывает хранимую процедуру xp_cmdshell и передает ей в качестве параметра команду операционной системы, создающую в системе нового пользователя test_user с паролем test_passW0rd.

* EXEC xp_cmdshell 'net localgroup Administrators test_user /add' - данная команда добавляет пользователя test_user в локальную группу "Администраторы".

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

17. Реляционная модель данных.

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

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

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

РБД базируется на совместном использовании взаимосвязанных таблиц. Связь между записями является неотьемлемым свойством РМ. С помощью РМ достигается информационность и структурная независимость. Записи не связаны друг с другом.

Язык SUE SQL ПЕРВЫЙ ДЛЯ РАБОТВЫ с БД.

+ РМ

*структурная незаисимость

*концептуальная простота

*относительная простота проектирования, реализации, управления и использования БД

*возможность реализации не регламентированных запросов

-РМ

*существенные требования к оборудованию и СО

*слабое представление сущностей реального мира

*семонтическая перегрузка

*слабая поддержка обеспечения целостности и корпоративности ограничений

*однородная структура данных

*ограниченный набор операций

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

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

N-арным отношением R называют подмножество декартова произведения

D1хD2х ... Dn множеств D1,D2, ..., Dn (n>=1)), необязательно различных. Исходные множества

D1,D2, ..., Dn называют в модели доменами.

R?D1х D2х : Dm, где D1, D2, : Dm - полное декартово произведение.

Полное декартово произведение - это набор всевозможных сочетаний из n элементов каждое, где каждый элемент берется из своего домена.

Например, имеем три домена:

D1 содержит три фамилии,

D2 - набор из двух учебных дисциплин и

D3 - набор из трех оценок.

Допустим, содержимое доменов следующее:

D1 = Иванов, Крылов, Степанов;

D2 = Теория автоматов, Базы данных;

D3 = 3, 4, 5

Данная таблица обладает рядом специфических свойств:

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

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

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

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

Схемой отношения R называется перечень имен атрибутов данного отношения с указанием домена, к которому они относятся:

SR = (A1, A2, : An), Ai ? Di

Если атрибуты принимают значения из одного и того же домена, то они называются ? -сравнимыми, где ? - множество допустимых операций сравнения, заданных для данного домена. Например, если домен содержит числовые данные, то для него допустимы все операции сравнения, тогда ? = =, <>,>=,<=,<,>. Однако и для доменов, содержащих символьные данные, могут быть заданы не только операции сравнения по равенству и неравенству значений. Если для данного домена задано лексикографическое упорядочение, то он имеет также полный спектр операций сравнения.

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

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

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

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

отношения.

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

В подчиненном отношении для моделирования связи должен присутствовать набор атрибутов, соответствующий первичному ключу основного отношения. Однако здесь этот набор атрибутов уже является вторичным ключом, то есть он определяет множество кортежей подчиненного отношения, которые связаны с единственным кортежем основного отношения. Данный набор атрибутов в подчиненном отношении принято называть внешним ключом (FOREIGN KEY).

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

PRIMARY KEY отношения Сотрудник атрибут Паспорт является FOREIGN KEY для отношения <карьера>.

Схемы привилегий

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

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

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

-columns_priv - привилегии отдельных столбцов,

-db - привилегии всей базы данных,

-host - привилегии всех пользователей того или иного узла.

-tables_priv - привилегии отдельных таблиц,

-user - глобальные привилегии.

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

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

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

Следует, правда, отметить, что любому зарегистрированному пользователю разрешено вводить инструкции SELECT с литералами в списке возвращаемых столбцов, например, SELECT NOW().

За каждым пользователем каждого узла в таблице user закреплен свой набор привилегий, заданных в виде перечислений со значениями 'Y'/'N'. В столбце Host содержится IP-адрес либо доменное имя компьютера. Для задания диапазона адресов можно использовать метасимволы % и _.

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

Столбец User содержит строку регистрационного имени пользователя. Метасимволы в строке недопустимы. Запись с пустым полем имени соответствует анонимным пользователям. Они могут регистрироваться в системе под любым именем, если только оно не указано в других записях. Столбец Password содержит пароль пользователя, зашифрованный по специальному алгоритму.

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

Таблицы db и host совместно контролируют доступ к базам данных. В таблице db записи сортируются в таком порядке: имя узла, имя базы данных, имя пользователя. Записи таблицы host сортируются сначала по имени узла, потом - по имени базы данных.

Названия привилегий в большинстве своем соответствуют названиям инструкций SQL, поэтому по названию привилегии легко понять, какие права получает пользователь. Привилегия File разрешает пользователям выполнять инструкцию LOAD DATA INFILE, а также инструкцию SELECT с предложением INTO OUTFILE. Она определяет лишь возможность

чтения и записи файлов на сервере.

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

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

Операции над отношениями. Реляционная алгебра

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

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

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

18. Резервное копирование и восстановление БД.

Резервное копирование и восстановление из копии является одним из самых важных процессов в администрировании базы данных InterBase/FireBird.

Резервное копирование – один из самых надежных способов сохранить и предохранить свои данные от потери или порчи. Процесс резервного копирования также делается в профилактических целях, для увеличения производительности базы данных – это достигается за счет того, что в момент копирования происходит считывание последних версий всех записей, старые же версии в копию никогда не попадают. Здесь важно заметить, что недостаточно одного лишь резеврного копирования, нужно иногда проверять восстанавливаемость базы данных из резеверной копии, потому что бывают случаи, что база данных работает в режиме 24*7, то есть 24 часа в сутки и 7 дней в неделю, backup базы данных может происходит нормально, но в силу определенных причин база данных не восстанавливается, последствия могут быть плачевными для всех данных.

Причины могут следующими: в базе данных есть ограничения, такие как NOT NULL поля, внешние ключи, уникальность, а существующие данные в базе данных этим ограничениям не соответствуют по каким-либо причинам. Такие данные могут мирно существовать до тех пор, пока они не будут задействованы в операциях редактирования или удаления. В процессе восстановления «прощупываются» все данные - в первую очередь создаются ограничения и затем заливаются данные, в этот момент и происходит ошибка. Для профилактики следует восстанавливать базу данных в тестовую, и лишь при успешном завершении процесса восстановления, делать Restore в текущую базу. В случае возникновения ситуации с поврежденным файлом backup’а следует найти в базе данных несоответствия и исправить их.

Резервное копирование (backup) и восстановление базы данных из резервной копии (restore) являются наиболее частыми, ответственными и абсолютно необходимыми процессами для нормальной работы.

Подробно процесс резервного копирования (как и проблемы, возникающие при этом и их решение) рассмотрен в книге (страница 307 и далее...), иметь которую под рукой при эксплуатации сервера FireBird (InterBase) настоятельно рекомендуется. Я позволю себе процитировать несколько абзацев из этой книги, поскольку лучше её уважаемых авторов, пожалуй, не скажешь.

Резервное копирование (backup) базы данных и восстановление из резервной копии (restore) - два важнейших и наиболее частых административных процесса, которые осуществляются разработчиками и администраторами InterBase. Резервное копирование базы данных - практически единственный и самый надежный способ предохранить ваши данные от потери в результате поломки диска, сбоев электропитания, действий злоумышленников или ошибок программистов: Помимо сохранения данных от возможных опасностей, в процессе резервного копирования создается независимый от платформы стабильный "снимок" базы данных, с помощью которого легко перенести данные на другую ОСили даже другую платформу.

Backup базы данных производит своего рода "освежение" данных в базе данных, производя сборку "мусора" во время процесса считывания данных. Полный цикл: резервное копирование и восстановление из резервной копии (часто эту последовательность действий называют backup/restore или сокращенно b/r) - является средством от излишнего "разбухания" базы данных, служит для корректировки статистической информации и является обязательным участником всех профилактических и "лечебных" процедур обслуживания базы данных.

В процессе backup/restore сначала все данные из базы данных копируются в backup-копию базы данных - файл специального формата (не GDB), а затем на основе сохраненных данных база данных полностью пересоздается. Можно сказать, что процессы backup и restore - лучшие друзья разработчика и администратора InterBase. Регулярное выполнение backup/restore поддерживает "здоровье" базы данных в прекрасном состоянии, предохраняя данные от порчи и возможных ошибок.

Помимо "лечебных" целей, процесс backup/restore дает возможность изменить многие ключевые характеристики базы данных - например, сменить размер страницы базы данных, установить для базы данных режим "только чтение" (readonly), разбить файл базы данных на несколько частей. Например, смена основных версий ODS (On-Disk Structure) и миграция от одной версии InterBase-сервера к другой происходят только при помощи процесса backup/restore.

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

Резервное копирование (backup) базы данных - это процесс считывания всех данных из базы данных и сохранения их в виде одного или нескольких файлов на диске или устройстве резервного копирования.

Во время backup происходит считывание самых последних версий записей в таблицах базы данных на момент запуска процесса резервного копирования. Старые версии записей никогда не попадают в backup. Backup - это не просто сохранение базы данных путем простого файлового копирования средствами ОС. Во время backup специальная программа-клиент подключается к базе данных в режиме чтения и считывает все системные и пользовательские данные в файл особого формата, который обычно имеет расширение gbk (groton backup, по всей видимости).

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

* Backup базы данных InterBase может осуществляться одновременно с работой обычных клиентских программ.

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

* Во время backup происходит считывание каждой записи из каждой таблицы в базе данных. Таким образом, происходит сборка "мусора" в базе данных (garbage collection): версии записей или их фрагменты, которые не являются актуальными, уничтожаются. Место из-под удаленных версий освобождается, и оставшиеся данные переупаковываются.

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

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

Восстановление из резервной копии (restore) - это процесс создания базы данных на основе информации, извлекаемой из файла резервной копии.

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

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

Обычно рекомендуется проводить полный цикл backup/restore не реже чем раз в месяц, чтобы избежать излишнего "разбухания" базы данных от накопленных версий. Трудно переоценить возможность полного пересоздания базы данных (можно даже сказать - возрождения) на основе "мгновенного снимка" информации из базы данных. Только во время восстановления можно сменить основную версию ODS, перейти на другую платформу или ОС. Также restore является обязательным участником процесса преобразования однофайловой базы данных в многофайловую.

Обращаем Ваше внимание, что удаление данных за период средствами программы не изменяет объём базы данных. Удаляемые записи просто помечаются как удалённые, но место в файле базе данных на диске продолжают занимать. Для реального освобождения места за счёт удаления данных необходимо выполнить процедуру backup/restore с базой данных программы.

19. Теоретико-множественные операции реляционной алгебры.

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

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

Разностью отношений R1 и R2 называется отношение, содержащее множество кортежей, принадлежащих R1 и не принадлежащих R2

Следует отметить, что первые две операции, объединение и пересечение, являются коммутативными операциями, то есть результат операции не зависит от порядка аргументов в операции. Операция же разности является принципиально несимметричной операцией, то есть результат операции будет различным для разного порядка аргументов, что и видно из сравнения отношений R5 и R6.

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

Расширенное декартово произведение

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

Сцеплением, или конкатенацией, кортежей с = <С1, ..., Сn> и q = <q1, ..., qm> называется кортеж, полученный добавлением значений второго в конец первого. Сцепление кортежей с и q обозначается как (с, q).

Все предыдущие операции не меняли степени или арности отношений - это следует из определения эквивалентности схем отношений. Операция декартова произведения меняет степень результирующего отношения.

Расширенным декартовым произведением отношения R1 степени n со схемой

SR1 = (А1, А2, ... , Аn) и отношения R2 степени m со схемой SR2 = (B1, B2, ..., Вm)

называется отношение Rз степени n+m со схемой SR3 = (A1, А2, ... , Аn, В1, В2, ..., Вm),

содержащее кортежи, полученные сцеплением каждого кортежа r отношения

R1 с каждым кортежем q отношения R2.

То есть, если R1 = r , R2 = q , то

R1 ? R2 = (r, q) | г ? R1 ? q ? R2

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

20. Инструменты администрирования.

21. Специальные операции реляционной алгебры.

Специальные опереции РА:

1.операция выбора R2=R1[начислено=2000]

2. операция проектирования-результат достигается в 2 шага- вычеркивание лишних полей, вычеркивание повторяющихся записей R11=R1[Начислено]

3. опрерация условного соединения выполняется в 2 этапа - декартово произведение, вычеркивание всех записей не удовлетворяющих условию RR12=R1[R1.t=R2.t]R2

22. Преимущества и недостатки распределенных СУБД.

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

Обзорная таблица

Преимущества Недостатки

Отображение структуры организации Повышение сложности

Разделяемость и локальная автономность Увеличение стоимости

Повышение доступности данных Проблемы защиты

Повышение надежности Усложнение контроля за целостностью данных

Повышение производительности Отсутствие стандартов

Экономические выгоды Недостаток опыта

Модульность системы Усложнение процедуры разработки базы данных

Преимущества и недостатки РСУБД

Системы с распределенными базами данных имеют преимущества перед традиционными централизованными системами баз данных:

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

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

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

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

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

6. Экономические выгоды. В шестидесятые годы мощность вычислительной установки возрастала пропорционально квадрату стоимости ее оборудования, поэтому система, стоимость которой была втрое выше стоимости данной, превосходила ее по мощности в девять раз. Эта зависимость получила название закона Гроша (Grosch). Однако в настоящее время считается общепринятым положение, согласно которому намного дешевле собрать из небольших компьютеров систему, мощность которой будет эквивалентна мощности одного большого компьютера. Оказывается, что намного выгоднее устанавливать в подразделениях организации собственные маломощные компьютеры, кроме того, го­раздо дешевле добавить в сеть новые рабочие станции, чем модернизировать систему с мейнфреймом.

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

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

К сожалению, системы с распределенными базами данных не лишены некоторых недостатков:

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

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

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

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

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

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

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

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

23. Проектирование баз данных.

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

Проектирование БД может осуществляться на основе нисходящего и восходящего подхода.

Нисходящий подход означает разработку системы с верхнего уровня к нижнему.

Восходящий подход – процесс разработки ведется от простых компонентов к сложным.

Задачи проектирование:

1. определение модели и состава таблиц

2. определение всех вторичных и первичных ключей

3. выполнение нормалтзации(иногда денормализации)

4. определение какие прикладные процессы необходимо реализвать как хранимые процедуры

5. выявление и реализация ограничений для обеспечения цлостности БД

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

7. разработка стратегии индексирования и кластеризации

8. оценка размеров таблиц и индексов

9. определение уровня доступа пользователей, правила безопастности и аудита

10. разработка сетевой топологии БД и механизма доступа к удаленным данным

24. Понятие об ООСУБД.

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

Любая сущность реального мира в объектно-ориентированных языках и системах моделируется в виде объекта.

Объект – это уникально идентифицируемая сущность, которая содержит атрибуты, описывающие состояние объектов "реального мира", и связанные с ними действия.

Объект получает генерируемый системой уникальный идентификатор, связанный с объектом во все время его существования и не меняется при изменении состояния объекта. Каждый объект имеет состояние (набор значений его атрибутов) и поведение (набор методов (программный код), оперирующих над состоянием объекта). Атрибуты объектов называются переменными экземпляра (instance variables). Значение атрибута объекта – это тоже некоторый объект или множество объектов. Каждый атрибут имеет уникальное имя и тип данных.

Традиционные типы данных, называемые базовыми типами данных (base data types) или договорные типы данных (conventional data types), используются в большинстве языков программирования и включают типы real (вещественный), integer (целый), string (строковый) и т.д.

Для атрибутов определены домены – логические группы, представляющие собой набор возможных значений данного атрибута. Типы данных определяют базовые домены, т.е. тип real представляет собой все вещественные числа, тип integer – все целые числа, тип date – все возможные даты, тип string – любые комбинации символов и т.д. Однако домены базовых типов данных представляют собой лишь основу, используемую для создания более ограниченных именованных доменов на более высоком логическом уровне.

Например, мы можем создать домен SRTEMP (средняя температура). Для точного определения домена атрибута SRTEMP мы должны создать домен с именем ‘SRTEMP’. Каждый домен имеет имя и описание, включая базовый тип данных, размер, формат и ограничения на значения домена. Поэтому мы можем определить домен ‘SRTEMP’ как любое вещественное число с двумя знаками после запятой. Домен может также определяться как список возможных значений, разделенных запятыми. Например, домен ‘STUDENT’ может быть определен как (NSTUD, FIO, GR, LANGUAGE).

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

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

Для каждого метода определяются имя (name) и тело (body). Тело состоит из компьютерных инструкций на некотором языке программирования, описывающих некоторое реальное действие.

Для инициализации метода объекту посылается сообщение. При отправлении сообщения (message) задаются объект-адресат, имя метода и все необходимые параметры.

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

Классы организуются в иерархию классов.

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

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

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

? В ООСУБД каждая определенная пользователем структура – это объект, непосредственно управляемый базой данных. Пользователь просто объявляет связь, и СУБД автоматически генерирует методы управления, динамически создавая, удаляя и пересекая связи. Ссылки при этом прямые, нет необходимости в

просмотре и сравнении или даже поиске индекса, который может сильно сказаться на производительности. Поэтому применение объектной модели предпочтительнее для баз данных с большим количеством сложных связей: перекрестных ссылок, ссылок, связывающих несколько объектов с несколькими (many-to-many relationships) двунаправленными ссылками.

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

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

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

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

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

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

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

С помощью ООСУБД:

• сложные информационные структуры выражаются лучше, чем в реляционных БД,

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

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

В этой модели данных поддерживаются и нерегламентированные запросы, но языком их составления не обязательно является SQL. Если логическое представление не соответствует SQL, то применение SQL становится бессмысленным, и есть смысл составлять нерегламентированные запросы, используя язык описания объекта ООСУБД.

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

Преимущества

? Улучшенные возможности моделирования. Допускается более точное моделирование реального мира.

? Расширяемость. Допускается создание новых типов данных на основе существующих типов.

? Устранение проблемы несоответствия. Простой интерфейс между языком манипулирования данными (типа SQL) и языком программирования (типа С).

Более выразительный язык запросов.

? Поддержка эволюции схемы.

? Поддержка долговременных транзакций.

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

? Повышенная производительность (при решении отдельных задач до 30-кратной по сравнению с реляционными СУБД, но далеко не всегда).

Недостатки

? Отсутствие универсальной модели данных. Большинство моделей не имеет теоретического обоснования.

? Недостаточность опыта эксплуатации. ОО системы все еще больше отвечают требованиям программиста, чем неопытного конечного пользователя.

? Отсутствие стандартов.

? Влияние оптимизации запросов на инкапсуляцию. Оптимизация работы невозможна без нарушения принципа инкапсуляции.

? Влияние блокировки на уровне объекта на производительность. Применение блокировки на уровне объектов может вызвать проблемы с блокировкой в отношении иерархии наследования.

? Сложность. Повышенная сложность систем ведет к созданию более дорогих и трудных в использовании продуктов.

? Отсутствие поддержки представлений.

? Недостаточность средств обеспечения безопасности.

25. История развития SQL.

SQL (Structured Query Language) - Структурированный Язык Запросов - это стандартный язык запросов по работе с реляционными БД. Язык SQL появился после реляционной алгебры, и его прототип был разработан в конце 70-х годов в компании IBM Research. Он был реализован в первом прототипе реляционной СУБД фирмы IBM System R. В дальнейшем этот язык применялся во многих коммерческих СУБД и в силу своего широкого распространения постепенно стал стандартом <де-факто> для языков манипулирования данными в реляционных СУБД.

Первый международный стандарт языка SQL был принят в 1989 г. (далее мы будем называть его SQL/89 или SQL1). Иногда стандарт SQL1 также называют стандартом ANSI/ISO, и подавляющее большинство доступных на рынке СУБД поддерживают этот стандарт полностью. Однако развитие информационных технологий, связанных с базами данных, и необходимость реализации переносимых приложений потребовали в скором времени доработки и расширения первого стандарта SQL. В конце 1992 г. был принят новый международный стандарт языка SQL, который в дальнейшим будем называть SQL/92 или SQL2. И он не лишен недостатков, но в то же время является существенно более точным и полным, чем SQL/89. В настоящий момент большинство производителей СУБД внесли изменения в свои продукты так, чтобы они в большей степени удовлетворяли стандарту SQL2.

В 1999 году появился новый стандарт, названный SQL3. Если отличия между стандартами SQL1 и SQL2 во многом были количественными, то стандарт SQL3 соответствует качественным серьезным преобразованиям. В SQL3 введены новые типы данных, при этом предполагается возможность задания сложных структурированных типов данных, которые в большей степени соответствуют объектной ориентации. Наконец, добавлен раздел, который вводит стандарты на события и триггеры, которые ранее не затрагивались в стандартах, хотя давно уже широко использовались в коммерческих СУБД. В стандарте определены возможности четкой спецификации триггеров как совокупности события и действия. В качестве действия могут выступать не только последовательность операторов SQL, но и операторы управления ходом выполнения программы. В рамках управления транзакциями произошел возврат к старой модели транзакций, допускающей точки сохранения (savepoints), и возможность указания в операторе отката ROOLBACK точек возврата позволит откатывать транзакцию не в начало, а в промежуточную ранее сохраненную точку. Такое решение повышает гибкость реализации сложных алгоритмов обработки информации. А зачем вообще нужны эти стандарты? Зачем их изобретают и почему надо изучать их? Текст стандарта SQL2 занимает 600 станиц сухого формального текста, это очень много, и кажется, что это просто происки разработчиков стандартов, а не то, что необходимо рядовым разработчикам. Однако ни один серьезный разработчик, работающий с базами данных, не должен игнорировать стандарт, и для этого существуют весьма веские причины.

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

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

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

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

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

Для поставщиков СУБД стандарт - это путеводная звезда, которая гарантирует правильное направление работ. А вот эффективность реализации стандарта - это гарантия успеха. SQL нельзя в полной мере отнести к традиционным языкам программирования, он не содержит традиционные операторы, управляющие ходом выполнения программы, операторы описания типов и многое другое, он содержит только набор стандартных операторов доступа к данным, хранящимся в базе данных. Операторы SQL встраиваются в базовый язык программирования, которым может быть любой стандартный язык типа C++, PL, COBOL и т. д. Кроме того, операторы SQL могут выполняться непосредственно в интерактивном режиме. Этот раздел познакомит вас с общими идеями языка SQL, а также с определенными общими выводами, которые существуют в SQL.

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

26. Понятие транзакции. Свойства транзакций.

Транзакция – это совокупность одной или нескольких SQL-инструкций, имеющих начало и конец. В конце транзакции происходит либо ее отмена, либо завершение. Отмена транзакции называется откатом (ROLLBACK), так как происходит последовательная отмена всех сделанных изменений. Успешное завершение транзакции завершается фиксацией результатов (COMMIT или фиксация). Если окажется, что зафиксированная транзакция была ошибочной, потребуется выполнить другую транзакцию, отменяющую действия, выполненные первой транзакцией.

Считается, что правильная транзакция обладает следующими свойствами:

• атомарностью. Под атомарностью понимается принцип неделимости: все инструкции, составляющие транзакцию, обязательно выполняются, иначе не выполняется ни одна из них. Никаких промежуточных состояний не существует. Это свойство типа "все или ничего". Любая транзакция представляет собой неделимую единицу работы, которая может быть либо выполнена целиком, либо не выполнена вовсе;

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

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

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

Транзакция реализуется путем ведения журнала всех изменений, вносимых в базу данных в ходе каждой транзакции. Когда происходит откат, СУБД сверяется с журналом и отменяет все изменения. По журналу легко можно восстановить согласованное состояние базы данных в случае сбоя. Ведение журнала транзакций приводит к снижению производительности, поэтому в MySQL для таблиц стандартного типа – MyISAM – транзакции не поддерживаются. Это одна из причин столь высокой скорости работы программы.

Транзакции в MySQL появились сравнительно недавно и поддерживаются пока только для таблиц расширенных типов, таких как InnoDB, Berkeley DB, Gemini. Однако следует отметить, что во многих ситуациях транзакции не нужны, так как табличных блокировок более чем достаточно.

В отличие от других СУБД, MySQL предоставляет пользователям право выбора:

• можно работать с более медленными таблицами, поддерживающими транзакции, или

• с более быстрыми таблицами, где транзакции недопустимы.

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

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

27. Типы данных.

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

Некоторые типы данных покажутся вам знакомыми, но учтите, что каждый тип данных имеет специфику использования. Например, не применяйте типы данных с префиксом "n" без настоятельной необходимости хранить символы в коде Unicode. Символы в Unicode, которые вынужден будет хранить SQL Server, займут больше места, чем стандартные символы из-за потенциально широкого набора символов. А также для чисел с максимальным значением 00 в столбце не следует выбирать тип данных, позволяющий хранить большие числа. Это неэкономное расходование пространства на диске.

Char - Тип данных char имеет фиксированную длину. Если определить для столбца длину 20 символов, то храниться будут 20 символов. Если ввести меньше символов, чем определено, то оставшаяся часть будет дополнена пробелами справа. Следовательно, если столбец был определен как char (10), то "ааа" будет храниться как "ааа ". Этот тип данных следует использовать в случае, если данные в столбце должны иметь фиксированную длину, например, идентификаторы клиентов или идентификаторы банковских счетов.

Varchar - Тип данных varchar содержит алфавитно-цифровые данные точно так же, как char. Отличие в том, что каждая строка может содержать различное количество символов в пределах указанной максимальной длины. Если стол определен, как varchar(50), то данные в столбце могут иметь длину 50 символов. Но если сохранить строку из 3 символов, то будет использовано пространство только для 3 символов. Это определение подходит для случаев, когда данные не имеют определенной длины— например, фамилии людей или описания, в которых длина сохраняемого элемента не имеет значения. Максимальный размер столбца varchar составляет 8000 символов. Но если. указать столбец без длины (т. е. varchar () ), то по умолчанию будет выбрана длина 1.

Text - Тип данных text хранит данные с длиной более 8000 символов. Но использовать этот тип данных не рекомендуется.

Image - Тип данных image очень похож на тип данных text, за исключением того, что он предназначен для любого типа двоичных данных, включая изображения, но в него могут также входить фильмы, музыка и т. п.

Int - Тип данных int или integer используется для хранения числовых значений без десятичной точки (целые числа). Для значений хранящихся в нем чисел существует ограничение: тип int предназначен для хранения чисел в диапазоне от -2 147 483 648 до 2 147 483 647.

Float - Тип данных float используется для чисел с плавающей десятичной точкой.

Real - Тип данных real очень похож на тип float, за исключением того, что real может хранить числа только в диапазоне от -З.40х10³⁸ до 3.40x10³⁸. Этот тип данных также содержит аппроксимированные значения.

Money - Тип данных money служит для хранения числовых значений с точностью до четырех десятичных разрядов после точки.

Date - Новый тип данных date был создан исключительно для хранения дат от 1 января 1 г. н. э. до 31 декабря 9999 г. в формате YYYY-MM-DD.

Datetime - Тип данных datetime может содержать любую дату от 1 января 1753 г. до 31 декабря 9999 г. Но в нем хранится не только дата, но и время в формате YYYY-MM-DD hh:mm:ss. Если указать в качестве значения в столбце, определенном как datetime, только дату, то будет также сохранено время по умолчанию 12:00:00.

Программные типы данных

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

Cursor - Данные могут храниться в структуре, называемой cursor, которая постоянно находится в памяти. Этот тип данных подобен таблице, т. к. имеет строки и столбцы данных, но на этом сходство заканчивается. Например, в нем нет индексов. Курсор используется с целью создания набора данных для построчной обработки.

Table - Тип данных table имеет сходство как с курсором, так и с таблицей. Он содержит строки и столбцы данных, но эти данные невозможно индексировать. В этом случае обрабатывается один набор данных, как обычная таблица. Типы данных cursor и table будут рассмотрены позже, т. к. они относятся к дополнительной тематике.

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

28. Редакции SQL Server.

Решение SQL Server 2008 R2 построено на основе SQL Server 2008, отличаясь улучшенным масштабированием, более эффективными технологиями, а также расширенными возможностями для самостоятельного бизнес-анализа и составления отчетов. Предусмотрено две новых премиальных редакции SQL Server 2008 R2, которые предназначены специально для крупных центров обработки данных и хранилищ данных.

* SQL Server 2008 R2 Datacenter

* SQL Server 2008 R2 Parallel Data Warehouse

Новые премиальные редакции

Datacenter

Решение SQL Server 2008 R2 Datacenter разработано на основе SQL Server 2008 R2 Enterprise и является высокопроизводительной платформой данных, которая обеспечивает максимальный уровень масштабируемости , виртуализацию, консолидацию и управление инфраструктурой баз данных компании. Редакция Datacenter помогает организациям экономически эффективно масштабировать основную среду.

Редакция Datacenter обладает следующими ключевыми возможностями.

* Управление приложениями и серверами: получение сведений о состоянии и управление более 25 экземплярами СУБД.

* Передовая технология виртуализации позволяет максимально эффективно осуществлять консолидацию и виртуализацию.

* Технология SQL Server StreamInsight для крупномасштабной обработки сложных событий.

* Поддержка более чем 8 физических и до 256 логических процессоров.

* Поддержка памяти в пределах лимита для операционной системы.

Parallel Data Warehouse

SQL Server 2008 R2 Parallel Data Warehouse — это масштабируемое аппаратное решение для хранилища данных. Благодаря архитектуре массовой параллельной обработки (MPP) и совместимости с оборудованием партнеров оно обеспечивает высокую производительность и низкие издержки, позволяя создавать хранилища данных размерами в десятки и сотни терабайт.

Новая редакция Parallel Data Warehouse обладает следующими ключевыми возможностями.

* Архитектура МРР обеспечивает хранение десятков и сотен терабайт данных.

* Передовые функции хранилища данных, например запросы соединения типа «звезда» и отслеживание измененных данных.

* Интеграция с SSIS, SSRS и SSAS.

* Поддержка стандартной отраслевой звездообразной архитектуры хранилища данных и параллельной копии базы данных.

29. Инструкция выбора SELECT. Общая структура и назначение компонентов.

Язык запросов (Data Query Language) в SQL состоит из единственного оператора SELECT. Этот единственный оператор поиска реализует все операции реляционной алгебры. Как просто, всего один оператор. Однако писать запросы на языке SQL (грамотные запросы) сначала совсем не просто. Надо учиться, так же как надо учиться решать математические задачки или составлять алгоритмы для решения непростых комбинаторных задач. Один и тот же запрос может быть реализован несколькими способами, и, будучи все правильными, они, тем не менее, могут существенно отличаться по времени исполнения, и это особенно важно для больших баз данных.

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

SELECT [ALL| DISTINCT] <Cписок полей>|*)

FROM <Список таблиц>

[WHERE<Предикат-условие выборки или соединения>]

[GROUP BY<Список полей результата>]

[HAVING<Предикат-условие для группы>]

[ORDER BY<Список полей, по которым упорядочить вывод>]

SELECT - ключевое слово, которое сообщает СУБД, что эта команда - запрос. Все запросы начинаются этим словом с последующим пробелом. За ним может следовать способ выборки - с удалением дубликатов (DISTINCT) или без удаления (ALL, подразумевается по умолчанию). Затем следует список перечисленных через запятую столбцов, которые выбираются запросом из таблиц, или символ '*' (звездочка) для выбора всей строки. Любые столбцы, не перечисленные здесь, не будут включены в результирующее отношение, соответствующее выполнению команды. Это, конечно, не значит, что они будут удалены или их информация будет стерта из таблиц, потому что запрос не воздействует на информацию в таблицах - он только показывает данные.

Здесь ключевое слово ALL означает, что в результирующий набор строк включаются все строки, удовлетворяющие условиям запроса. Значит, в результирующий набор могут попасть одинаковые строки. И это нарушение принципов теории отношений (в отличие от реляционной алгебры, где по умолчанию предполагается отсутствие дубликатов в каждом результирующем отношении).

Ключевое слово DISTINCT означает, что в результирующий набор включаются только различные строки, то есть дубликаты строк результата не включаются в набор.

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

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

Все последующие предложения оператора SELECT являются необязательными.

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

В предложении GROUP BY задается список полей группировки. Строки результирующего набора группируются в соответствии с перечисленными в списке столбцами. Это предложение особенно полезно при определении таких функций, как COUNT() или MAX() в списке полей.

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

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

30. Организация работы с несколькими экземплярами отношения в SQL (MSSQL).

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

В выражении условий предложения WHERE могут быть использованы следующие предикаты:

-Предикаты сравнения =, <>, >,<, >=,<= , которые имеют традиционный смысл.

-Предикат Between A and В - принимает значения между А и В.

Предикат истинен, когда сравниваемое значение попадает в заданный диапазон, включая границы диапазона. Одновременно в стандарте задан и противоположный предикат Not Between A and В, который истинен тогда, когда сравниваемое значение не попадает в заданный интервал, включая его границы.

Предикат вхождения в множество IN (множество) истинен тогда, когда сравниваемое значение входит в множество заданных значений. При этом множество значений может быть задано простым перечислением или встроенным подзапросом. Одновременно существует противоположный предикат NOT IN (множество), который истинен тогда, когда сравниваемое значение не входит в заданное множество.

Предикаты сравнения с образцом LIKE и NOT LIKE. Предикат LIKE требует задания шаблона, с которым сравнивается заданное значение. Предикат истинен, если сравниваемое значение соответствует шаблону, и ложен в противном случае. Предикат NOT LIKE имеет противоположный смысл.

По стандарту в шаблон могут быть включены специальные символы:

-символ подчеркивания (_) - для обозначения любого одиночного символа;

-символ процента (%) - для обозначения любой произвольной последовательности символов;

Остальные символы, заданные в шаблоне, обозначают самих себя.

Предикат сравнения с неопределенным значением IS NULL. Понятие неопределенного значения было внесено в концепции баз данных позднее. Неопределенное значение интерпретируется в реляционной модели как значение, неизвестное на данный момент времени. Это значение при появлении дополнительной информации в любой момент времени может быть заменено на некоторое конкретное значение. При сравнении неопределенных значений не действуют стандартные правила сравнения: одно неопределенное значение никогда не считается равным другому неопределенному значению. Для выявления равенства значения некоторого атрибута неопределенному применяют специальные стандартные предикаты:

<имя атрибута>IS NULL и

<имя атрибута> IS NOT NULL.

Если в данном кортеже (в данной строке) указанный атрибут имеет неопределенное значение, то предикат IS NULL принимает значение <Истина> (TRUE), а предикат IS NOT NULL - <Ложь> (FALSE), в противном случае предикат IS NULL принимает значение <Ложь>, а предикат IS NOT NULL принимает значение <Истина>.

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

Предикаты существования EXIST и не существования NOT EXIST. Эти предикаты относятся к встроенным подзапросам, и подробнее мы рассмотрим их, когда коснемся вложенных подзапросов.

В условиях поиска могут быть использованы все рассмотренные ранее предикаты.

31. Предикаты сравнения для опции WHERE инструкции SELECT.

-Предикаты сравнения { =, <>, >,<, >=,<= }, которые имеют традиционный смысл.

-Предикат Between A and В - принимает значения между А и В. Предикат истинен, когда сравниваемое значение попадает в заданный диапазон, включая границы диапазона. Одновременно в стандарте задан и противоположный предикат Not Between A and В, который истинен тогда, когда сравниваемое значение не попадает в заданный интервал, включая его границы. WHERE name BETWEEN 'А' and 'К';

-Предикат вхождения в множество IN (множество) истинен тогда, когда сравниваемое значение входит в множество множество заданных значений. При этом множество значений может быть задано простым перечислением или встроенным подзапросом. Одновременно существует противоположный предикат NOT IN (множество), который истинен тогда, когда сравниваемое значение не входит в заданное множество. WHERE student_id IN (44)

-Предикаты сравнения с образцом LIKE и NOT LIKE. Предикат LIKE требует задания шаблона, с которым сравнивается заданное значение. Предикат истинен, если сравниваемое значение соответствует шаблону, и ложен в противном случае. Предикат NOT LIKE имеет противоположный смысл. WHERE family LIKE 'За%'

-Предикат сравнения с неопределенным значением IS NULL.

32. Система безопасности SQL Server.

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

1. Терминология и основы системы безопасности SQL Server 2005

Принципалы (principals) — это те объекты, которым в SQL Server 2005 можно предоставлять разрешения. Они могут быть как индивидуальными (например, учетная запись), так и групповыми (например, роль). Далее приведен полный список принципалов в системе безопасности SQL Server 2005, которые существуют на трех уровнях:

• на уровне операционной системы Windows:

· логин для доменной учетной записи Windows (Windows Domain login) — учетная запись, созданная на уровне SQL Server 2005 для подключения от имени учетной записи Windows. Чтобы отличать доменные учетные записи от учетных записей Windows, в этой книги первые будут называться логинами (как обычно они и называются на предприятиях);

· логин для локальной учетной записи Windows (Windows Local login);

• на уровне сервера SQL Server 2005:

· логин SQL Server 2005 (SQL Server login);

• на уровне базы данных:

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

· роль базы данных (database role);

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

Securables (дословно "защищаемые") — еще одна важнейшая концепция системы безопасности SQL Server 2005. Это все, на что в SQL Server 2005 можно назначить разрешения. Они также относятся к трем уровням SQL Server 2005, но уровни другие:

• на уровне сервера SQL Server:

· логин (теперь можно одному пользователю SQL Server 2005 предоставить разрешения на объект другого пользователя);

· база данных;

· точка подключения (endpoint), т. е. можно предоставить разрешения на точки подключения по HTTP;

• на уровне базы данных:

· пользователь;

· роль;

· роль приложения;

· сборка;

· тип сообщения;

· маршрут;

· служба;

· привязка удаленной службы;

· полнотекстовый каталог;

· сертификат;

· асимметричный ключ;

· симметричный ключ;

· контракт;

· схема;

• на уровне схемы:

· таблица;

· представление;

· функция;

· процедура;

· ограничение целостности;

· очередь;

· статистика;

· пользовательский тип данных;

· синоним;

· агрегат;

· коллекция схем XML.

Как вы видите, в SQL Server 2005 появилось множество новых объектов, на которые можно предоставлять разрешения.

В большинстве случаев процесс предоставления разрешений выглядит очень просто:

1. Создать логин — учетную запись для подключения к SQL Server.

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

3. Предоставить пользователю необходимые разрешения.

33. Применение агрегатных функций и вложенных запросов в операторе выбора.

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

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

MIN/MAX: Возвращает минимальное/максимально значение выражения.

Синтаксис: MIN/MAX([ALL|DISTINCT] expression)

Аргументы:

ALL - Применяет статистическую функцию ко всем значениям. Параметр ALL установлен по умолчанию.

DISTINCT - Указывает, что учитывается каждое уникальное значение. DISTINCT не имеет смысла с функцией MIN и доступен только в целях совместимости с SQL-92.

expression - Может быть константой, именем столбца, функцией или любым сочетанием арифметических, логических и строковых операторов. Функция MIN может использоваться со столбцами числовых типов, а также типов char, varchar, datetime, но не со столбцами типа bit. Статистические функции и вложенные запросы запрещены.

Типы возвращаемых данных - Возвращает то же значение, что и expression.

AVG: Возвращает среднее арифметическое группы значений. Значения NULL пропускаются.

Синтаксис: AVG([ALL|DISTINCT] expression)

Аргументы:

ALL - Применяет статистическую функцию ко всем значениям. ALL является параметром по умолчанию.

DISTINCT - Указывает на то, что функция AVG будет выполнена только для одного экземпляра каждого уникального значения, независимо от того, сколько раз встречается это значение.

expression - Выражение, принадлежащее к категории точных или приблизительных числовых типов данных, за исключением типа данных bit. Статистические функции и вложенные запросы несовместимы.

Типы возвращаемых данных - Возвращаемый тип определяется типом вычисленного результата expression.

COUNT: Возвращает количество элементов в группе. Функция COUNT работает как функция COUNT_BIG. Единственное различие между двумя функциями — возвращаемые значения. Функция COUNT всегда возвращает значение типа int. Функция COUNT_BIG всегда возвращает значение типа данных bigint.

Синтаксис: COUNT ({[[ALL|DISTINCT]expression]|*})

Аргументы:

ALL - Применяет статистическую функцию ко всем значениям. ALL применяется по умолчанию.

DISTINCT - Указывает, что функция COUNT возвращает количество уникальных значений, не равных NULL.

expression - Выражение любого типа, за исключением text, image или ntext. Статистические функции и вложенные запросы запрещены.

* - Указывается, что при возврате общего числа строк в таблице необходимо посчитать все строки. Функция COUNT(*) не принимает аргументы и не может использоваться с ключевым словом DISTINCT. Для функции COUNT(*) не нужен аргумент expression, так как по определению она не использует сведения о каких-либо конкретных столбцах. Функция COUNT(*) возвращает количество строк в указанной таблице, не отбрасывая дублированные строки. Подсчитывает каждую строку отдельно. При этом учитываются и строки, содержащие значения NULL.

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

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

GROUP BY: Задает группы, в которые должны быть помещены строки вывода. Если в предложение SELECT <список выбора> включены статистические функции, инструкция GROUP BY вычисляет сводные значения для каждой группы. Если задано предложение GROUP BY, либо каждый столбец во всех нестатистических выражениях в списке выбора должен включаться в список GROUP BY, либо выражение GROUP BY должно точно соответствовать выражению списка выбора.

Синтаксис:

GROUP BY [ ALL ] group_by_expression [ ,...n ]

    [ WITH { CUBE | ROLLUP } ]

34. Возможности объединения таблиц.

Достаточно интересно то, что та же самая методика может использо-

ваться чтобы объединять вместе две копии одиночной таблицы. В этой

главе, мы будем исследовать этот процесс. Как вы видете, объединение

таблицы с самой собой, далеко не простая вещь, и может быть очень по-

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

данных в конкретной таблице.

========= КАК ДЕЛАТЬ ОБЪЕДИНЕНИЕ ==========

ТАБЛИЦЫ С СОБОЙ ?

Для объединения таблицы с собой, вы можете сделать каждую строку

таблицы, одновременно, и комбинацией ее с собой и комбинацией с каждой

другой строкой таблицы. Вы затем оцениваете каждую комбинацию в терми-

нах предиката, также как в обьединениях мультитаблиц. Это позволит вам

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

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

ем поля, например.

Вы можете изобразить обьединение таблицы с собой, как обьединение

двух копий одной и той же таблицы. Таблица на самом деле не копирует-

ся, но SQL выполняет команду так, как если бы это было сделано. Други-

ми словами, это обьединение - такое же, как и любое другое обьединение

между двумя таблицами, за исключением того, что в данном случае обе

таблицы идентичны.

ПСЕВДОНИМЫ

Синтаксис команды для объединения таблицы с собой, тот же что и для

объединения многочисленых таблиц, в одном экземпляре. Когда вы объеди-

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

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

вы должны иметь два различных имени для этой таблицы.

Вы можете сделать это с помощью определения временных имен называе-

мых переменными диапазона, переменными корреляции или просто - псевдо-

нимами. Вы определяете их в предложении FROM запроса. Это очень прос-

то: вы набираете имя таблицы, оставляете пробел, и затем набираете

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

имеющих один и тот же самый рейтинг (вывод показывается в Рисунке

9.1):

SELECT first.cname, second.cname, first.rating

FROM Customers first, Customers second

WHERE first.rating = second.rating;

В вышеупомянутой команде, SQL ведет себя так, как если бы он соеди-

нял две таблицы называемые 'первая' и 'вторая'. Обе они - фактически,

таблицы Заказчика, но псевдонимы разрешают им быть обработаными неза-

висимо. Псевдонимы первый и второй были установлены в предложении FROM

запроса, сразу после имени копии таблицы. Обратите внимание что псев-

донимы могут использоваться в предложении SELECT, даже если они не оп-

ределены в предложении FROM.

Это - очень хорошо. SQL будет сначала допускать любые такие псевдо-

нимы на веру, но будет отклонять команду если они не определены далее

в предложении FROM запроса.

Псевдоним существует - только пока команда выполняется ! Когда зап-

рос заканчивается, псевдонимы используемые в нем больше не имеют ника-

кого значения.

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

ними, SQL может обрабатывать эту операцию точно также как и любое дру-

гое обьединение - берет каждую строку из одного псевдонима и сравнива-

ет ее с каждой строкой из другого псевдонима.

УСТРАНЕНИЕ ИЗБЫТОЧНОСТИ

Обратите внимание что наш вывод имеет два значение для каждой комби-

нации, причем второй раз в обратном порядке. Это потому, что каждое

значение показано первый раз в каждом псевдониме, и второй раз( сим-

метрично) в предикате. Следовательно, значение A в псевдониме сначала

выбирается в комбинации со значением B во втором псевдониме, а затем

значение A во втором псевдониме выбирается в комбинации со значением B

в первом псевдониме. В нашем примере, Hoffman выбрался вместе с Cle-

mens, а затем Clemens выбрался вместе с Hoffman. Тот же самый случай с

Cisneros и Grass, Liu и Giovanni, и так далее. Кроме того каждая стро-

ка была сравнена сама с собой, чтобы вывести строки такие как - Liu и

Liu. Простой способ избежать этого состoит в том, чтобы налагать поря-

док на два значения, так чтобы один мог быть меньше чем другой или

предшествовал ему в алфавитном порядке. Это делает предикат ассимет-

ричным, поэтому те же самые значения в обратном порядке не будут выб-

раны снова, например:

SELECT tirst.cname, second.cname, first.rating

FROM Customers first, Customers second

WHERE first.rating = second.rating

AND first.cname < second.cname;

Hoffman предшествует Periera в алфавитном порядке, поэтому комбина-

ция удовлетворяет обеим условиям предиката и появляется в выводе. Ког-

да та же самая комбинация появляется в обратном порядке - когда Perie-

ra в псевдониме первой таблицы сравнтвается с Hoffman во второй табли-

це псевдонима - второе условие не встречается. Аналогично Hoffman не

выбирается при наличии того же рейтинга что и он сам потому что его

имя не предшествует ему самому в алфавитном порядке. Если бы вы захо-

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

могли бы просто использовать < = вместо <.

ПРОВЕРКА ОШИБОК

Таким образом мы можем использовать эту особенность SQL для проверки

определенных видов ошибок. При просмотре таблицы Порядков, вы можете

видеть что поля cnum и snum должны иметь постоянную связь. Так как

каждый заказчик должен быть назначен к одному и только одному продав-

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

Порядков, он должен совпадать с таким же номером продавца. Следующая

команда будет определять любые несогласованности в этой области:

SELECT first.onum, tirst.cnum, first.snum,

second.onum, second.cnum,second.snum

FROM Orders first, Orders second

WHERE first.cnum = second.cnum

AND first.snum < > second.snum;

Хотя это выглядит сложно, логика этой команды достаточно проста. Она

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

псевдонимом, и проверять ее в комбинации с каждой строкой таблицы По-

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

удовлетворяет предикату, она выбирается для вывода. В этом случае пре-

дикат будет рассматривать эту строку, найдет строку где поле cnum=2008

а поле snum=1007, и затем рассмотрит каждую следующую строку с тем же

самым значением поля cnum. Если он находит что какая -то из их имеет

значение отличное от значения поля snum, предикат будет верен, и выве-

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

с данным значением cnum в наш таблице совпадает, эта команда не произ-

ведет никакого вывода.

БОЛЬШЕ ПСЕВДОНИМОВ

Хотя обьединение таблицы с собой - это первая ситуация когда понятно

что псевдонимы необходимы, вы не ограничены в их использовании что бы

только отличать копию одлной таблицы от ее оригинала. Вы можете ис-

пользовать псевдонимы в любое время когда вы хотите создать альтерна-

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

имеют очень длинные и сложные имена, вы могли бы определить простые

односимвольные псевдонимы, типа a и b, и использовать их вместо имен

таблицы в предложении SELECT и предикате. Они будут также использо-

ваться с соотнесенными подзапросами(обсуждаемыми в Главе 11).

ЕЩЕ БОЛЬШЕ КОМПЛЕКСНЫХ ОБЪЕДИНЕНИЙ

Вы можете использовать любое число псевдонимов для одной таблицы в

запросе, хотя использование более двух в данном предложении SELECT *

будет излишеством. Предположим что вы еще не назначили ваших заказчи-

ков к вашему продавцу. Компании должна назначить каждому продавцу пер-

воначально трех заказчиков, по одному для каждого рейтингового значе-

ния. Вы лично можете решить какого заказчика какому продавцу назна-

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

комбинации заказчиков которых вы можете назначать. ( Вывод показывает-

ся в Рисунке 9.3 ):

SELECT a.cnum, b.cnum, c.cnum

FROM Customers a, Customers b, Customers c

WHERE a.rating = 100

AND b.rating = 200

AND c.rating = 300;

Как вы можете видеть, этот запрос находит все комбинации заказчиков

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

ков с оценкой 100, второй с 200, и последний с оценкой 300. Они повто-

ряются во всех возможных комбинациях. Это - сортировка группировки ко-

торая не может быть выполнена с GROUP BY или ORDER BY, поскольку они

сравнивают значения только в одном столбце вывода.

Вы должны также понимать, что не всегда обязательно использовать

каждый псевдоним или таблицу которые упомянуты в предложении FROM зап-

роса, в предложении SELECT. Иногда, предложение или таблица становятся

запрашиваемыми исключительно потому что они могут вызываться в преди-

кате запроса. Например, следующий запрос находит всех заказчиков раз-

мещенных в городах где продавец Serres ( snum 1002 ) имеет заказиков (

вывод показывается в Рисунке 9.4 ):

SELECT b.cnum, b.cname

FROM Customers a, Customers b

WHERE a.snum = 1002

AND b.city = a.city;

Псевдоним a будет делать предикат неверным за исключением случая

когда его значение столбца snum = 1002. Таким образом псевдоним опус-

кает все, кроме заказчиков продавца Serres. Псевдоним b будет верным

для всех строк с тем же самым значением города что и текущее значение

города для a; в ходе запроса, строка псевдонима b будет верна один раз

когда значение города представлено в a. Нахождение этих строк псевдо-

нима b - единственая цель псевдонима a, поэтоиму мы не выбираем все

столбцы подряд. Как вы можете видеть, собственные заказчики Serres вы-

бираются при нахождении их в том же самом городе что и он сам, поэтому

выбор их из псевдонима a необязателен. Короче говоря, псевдоним назхо-

дит строки заказчиков Serres, Liu и Grass. Псевдоним b находит всех

заказчиков размещенных в любом из их городов ( San Jose и Berlin соот-

ветственно ) включая, конечно, самих - Liu и Grass.

Вы можете также создать обьединение которое включает и различные

таблицы и псевдонимы одиночной таблицы. Следующий запрос объединяет

таблицу Пользователей с собой: чтобы найти все пары заказчиков обслу-

живаемых одним продавцом. В то же самое время, этот запрос объединяет

заказчика с таблицей Продавцов с именем этого продавца ( вывод показан

на Рисунке 9.5 ):

SELECT sname, Salespeople.snum, first.cname

second.cname

FROM Customers first, Customers second, Salespeople

WHERE first.snum = second.snum

AND Salespeople.snum = first.snum

AND first.cnum < second.cnum;

35. Средства обеспечения целостности.

Общее правило целостности, свойственные любой БД:

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

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

Применительно к целостности рассматривают 2 категории:

А) целостность сущности – каждая запись любого отношения должна отличаться от записи другого отношения

Б) целостность ссылок – для каждого значения внешнего ключа появляющегося в дочернем отношении должно существовать соответствующее значение первичного ключа в родительном отношении

Обеспечение целостности дает:

1.улучшение качества данных

2.улучшение разработки

3.меньшее число ошибок

Главное средство обеспечение доменной целостности в SQL Server - это ограничения.

Ограничения целостности – это некоторое утверждение которое может быть истинным или ложным в зависимости от состояния БД. Различают следующие ограничения:

1. CHECK – логическое условие, при выполнении которого разрешается вставка определенного значение.

2. NULL – значение не определено.

3. DEFAULT – обеспечивает ввод информации по умолчанию. Возможно использование констант, различных выражений и функций.

4. UNIQUE – для гарантирования уникальности значений в различных столбцах возможно ограничение целостности с помощью UNIQUE. Допускает значение типа null.

5. PRIMARY KEY - первичный ключ – множество атрибутов задания значений, которые позволяет однозначно определить значение других атрибутов записи. Не допустимо использование null.

6. FOREIGH KEY – внешний ключ – автоматически контролирует правильности вводимых значений в подчиненной таблице. Если значение внешнего ключа найдено в соответствующей род.таблице, то операция разрешается.

7. NO ACTION AND CASCADE – позволяет контролировать удаление или изменение данных.

NO ACTION .Не требует никаких действий в связанных таблицах.

CASCADE. Обеспечивает каскадное изменение в связанных таблицах.

36. Проблемы стандартизации SQL. SQL. T-SQL.

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

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

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

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

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

Для поставщиков СУБД стандарт – это путеводная звезда, которая гарантирует правильное направление работ. А вот эффективность реализации стандарта - это гарантия успеха.

37. Встроенные математические функции.

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

-CEILING(x) - возвращает наименьшее целое значение, не превышающее значения аргумента x.

-EXP(x) - возвращает значение экспоненциальной функции (ex).

-FLOOR(x) - возвращает наибольшее целое значение, не превышающее значение аргумента x.

-LOG(x) - возвращает значение натурального логарифма аргумента х.

-LOG10(x) - возвращает значение десятичного логарифма аргумента х.

-MOD(x,y) - возвращает остаток от деления нацело х на у.

-SIN(x) - возвращает тригонометрический синус аргумента х.

Аргумент задается в радианах.

-SQRT(x) - возвращает положительный квадратный корень из неотрицательного числа х.

-RAND([начальное_число]) - возвращает псевдослучайное число в интервале от 0 до 1. Аргумент функции инициализирует генератор псевдослучайных чисел. Если аргумент отсутствует, используется значение системных часов.

-ROUND(x[,d]) - возвращает значение аргумента (числа с плавающей запятой) х, округленное до d десятичных разрядов (если d не указано, число округляется до целого числа.

-TAN(x) - возвращает тригонометрический тангенс аргумента х.

-TRANCATE(число, точность) - усекает число до требуемой точности.

38. Алгоритм функционирования SQL.

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

1. Рассмотрите строку таблицы.

2. Выполните проверку - является ли эта строка одной из строк, которая вам нужна.

3. Если это так, сохраните ее где-нибудь, пока вся таблица не будет проверена.

4. Проверьте, имеются ли другие строки в таблице.

5. Если имеются, возвратитесь на шаг 1.

6. Если строк больше нет, вывести все значения, сохраненные в шаге 3.

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

39. Встроенные строковые функции.

Описанные ниже функции принимают строки в качестве аргументов либо возвращают строки.

BIN(целое) - функция возвращает двоичное представление заданного целого числа.

SELECT BIN(13) ->1101,

BINARY строка - объявляет строку двоичной, т.е. операции сравнения с ней будут чувствительны к регистру. Это слово имеет более высокий приоритет, чем операторы сравнения. SELECT 'a'='A', BINARY 'a'='A' 1 0

CONCAT(str1,str2,:) ? возвращает строку, созданную путем объединения (конкатенации) аргументов. Если какая-либо строка содержит NULL, то и результат будет равен NULL. CONCAT("Иванов","Василий") => ИвановВасилий

INSERT(строка, позиция, длина, подстрока) - вставляет подстроку в строку, начиная с позиции. Длина показывает, сколько символов в строке может быть удалено, начиная с позиции. INSERT("Паразитолог",5,3,"псих")

INSTR(str, substr) ? возвращает номер позиции первого вхождения подстроки substr в строку str.

INSTR("Пароход", "ох") =>4

LEFT(str, len) ? возвращает len левых крайних символов из строки str.

LEFT("Пароход", 3) => Пар

LENDTH(str) - возвращает количество байтов (символов) в строке str.

LENDTH("Пароход") => 7

LPAD(str, len, pad_str), RPAD(str, len, pad_str) ? дополняет слева (справа) строку str до длины len строкой-заполнителем pad_str.

LPAD("Пушкин", 20, "Ива") => ИваИваИваИваИвПушкин

LTRIM(str) ? возврашает подстроку после удаления из нее начальных пробелов.

LTRIM("Пушкин") => Пушкин

POSITION(подстрока IN строка) - определяет позицию вхождения подстроки в строку.

REPEAT(строка, счетчик) - возвращает строку, состоящую из строки, повторенной счетчик раз.

REPLACE(str,str1,str2) ? возвращает строку str после замены подстроки str1 подстрокой str2 в строке str.

RTRIM(str) - возвращает подстроку после удаления из нее конечных пробелов.

SPACE(n) ? возвращает строку из n пробелов.

TRIM([:] строка) - удаляет из строки начальные и конечные пробелы.

40. Декомпозиция плоской таблицы.

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

41. Функции даты и времени.

CURDATE(), CURRENT_DATE - каждая из функций возвращает текущую дату. Вторая функция в скобках не нуждается.

CURTIME(), CURRENT_TIME - возвращает текущее время.

DATE_ADD(дата, INTERVAL значение тип) ? возвращает новую дату после добавления интервала времени к значению даты (возможные значения параметра тип - YEAR, DAY, MONTH, HOUR, SECOND, :).

DATE_ADD(NOW(), INTERVAL 15 DAY)

DAYNAME(дата) - возвращает название дня недели по дате.

DAYOFMONTH(дата) - возвращает числовое значение дня месяца по дате.

DAYOFWEEK(дата) - возвращает номер дня недели по дате. Первым днем недели считается воскресенье.

DAYOFYEAR(дата) - возвращает числовое значение дня года по дате.

HOUR(время) - возвращает номер часа по времени.

MONTH(дата) - возвращает номер месяца года по дате.

NOW() - возвращает текущие дату и время.

SELECT NOW() => 2003-10-21 12:10:15

QUARTER(дата) - определяет квартал года. Первый квартал - первые три месяца года.

SYSDATE() - синоним функции NOW().

YEAR(дата) - возвращает номер года по дате.

WEEKDAY(дата) - возвращает номер дня недели по дате.

42. Операция условного соединения.

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

Пусть R =r, Q = q- исходные отношения, SR, SQ - схемы отношений R и Q, соответственно.

SR = (А1, А2, ... , Аk), SQ = (В1, В2, ... , Вm), где Аi, Вj - имена атрибутов в схемах отношений R и Q, соответственно.

При этом полагаем, что заданы наборы атрибутов А и В. А С- Аi i=1,k; В С- Вj j=1,m ("С-" соединение (эс подчеркнутое) i=1,k j=1,m - нижний регистр) и эти наборы состоят из (тетта) -сравнимых атрибутов.

Тогда соединением отношений R и Q при условии (бетта) будет подмножество декартова произведения отношений R и Q, кортежи которого удовлетворяют условию ?, рассматриваемому как одновременное выполнение условий: - r.Аi (тетта)i q.Вi : i=1,k, где k - число атрибутов, входящих в наборы А и В, а (тетта)i - конкретная операция сравнения.

-Аi (тетта)i Вi D; (тетта)i - i-й предикат сравнения, определяемый из множества допустимых на домене Di операций сравнения.

R [ ? ] Q = (r, q) | r.Аi (тетта)i q.Bi = "Истина", i=1,k

43. Преимущества и недостатки MSSQL.

Независимость от конкретной СУБД

Несмотря на наличие диалектов и различий в синтаксисе, в большинстве своём тексты SQL-запросов, содержащие DDL и DML, могут быть достаточно легко перенесены из одной СУБД в другую. Существуют системы, разработчики которых изначально ориентировались на применение по меньшей мере нескольких СУБД (например: система электронного документооборота Documentum может работать как с Oracle, так и с Microsoft SQL Server и IBM DB2). Естественно, что при применении некоторых специфичных для реализации возможностей такой переносимости добиться уже очень трудно.

Наличие стандартов

Наличие стандартов и набора тестов для выявления совместимости и соответствия конкретной реализации SQL общепринятому стандарту только способствует «стабилизации» языка. Правда, стоит обратить внимание, что сам по себе стандарт местами чересчур формализован и раздут в размерах (например, Core-часть стандарта SQL:2003 представляет собой более 1300 страниц текста).

Декларативность

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

Недостатки

Несоответствие реляционной модели данных

Создатели реляционной модели данных Эдгар Кодд, Кристофер Дейт и их сторонники указывают на то, что SQL не является истинно реляционным языком. В частности, они указывают на следующие проблемы SQL[3]:

* Повторяющиеся строки

* Неопределённые значения (nulls)

* Явное указание порядка колонок слева направо

* Колонки без имени и дублирующиеся имена колонок

* Отсутствие поддержки свойства «=»

* Использование указателей

* Высокая избыточность

В опубликованном Кристофером Дейтом и Хью Дарвеном Третьем Манифесте[4] они излагают принципы СУБД следующего поколения и предлагают язык Tutorial D, который является подлинно реляционным.

Сложность

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

Отступления от стандартов

Несмотря на наличие международного стандарта ANSI SQL-92, многие компании, занимающиеся разработкой СУБД (например, Oracle, Sybase, Microsoft, MySQL AB), вносят изменения в язык SQL, применяемый в разрабатываемой СУБД, тем самым отступая от стандарта. Таким образом, появляются специфичные для каждой конкретной СУБД диалекты языка SQL.

Сложность работы с иерархическими структурами

Ранее диалекты SQL большинства СУБД не предлагали способа манипуляции древовидными структурами. Некоторые поставщики СУБД предлагали свои решения (например, Oracle использует выражение CONNECT BY). В настоящее время в ANSI стандартизована рекурсивная конструкция WITH из диалекта SQL DB2. В MS SQL Server рекурсивные запросы появились лишь в версии MS SQL Server 2005. В версии MS SQL Server 2008 появился новый тип данных — hierarchyid, упрощающий манипуляцию древовидными структурами.

44. Операция проектирования.

Результат операции достигается в 2 шага – вычеркивание лишних полей, вычеркивание повторяющихся записей.

Проекцией отношения R на набор атрибутов В, обозначаемой R[В], называется отношение со схемой, соответствующей набору атрибутов В SR[B] = В, содержащее кортежи, получаемые из кортежей исходного отношения R путем удаления из них значений, не принадлежащих атрибутам из набора

R[В] = {r[B]}

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

-в исходном отношении (таблице) удаляются все столбцы, которые не входят в множество необходимых атрибутов,

-в оставшейся части таблицы удаляются (вычеркиваются) все повторяющиеся записи (строки, кортежи).

45. Правила оформления программного кода.

-комментарии

-структурированность

-выделение блоков информации

46. Операция фильтрации.

Иначе, операция горизонтальный выбор или операция ограничения отношений. Для определения этой операции необходимо ввести дополнительные обозначения.

Пусть а - булевское выражение, составленное из термов (выражений) сравнения с помощью связок И (л), ИЛИ (v), НЕ (-) и, возможно, скобок. В качестве термов сравнения допускаются:

а) терм А ос а,

где А - имя некоторого атрибута, принимающего значения из домена D; а - константа, взятая из того же домена D, aЄD, ос - одна из допустимых для данного домена D операций сравнения;

б) терм А ос В,

где А, В - имена некоторых (тетта)-сравнимых атрибутов, то есть атрибутов, принимающих значения из одного и того же домена D.

Тогда результатом операции фильтрации, или выбора, заданной на отношении R в виде булевского выражения, определенного на атрибутах отношения R, называется отношение R[a], включающее те кортежи из исходного отношения, для которых истинно условие выбора или фильтрации:

R[a(r)] = {r | г Є R л a(r) = "Истина"} (а- альфа)

47. Команды создания баз данных, таблиц и индексов.

Инструкция создает базу данных. Синтаксис инструкции:

CREATE DATABASE [IF NOT EXISTS] имя_БД

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

CREATE TABLE

Инструкция предназначена для создания таблиц. Это одна из наиболее сложных SQL-инструкций. Формат:

CREATE TABLE [TEMPORARY][IF NOT EXIST] имя

[(спецификация, ...)]

[опция:]

[[IGNORE | REPLACE] запрос]

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

IF NOT EXIST подавляет вывод сообщений об ошибках в случаях, если таблица с указанным именем уже существует.

Спецификации столбцов и индексов приводятся в круглых скобках и разделяются запятыми.

Спецификация имеет следующий формат:

столбец тип [NOT NULL | NULL]

[DEFAULT значение]

[AUTO INCREMENT]

[PRIMARY KEY]

[ссылка]

Спецификация типа включает название типа и его размерность. У любого столбца есть значение по умолчанию, которое задается явно с помощью предложения DEFAULT или выбирается MySQL автоматически. Поля-счетчики, создаваемые с помощью AUTO_INCREMENT, игнорируют значения по умолчанию, т.к. в них записываются порядковые номера. Тип счетчика должен быть беззнаковым целым.

Спецификация PRIMARY KEY позволяет назначить столбец первичным ключом. При этом для столбца будет создан индекс.

CREATE INDEX

Инструкция добавляет индекс к заданной таблице. Формат

CREATE [UNIQUE | FULLTEXT] INDEX имя

ON таблица (столбец [(длина)], :)

UNIQUE создает индекс с уникальным значением по таблице имя

48. Декартово произведение.

Сцеплением, или конкатенацией, кортежей с = <С1, ..., Сn> и q = <q1, ..., qm> называется кортеж, полученный добавлением значений второго в конец первого. Сцепление кортежей с и q обозначается как (с, q).

(С, q) = <С1, С2, ... ,Сn, q1, q2, ..., qm>

Здесь n - число элементов в первом кортеже с, m - число элементов во втором кортеже q.

Все предыдущие операции не меняли степени или арности отношений - это следует из определения эквивалентности схем отношений. Операция декартова произведения меняет степень результирующего отношения.

Расширенным декартовым произведением отношения R1 степени n со схемой

SR1 = (А1, А2, ... , Аn) и отношения R2 степени m со схемой SR2 = (B1, B2, ..., Вm) называется отношение Rз степени n+m со схемой

SR3 = (A1, А2, ... , Аn, В1, В2, ..., Вm), содержащее кортежи, полученные сцеплением каждого кортежа r отношения R1 с каждым кортежем q отношения R2.

То есть, если R1 = { r }, R2 = { q }, то R1 х R2 = {(r, q) | г Є R1 л q Є R2}

Операцию декартова произведения с учетом возможности перестановки атрибутов в отношении можно считать симметричной.

49. Команды изменения таблиц.

ALTER TABLE

Эта инструкция позволяет менять определение таблицы. Для выполнения команды необходимо наличие привилегий ALTER, CREATE, INSERT. Общий формат команды

ALTER [IGNORE] TABLE имя_табл спецификация [,спецификация ...]

где спецификация:

ADD [COLUMN] определение [FIRST | AFTER столбец] or CHANGE [COLUMN] столбец определение or ALTER [COLUMN] столбец { SET DEFAULT значение | DROP DEFAULT } or

DROP [COLUMN] столбец or DROP PRIMARY KEY or DROP INDEX индекс

Команда ALTER TABLE может быть использована для изменения определения таблицы. ALTER TABLE работает с временно созданной таблицей в которую копирует все данные из текущей таблицы.

INSERT

Инструкция добавляет записи в таблицу. Ее синтаксис:

INSERT [LOW_PRIORITY | DELAYED] [IGNORE]

[INTO] таблица [(столбец, :)]

{VALUES (значение, :),(:), : | запрос | SET столбец=значение, :}

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

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

50. Разность отношений.

Разностью отношений R1 и R2 называется отношение, содержащее множество кортежей, принадлежащих R1 и не принадлежащих R2

R5 = R1 \ R2 = {r | r Є R1 п r ё R2} ("Є"- принадлежит, ё-не приналдежит)

51. Система репликации.

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

Назначение репликации состоит в управляемом тиражировании данных между несколькими СУБД. Задача эта не нова, и поэтому в репликации используется давно всем известная метафора издательского дела: издатель, публикация, статья, распространитель и подписчик. Для SQL Server характерно также наличие специализированных программных модулей, с помощью которых организуется взаимодействие задействованных в репликации баз данных, и которые в документации принято называть агентами репликации.