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

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

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

Нули

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

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

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

С точки зрения другого эксперта по реляционным системам. Дейта, нули не являются полноценным решением проблемы пропусков информации. Тем не менее они являются составной частью большинства официальных стандартов SQL и de facto промышленных стандартов. Нули - это настолько важная тема, что мы будем обращаться к ней в нескольких главах. В главе 3 объясняется, как создавать таблицы, в которых в определенных столбцах могут располагаться нул!. В главе 4 мы поговорим об использовании операции выбора применительно к таблицам с нулями. В главе 5 нули рассматриваются в контексте применения функций упорядочивания и агрегирующих функций. В главе 6 обобщается информация, связанная с использованием нулей в системах управления базами данных.

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

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

Эти права устанавливают владельцы (owner) баз данных или объектов баз данных.

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

В многопользовательских системах обычно имеется пользователь с правами даже более высокими, чем у владельца базы данных - системный администратор (system administrator), или администратор базы данных (database adminisnrator). Этот пользователь обычно обладает широкими правами на наделение полномочий, а также выполняет целый ряд других задач, связанных с поддержкой и администрированием базы данных.

В качестве дополнительного механизма обеспечения безопасности могут выступать и виртуальные таблицы. Пользователи могут разрешать доступ только к определенному подмножеству своих данных, включенному в виртуальную таблицу. Виртуальные таблицы рассматриваются в главе 9, операторы GiNT и REVOKE - в главе 10.

Целостность

Целостность (integrity) - очень сложный и серьезный вопрос при управлении реляционными базами данных. Несогласованность между данными может возникать по целому ряду причин. Несогласованность или противоречивость данных может возникать вследствие сбоя системы - проблемы с аппаратным обеспечением, ошибки в профаммном обеспечении или логические ошибки в приложениях. Реляционные системы управления базами данных защищают данные от такого типа несогласованности, гарантируя, что команда SQL либо будет исполнена до конца, либо будет полностью отменена. Этот процесс обычно называют управлением транзакциями (transaction management). Транзакции и связанные с ними методы SQL обсуждаются в главе 10.

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

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

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

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

храниться в словаре данных, а не в профаммных приложениях.

Первоначально только несколько реализаций SQL удовлетворяли критериям Кодда на целостность, но ситуация постепенно изменялась. ANSI-стандарт SQL 1992 года (часто называемый SQL2 ) поддерживает офаничения в операторе CREATE TABLE, обеспечивающие ссылочную целостность и позволяющие задавать бизнес-правила. Эти возможности в том или ином виде реализованы в большинстве систем. Подробно они рассматриваются в главе 3.

ПРИСТУПАЯ К ПРОЕКТИРОВАНИЮ БАЗЫ ДАННЫХ

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

Глава 2

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

СТРУКТУРА БАЗЫ ДАННЫХ

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

таблиц, которые будут входить в базу данных,

столбцов, принадлежаших каждой таблице,

взаимосвязей между таблицами и столбцами.

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

Конструирование баз данных на основе реляционной модели имеет ряд важных преимуществ перед другими моделями.

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

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

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

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

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

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

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