Представления.

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

Так, естественная, для большинства пользователей, информация о домах должна включать не о введенных нами в целях экономии хранения кодах улиц и городов, но об их реальных названиях, хранящихся в базовых справочных таблицах УЛИЦЫ и ГОРОДА и, конечно, другие атрибуты домов из базовой таблицы ДОМА. В одних случаях, эта информация должна быть полной, включающей атрибуты всех проживающих в этих домах людей, в других - содержать лишь количество проживающих, относится лишь к одному городу и проч.

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

Так, в нашей модели-примере естественно определить представление ДОМА1 – именованном запросе, “хранящем” раскодированную по таблицам ДОМА, УЛИЦЫ и ГОРОДА полную информацию о домах в виде, естественном для пользователя БД, и представление ЛЮДИ1, “содержащую” (с точки зрения пользователя БД) информацию о людях, включающую ссылки на представление ДОМА1 и базовую таблицу ЛЮДИ. В свою очередь, эти представления могут служить базой более конкретных представлений ЖИТЕЛИ_КАЗАНИ и ЖИТЕЛИ_ЦЕНТРА.

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

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

Так, изменение, номера дома в некоторой записи представления ЖИТЕЛИ_ЦЕНТРА в реальности может означать лишь изменение значения дочернего ключа код_дома в таблице ЛЮДИ.[3]

Модификация представления в действительности означает

модификацию данных базовой таблицы

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

Пример неосуществимости модификации представления. Заведем в нашей модели-примере представление, содержащее единственное поле – средний доход людей, информация о которых хранится в таблице БД. Как повысить средний доход – т.е. изменить значения поля доход в таблице ЛЮДИ? Как подсказывает математика (и наш жизненный опыт), решение этой задачи далеко не однозначно.

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

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

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

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

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

Отличие - в явном допущении возможности лишь частичного выполнения.

Основной принцип транзакции - "все или ничего". Сбой при выполнении любой команды ведет к откату – невыполнению всей транзакции.

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

Итак, с точки зрения логики моделирования

База данных =

(Базовые) Таблицы + Отношения + Правила целостности + Представления

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

Почему SQL?

Введение в технологию "клиент-сервер".

Как показывает практика, системы управления баз данных (СУБД) составляют наиболее значительную часть всех используемых программных систем – при этом часть, все более увеличивающуюся в связи с развитием локальных и, особенно, глобальных компьютерных сетей. Язык структурированных запросов SQL (Structured Query Language)[5] фактически играет роль стандарта языка коммуникации сетевых СУБД, часто работающих под управлением различных операционных систем и использующих разные форматы представления информации. "Встроенный" SQL не только является неотъемлемой частью любой современной СУБД, но и любой сколь-нибудь крупной системы программирования, ориентированной на использование технологии "клиент-сервер". Среди прочих достоинств SQL отметим максимальную компактность, обеспечивающую при этом полноценные средства обработки БД и логическую простоту, делающую SQL не только языком программирования, но и неоценимым средством проектирования и функционального описания достаточно больших программных систем. Сказанное объясняет несомненную важность изучения SQL.

Недостатки SQL – обратная сторона его достоинств. Стандартность SQL не идеальна – в действительности, различные СУБД использует отличающиеся диалекты языка, что делает далеко не тривиальным перенос определения и данных БД из одной среды в другую - в частности, т.н. "подъем" (upsizing) БД из локальной среды в сеть. Компактность и декларативность языка, отсутствие в нем традиционных структур управления (циклов, условных операторов и пр.) усложняет переход на SQL программистов, привыкших к процедурному программированию в стиле языков семейства xBase/dBase. В целом, характерный для SQL более абстрактный и высокоуровневый реляционный подход, т.е. взгляд на обработку данных как преобразование таблиц "в целом", сильно отличается по своей логике от характерного для языков этого семейства навигационного подхода - преобразования отдельных записей таблиц.

Цель настоящего пособия скромна - не заменить достаточно богатую "толстую" литературу по SQL и технологиям СУБД в целом, но скорее - подготовить к ее чтению начинающего осваивать эту обширную область, выделив (даже в ущерб если не точности, то полноте изложения) одновременно наиболее существенное и минимально достаточное. Пособие включает краткое теоретическое введение в терминологию реляционных СУБД и технологии "клиент-сервер", синтаксис языка SQL, встроенного в язык MS Visual FoxPro и типовые задания по СУБД. Автор заранее благодарен за все критические замечания и пожелания коллег и студентов, направленные на улучшение данного пособия как по содержанию, так и стилю изложения. Он особенно благодарен Р.Тагирову и В.Байрашевой, уже сделавших ряд ценных предложений подобного рода.

Диаграмма 1. Эволюция сетевых БД.

· Как показывает принятое деление данных на локальные (local), т.е. хранимые на компьютере-клиенте и удаленные (remote), т.е. хранимые на сервере, в рамках этой технологии при необходимости возможно и распределение хранения данных.

Диаграмма 2. Навигационный и реляционный подход к СУБД.

Диаграмма 3. SQL в составе Visual FoxPro.

Сфера приложения FoxPro SQL, в сравнении с другими частями языка

· Во избежание недоразумений - Visual FoxPro не есть объектная или даже смешанная[6] СУБД. Аппарат ООП применяется лишь для обработки оперативных данных.