Представление может использоваться для улучшения защиты, для вывода дополнительной информации, для сокрытия сложных запросов (конкретное использование рассматривается в специальной литературе).
Обеспечение целостности данных.
Очень важно, чтобы была обеспечена целостность информации базы данных, то есть чтобы данные были, согласно некоему набору правил, допустимыми. Реляционная модель описывает некоторые характерные правила, которые можно ввести для обеспечения в реляционной базе данных целостности данных. Это - ограничение домена, ограничение таблицы и ссылочное ограничение. Правила целостности поясняют следующие понятия.
Целостность домена: каждое значение поля должно быть элементом домена.
Целостность домена гарантирует, что база данных не содержит бессмысленных значений. Она обеспечивает то, что значение в столбце является элементом домена столбца, то есть допустимого множества его значений. Строка не будет включена в таблицу, пока каждое из значений ее столбцов не будет находиться в домене соответствующего столбца.
Задание целостности домена осуществляется с помощью типов данных. Запись данных не может быть включена в таблицу, пока данные в каждом столбце не будут иметь корректный тип.
Все типы данных ORACLE7 позволяют разработчикам описывать тот или иной тип столбца. Можно ввести дальнейшие ограничения домена столбца. Например, тип данных NUMBER позволяет определить точность (общее число значащих цифр) и масштаб (общее число цифр справа или слева от десятичной точки), и тому подобное (более полное описание можно получить в справочном руководстве).
Целостность вcей таблицы: обеспечение уникальности каждой строки.
Другим встроенным ограничением целостности данных является целостность всей таблицы, которая означает, что каждая строка в таблице должна быть уникальной. Если таблица имеет такое ограничение, то вы можете уникальной. Если таблица имеет такое ограничение, то вы можете уникально идентифицировать каждую ее строку .
Чтобы задать целостность всей таблицы, разработчик указывает в таблице столбец или группу столбцов, определяя их как первичный ключ. Уникальное значение первичного ключа должно содержаться в каждой строке таблицы. Неявно это означает, что каждая строка таблицы должна иметь первичный ключ, поскольку отсутствие значение, то есть NULL, не будет отличаться от других значений NULL.
Таблица может иметь только один первичный ключ. ВО многих случаях разработчикам требуется устранить дублирующие значения и из других столбцов. Для этого разработчик может выделить другой ключевой столбец - задать альтернативный или уникальный ключ. Как и в основном ключе, дублирующих значений в альтернативном ключе таблица содержать не может.
Ограничения целостности позволяют легко задать целостность таблицы, и всей базы данных в целом. Так как разработчики могут описывать стандартные правила целостности как часть определения таблицы, использовать такие ограничения целостности несложно. Приведем примеры операторов задающих ограничения целостности, на примере базы данных, состоящей из двух таблиц.
CREATE TABLE customer
(id NUMBER(5,0) PRIMARY KEY,
lastname CHAR(50) NOT NULL,
firstname CHAR(50) NOT NULL,
phone CHAR(20),
UNIQUE (lastname,firstname),
CHECK (state IN
(‘AL’,’AK’,’AZ’,’OH’,’SC’,’WV’))) --сокращенные названия штатов
CREATE TABLE orders
(customerid NUMBER(5,0) NOT NULL,
orderdate DATE NOT NULL,
shipdate DATE
status CHAR(1),
CHECK (status IN (‘F’,’B’)), --F—оплачено, В—долг
FOREIGN KEY (customerid) REFERENCES customer)
В данном примере ограничения NOT NULL, CHECK позволяют задать в таблице ограничения домена. Для определения первичного ключа и задания ограничений целостности таблицы разработчик должен описать целостность таблицы с помощью PRIMARY KEY. Для таблицы customer описывается также ограничение UNIQUE, которое обеспечивает уникальность имен/фамилий покупателей.
Ссылочная целостность: обеспечение синхронизации связанных таблиц.
Ссылочная целостность или целостность отношения - еще одно элементарное правило целостности реляционной модели. Ссылочная целостность определяет соотношения между различными столбцами и таблицами в реляционной базе данных. Такое название она получила, поскольку значения в одном столбце или наборе столбцов ссылаются на значения другого столбца или набора столбцов, либо должны совпадать с ними.
При описании ссылочной целостности встретятся новые термины. Столбец, от которого зависит другая таблица, называется внешним ключем. При этом другая таблица, называется родительским ключем (это должен быть первичный или уникальный ключ). Внешний ключ находится в дочерней или детальной таблице, а родительский ключ - в основной таблице.
Возможность связывать значения в различных таблицах и поддерживать отношения ссылочной целостности - это очень важная характеристика реляционных баз данных. Благодаря возможности связывания таблиц серверы реляционных СУБД могут очень эффективно хранить данные.
В приведенном выше примере с помощью ограничения целостности FOREIGN KEY задается ограничение ссылочной целостности , определяющего для таблицы внешний ключ. С помощью этого мы соединяем таблицу orders с родительской таблицей customer.
Деловые правила: специальные правила целостности данных.
До сих пор это были стандартные правила целостности данных, встроенные в реляционную модель данных. Однако в базе данных каждой организации определяется собственный уникальный набор деловых правил, не менее важных чем стандартный набор правил целостности данных. Например, администратор, отвечающий за вопросы защиты, может запретить изменение таблицы вне обычного рабочего времени либо получать значение столбца, когда пользователь вставляет или обновляет запись.
Для задания специальных правил ORACLE7 предлагает использовать хранимые процедуры или триггеры. Для полного представления о задании специальных правил надо обратиться к справочным материалам.
7.3. Управление доступом к данным в многопользовательской СУБД.
Так как к базе данных должны обращаться много пользователей, то СУБД должна обеспечивать множественный доступ к базе данных. К сожалению, однопользовательские СУБД не подходят для коллективной работы. Рассмотрим проблему взаимного влияния на примере картотеки. Вы хотите использовать ту же информацию с которой в данный момент работает кто-то еще. Если вы хотите увидеть результаты работы другого пользователя, то придется подождать. Если же эти результаты на вашу работу не повлияют, вы можете скопировать данные. Возникает неудобство. Картотека иллюстрирует проблемы параллельного доступа, возникающие при попытке нескольких пользователей одновременно работать с базой данных.
В многопользовательских СУБД говорят о проблеме конкуренции — попытках многих пользователей одновременно выполнять операции с одними и теми же данными. Фактически, задача обеспечения параллельного доступа к данным — одна из наиболее важных и наиболее очевидных задач сервера базы данных. Сервер базы данных должен управлять информацией таким образом, чтобы при сохранении целостности данных пользователи ожидали выполнения работы другими пользователями минимальное время. Если сервер базы не может удовлетворить одну из этих целей, то пользователи сразу заметят последствия. Когда многие транзакции конкурируют за одни и те же данные, то пользователи столкнутся с плохой производительностью или получат неточные результаты.
Это проблемы, но ORACLE7 решает эти проблемы. Рассмотрим как это он делает.
Предотвращение разрушающих взаимных влияний с помощью блокировок данных.
Когда две конкурирующие за одни и те же данные операции вмешиваются в работу друг друга, это может привести к неточным результатам или потере целостности данных. Это называется “ разрушающее взаимное влияние”. Для предотвращения таких ситуаций при одновременном доступе пользователей к данным применяются блокировки. Аналогично тому как “вертушка” в проходной не позволяет проходить через нее одновременно двоим, блокировка данных предотвращает в многопользовательской СУБД разрушающее влияние. Существуют исключающие и разделяемые блокировки.
Заперев ячейку камеры хранения на вокзале, вы получаете на нее исключительное право. Никто не сможет в нее положить, пока вы ее не освободите. Если же вы хотите, чтобы этой ячейкой воспользовался ваш знакомый, то сообщаете шрифт. Аналогично блокирует данные и ORACLE7.
Когда пользователь пытается выполнять операции с данными, с которыми работает кто-то еще, ORACLE7 автоматически их блокирует и предотвращает возможность разрушающего влияния. Если это возможно (то есть не приведет к разрушающему влиянию), всегда использует разделяемую блокировку. Однако, если такая блокировка оставляет возможность разрушающего влияния, устанавливается исключающая блокировка запрашиваемых вашей транзакцией данных. Исключающая блокировка предотвращает возможность блокировать те же данные с помощью блокировки любого типа и за счет устранения параллельного доступа к одним и тем же данным обеспечивает их целостность.
Получение точных данных при высокой степени доступа: запросы, согласованное чтение и поддержка версий.
Предыдущие примеры показывают, как Огасlе7 для одного и того набора данных обрабатывает две различные транзакции обновления. А что происходит в случае запросов, содержащих только операции чтения? Как Огaсlе7 обрабатывает конкурирующие запросы и запросы с операциями обновления, возвращая точные результаты ?
В зтих ситуациях Оraсlе7 использует следующий подход. Во-первых, транзакция не требует блокировки строк для любого типа запросов. Это означает , что две транзакции могут давать одновременно в точности один и тот же запрос без какой-либо конкуренции за один набор строк. Отсутствие блокировок чтения означает также, что такой запрос не может блокировать обновления и наоборот.
Как же Огасlе7 возвращает точные результаты, если он не устанавливает блокировки для запросов? Можно было бы полагать, что без блокировки строки для запросов конкурирующее с запросом обновление может дать для запроса неточный набор результатов.