39) Язык er-моделирования. Представление уникальных идентификаторов столбцами-заменителями

Язык ER-моделирования - это язык определения информационной модели ПО. Базируется на концепции, согласно которой информационная модель ПО может быть описана в терминах: сущность, атрибут, связь. Используется на этапе анализа и прежде всего – концептуального моделирования. Язык является существенно графическим.

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

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

Всем уникальным ИД придаются ограничения целостности UNIQUE, NOT NULL.

CREATE TABLE ROUTE ( RoID NUMBER(3)PRIMARY KEY, RoNO NUMBER(5)UNIQUE NOT NULL); CREATE TABLE ROUTE_FLIGHT ( FlID NUMBER(3) PRIMARY KEY, FlDate DATE NOT NULL, FlTime TIME NOT NULL, RoID NUMBER (3) REFERENCES ROUTE, CONSTRAINT unq UNIQUE (FlDate, FlTime, RoID)); CREATE TABLE BOARDING_PASS ( BPID NUMBER(3)PRIMARY KEY, BPDate DATE NOT NULL, BPTime TIME NOT NULL, FlID NUMBER(3) REFERENCES ROUTE_FLIGHT, CONSTRAINT unq2 UNIQUE (BPDate, BPTime, FlID));

40) Защита данных. Определение пользователей и ролей.

Создание пользователей

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

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

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

Создание ролей

Роль - это совокупность привилегий (прав) которые могут предоставляться группам пользователей или другим ролям.

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

Можно присвоить привилегии ролям, а затем «приписывать» пользователей к тем или иным ролям. Когда пользователь отнесен к роли, он получает привилегии этой роли

Предоставление и отмена ролей пользователям или ролям

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

41) Защита данных. Предоставление привилегий на объекты БД

Указывается КТО имеет право выполнять определенные ОПЕРАЦИИ над ОБЪЕКТАМИ БД

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

Отмена привилегий на объекты БД

Команда имеет структуру, аналогичную REVOKE.

Многократно предоставленные привилегии должны быть отменены всеми.

Каскадный эффект при отмене привилегий.

Условия предоставления привилегий

Иногда оказывается полезным специфицировать условия, при выполнении которых пользователям предоставляются указываемые права доступа. Примеры: временные характеристики, например, специфицируемые права доступа действуют только между 16 и 17 часами первого понедельника каждого месяца;

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

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

42) Целостность БД. Целостность связей между таблицами

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

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

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

43) Целостность БД. Динамические ограничения целостности.

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

Другими словами – это ограничения, связанные с переходом базы данных из одного состояние в другое.

Выделяют такие динамические ограничения:

• ситуационно-ориентированные;

• операционно-ориентированные.

Ситуационно-ориентированные динамические ограничения целостности

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

Операционно-ориентированные динамические ограничения целостности

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

Пример операционно-ориентированного ограничения целостности

Пример: Вставка в базу данных информации о том, что х является супругом y допустима только в том случае, если текущее семейное положение x и y не есть женат/замужем

MARRIAGE(Husb, Wife), PERSON(Name, MarSt)

44) Целостность БД. Транзакции как механизм поддержания целостности

Тразакция – это последовательность предложений SQL, которые рассматриваются как единое целое.

Либо все предложения в транзакции выполняются успешно, либо ни одно из них не будет выполнено.

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

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

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

Общая схема транзакции