Проектирование и разработка БД Oracle для информатизации объектов культуры

1. id - первичный ключ.

2. name - наименование типа данных.

3. Usertablename - наименование словаря в котором хранятся значения атрибутов.

4. Oracledatatype - нейтив тип данных БД Oracle.

Таблица Objecttypes содержит в себе следующие поля:

1. id - первичный ключ.

2. Note - наименование объектного типа на русском языке.

3. Name - наименование объектного типа на английском языке.

Рис. 2.3. ER-диаграмма общей архитектуры системных объектов БД.

Ограничения, индексы, представления и синонимы. Коротко рассмотрим процесс генерации с точки зрения создания пользовательских таблиц. Важно то, что на этот момент должны быть созданы системные таблицы Datatypes, Attributes, Objecttypes и Objects, т.к. на их основе как раз и будут создаваться пользовательские таблицы.

Итак, приведу ER-диаграмму объектов, определяющую создание пользовательских таблиц (рис. 2.4).

Коротко опишу структуру объектов рис. 2.4.

Таблица Datatypes содержит в себе следующие поля:

5. id - первичный ключ.

6. name - наименование типа данных.

7. Usertablename - наименование словаря в котором хранятся значения атрибутов.

8. Oracledatatype - нейтив тип данных БД Oracle.

Таблица Objecttypes содержит в себе следующие поля:

4. id - первичный ключ.

5. Note - наименование объектного типа на русском языке.

6. Name - наименование объектного типа на английском языке.

Таблица Attributes содержит в себе следующие поля:

1. id - первичный ключ.

2. idObjectType - id объектного типа атрибута.

3. idDataType - id типа данных атрибута.

4. Length - длина типа данных (только для varchar2).

5. Name - наименование атрибута объектного типа на английском языке.

6. Note - наименование атрибута объектного типа на русском языке.

Таблица Objects содержит в себе следующие поля:

1. id - первичный ключ.

2. idObjectType - id объектного типа к которому принадлежит этот объект.

3. ID_OWNER - id владельца на данный объект. Внешний ключ к таблице Users.

4. ORIGHTS - право владельца на данный объект.

5. ARIGHTS - право всех пользователей кроме владельца на данный объект.

6. Created_user - пользователь, который создал объект.

7. Created_time - время, когда был создан объект.

8. Last_modified_user - пользователь, который последним изменял объект.

9. Last_modified_time - время, когда в последний раз объект изменялся.

Рис. 2.4. ER-диаграмма объектов, участвующих в генерации таблиц.

Для создания пользовательских таблиц был создан пакет generateTables. Код этого пакета приведен в приложении 1. Коротко рассмотрим спецификацию пакета.

SQL> CREATE OR REPLACE PACKAGE generateTables IS

2

3 procedure doGenerate;

4 procedure createParentTables;

5 procedure insertDataParentTables;

6

7 END generateTables;

8 Package created

Таблица 2.1. Комментарии к заголовку пакета generateTables.

Номер строчки кода	Комментарии
3	Процедура doGenerate предназначена для генерации, состоящей из удаления таблиц (если они существуют), создания и вставки значений данных в генерируемые таблицы.
4	Процедура createParentTables предназначена для создания генерируемых таблиц с атрибутами соответвующими объектному типу, для которого создается плоская таблица.
5	Процедура insertDataParentTables предназначена для вставки значений для сгенерированных таблиц.

Небольшие комментарии по реализации тела пакета generateTables:

Таблица 2.2. Комментарии к телу пакета generateTables.

Номера строчек кода	Комментарии
3-19	Процедура dropParentTables предназначена для удаления таблиц (если они существуют) схемы. Обратите внимание, что ее спецификации нету в заголовке пакета generateTables, поэтому она доступна только внутри пакета другим процедурам этого пакета. Создается курсор for curTables IN (select name from objecttypes) LOOP - 7 строка, по которым удаляются таблицы соответствующих объектных типов. Если такой таблицы по какой-либо причине нету, то срабатывает исключение, выводится сообщение о том, что такой таблицы нету, и цикл 7 строки продолжается.
21-38	Процедура createParentTables предназначена для создания генерируемых таблиц с атрибутами соответвующие объектному типу, для которого создается плоская таблица. Для этого создается курсор по всем объектным типам. В переменную сSQLCode, предназначенную для хранения динамического SQL кода, записывается код, который собирается, как совокупность объектного типа (значение внешнего курсора for curTables IN (select name, id from objecttypes) LOOP - 25 строка кода) и атрибутов ему соответствующих (значения параметризированного внутреннего курсора for curAttributes IN (select name, iddatatype, length from attributes where idobjecttype = curTables.id) LOOP - 27 строка кода).
40-61	Процедура insertDataParentTables предназначена для вставки значений для сгенерированных таблиц. Для этого создается курсор по всем объектным типам. В переменную сSQLCode, предназначенную для хранения динамического SQL кода, записывается код, который собирается, как совокупность объектного типа (значение внешнего курсора for curTables IN (select name, id from objecttypes) LOOP - 45 строка кода) и атрибутов ему соответствующих (значения параметризированного курсора for curAttributes IN (select name, iddatatype, length from attributes where idobjecttype = curTables.id) LOOP - 47 строка кода). Значения в генерируемую таблицу выбираются из системной таблицы userStringValues, которая хранит в поле Value значения для соответветствующего атрибута и объекта (его id задается из внутреннего курсора for curObjects IN (SELECT id from objects where idobjecttype = curTables.id) LOOP - 50 строка кода).
63-68	Процедура doGenerate предназначена для генерации, состоящей из удаления таблиц (если они существуют), создания и вставки значений данных в генерируемые таблицы и состоит из последовательного вызова процедур dropParentTables, createParentTables и insertDataParentTables.

2.2.3 Реализация функциональности добавления, редактирования и удаления объектов

Каждый объект в модели EAV состоит из набора присущих ему атрибутов. Эти атрибуты имеют свои значения. У каждого значения атрибута объекта есть свой тип данных. Каждый объект принадлежит конкретному объектному типу. Настройка параметров объекта (т.е. какому объектному типу принадлежит, какой у этого объекта набор атрибутов, типы данных этих атрибутов и т.д.) осуществляется программистом БД). ER-диаграмма объектов БД, участвующих в создании, редактирования или удалении объекта приведена на рис.2.5.



Рис. 2.5. ER-диаграмма объектов БД, участвующих в создании, редактирования или удалении объекта.

Структура и назначение таблиц Objects, Datatypes, Objecttypes и Attributes были рассмотрены чуть выше в описании процесса генерации таблиц. В этой диаграмме новой является таблица Userstringvalues. Опишем ее здесь. Таблица Userstringvalues -это таблица-справочник. Она содержит значения атрибутов, у которых тип данных String(VARCHAR). В этой таблице есть все поля, которые одназначно определят принадлежность данного значения конкретному атрибуту конкретного объекта, а именно:

1. ID - первичный ключ.

2. ID_OBJECT - определеяет ID объекта, которому принадлежит значение атрибута.

3. ID_ATTRIBUTE - определяет ID атрибута, значение которого определено в справочике.

4. VALUE - значение атрибута.

5. Created_user - пользователь, который создал объект.

6. Created_time - время, когда был создан объект.

7. Last_modified_user - пользователь, который последним изменял объект.

8. Last_modified_time - время, когда в последний раз объект изменялся.

Таким образом, рассмотрели структуру одного справочника Userstringvalues для типа данных String(VARCHAR). Однако в БД есть и другие типы данных: CLOB, DATE, DICTIONARY, MULTILANG и NUMBER. Для них будут аналогичные по структуре справочники: USERCLOBVALUES, USERDATEVALUES, USERDICTIONARYVALUES, USERMULTILANGVALUES и USERNUMBERVALUES. Стоит отметить, что в качестве значения Value справочника USERDICTIONARYVALUES будет указано id существующего объекта.

2.2.4 Реализация функциональности тщательного контроля доступа на уровне объектов

В процессе разработки и внедрения системы я столкнулся с проблемой разграничения прав доступа для разных пользователей. Была предложена система разграничения прав пользователей на основе пакета SecurityData. Этот пакет, в зависимости от контекста подключения, предоставляет пользователю права владельца объекта или по умолчанию. Это важно, т.к. права устанавливаются динамически и их легко можно менять в процессе работы системы. Кроме того, нужно отметить, что в БД Oracle существует встроенный пакет DBMS_RLS в рамках реализации Fine Grained Access Control(FGAC), который осуществляет политику прав доступа на объекты. FGAC начиная с Oracle 8i позволяет во время выполнения динамически добавлять условие (конструкцию WHERE) ко всем запросам, обращенным к таблице или представлению баз данных. Можно проверить, кто выполнял запрос, с какого терминала и когда он выполнялся, а затем создать условие на основе данной информации. Однако средства тщательного контроля доступа доступны только в редакциях Enterprise и Personal Edition; в Standard Edition эти примеры не работают. Как раз на момент разработки у нас была на данный проект лицензия на Oracle 10 Standart Edition, поэтому необходимо было разработать пакет SecurityData.

Итак, приведу ER-диаграмму объектов, определяющую политику тщательного контроля доступа на уровне объектов (рис. 2.6.).

Рис. 2.6. ER-диаграмма объектов тщательного контроля доступа.

В ER-диаграмму объектов тщательного контроля доступа входят 3 таблицы: OBJECTS, USERS и OBJECTPRIVILEGES.

Таблица OBJECTS была рассмотрена выше. Поэтому рассмотрим структуру таблиц USERS и OBJECTPRIVILEGES. Таблица USERS предназначена для хранения информации о пользователях информационной системы. Ее структура:

1. ID - первичный ключ.

2. NAME - имя пользователя, т.е. логин.

3. PASSWORD - пароль пользователя.

4. NOTE - краткие комментарии о пользователе.

5. Created_user - пользователь, который создал объект.

6. Created_time - время, когда был создан объект.

7. Last_modified_user - пользователь, который последним изменял объект.

8. Last_modified_time - время, когда в последний раз объект изменялся.

Таблица OBJECTPRIVILEGES предназначена для хранения информации о видах прав на объект. Ее структура:

1. ID - первичный ключ.

2. NAME - наименование привелегии

3. NOTE - краткие о привелегии.

Для реализации вышеозвученной задачи была принята следующая архитектура определения права на объект:

1. Если пользователь, вызывающий объект, является его владельцем, т.е. его логин совпадает с полем owner, указанным в таблице objects, тогда пользователю назначаются права владельца объекта, т.е. значение поля orights таблицы objects. Иначе идем в п.2.

2. Пользователю устанавливается право по умолчанию - значение поля arights таблицы objects для данного объекта.

Принято 3 категории прав:

Таблица 2.3. Классификация прав на объекты.

Право	Что дает это право
0	Пользователю не дается никаких прав на объект, в том числе на просмотр.
1	Пользователю дается право read-only, т.е. он может только просматривать объект, но не имеет права его изменять или удалять.
2	Пользователю даются все права на объект, в том числе он может изменять, просматривать и удалять объект.

Для вышеозвученной политики был реализован пакет SECURITYDATA. Его спецификация:

SQL> CREATE OR REPLACE PACKAGE SECURITYDATA

2 AS

3 FUNCTION checkRights(idObject NUMBER) RETURN NUMBER;

4 FUNCTION checkRights(idObject NUMBER, oright NUMBER, owner VARCHAR2, aright NUMBER) RETURN NUMBER;

5 END SECURITYDATA;

6 /

Package created

Таблица 2.4. Комментарии к заголовку пакета SECURITYDATA.

номер строчки кода	Комментарии
3	Функция checkRights предназначена для динамического определения прав вызывающего пользователя на объекты idObject.
4	Это перегруженная версия функции checkRights 3 строчки кода. Необходима для ускоренного динамического определения прав вызывающего пользователя на объекты idObject, для этого все параметры объекта должны быть определены заранее.

Для отображения на клиенте необходимо данные о правах из таблиц объектов, определяющих политику тщательного контроля доступа рис.2.2. представить в виде XML-документа. Для этого существует пакет Datamodification, его листинг приведен в приложении 1. Выходной документ должен содержать информацию о владельце, правах владельца, пользовательских группах в которые входит вызывающий, права пользовательских групп на этот объект и права пользовательских групп по умолчанию, а также право по умолчанию - т.е. для пользователей, которые не являются владельцами и не входят в пользовательские группы. Соответственно этому приложению выводится следующий XML-документ:

<object_rights ID_OBJECT="33760">

<owner>VMG</owner>

<owner_right>2</owner_right>

<others_right>1</others_right>

</object_rights>

Верхний тег object_rights содержит один атрибут - это id объекта. В нем 2 вложенных элемента: owner, owner_rights. В теге owner указывается информация о владельце объекта, в теге owner_rights - права владельца на объект, в теге others_right - право по умолчанию - т.е. для пользователей, которые не являются владельцами и не входят в пользовательские группы.

2.2.5 Реализация аудита на изменение объектов

В процессе коммерческой эксплуатации приложения часто возникают такие моменты, когда необходимо просмотреть кто, когда и как изменил клиентские данные и если, возможно, то и восстановить их. Это требование было отражено в техническом задании к работе. Для реализации этого требования я ввел процедуру аудита пользовательских объектов (т.е. данных пользовательских таблиц). При изменении, добавлении или удалении объектов данные происходит соответствующая DML-операция в таблице objects и user*values(т.е. таблицах справочниках - userclobvalues, userdatevalues, userdictionaryvalues, usermultilangvalues, usernumbervalues, userstringvalues). Для логирования были написаны триггеры, срабатывающие на каждую DML-операцию вышеперечисленных таблиц. В теле таких триггеров в зависимости от типа DML-операции(INSERT, UPDATE, DELETE) и типа данных изменненого атрибута осуществляется соответствующая запись в целевую таблицу лога (userclobvalueslog, userdatevalueslog, userdictionaryvalueslog, usermultilangvalueslog, usernumbervalueslog, userstringvalueslog), а также производится запись в пользовательскую плоскую таблицу соответсвующего объектного типа с целью немедленного изменения данных, показываемых пользователям информационной системы.

В системе используется 6 типов данных: это Clob, Date, Dictionary, Multilang, Number, String. Метаинформация этих типов содержится в системной таблице datatypes. Соответствие типов данных приложения - нейтив типам СУБД Oracle приведено в таблице 2.4.

Таблица 2.4. Соответствие типов данных приложения - нейтив типам СУБД Oracle

№	Тип данных приложения	Фактический тип данных в СУБД Oracle	Предназначение
1	CLOB	CLOB	Для хранения значений больших текстовых полей
2	DATE	DATE	Для хранения значений полей дат
3	DICTIONARY	NUMBER	Для хранения значений ссылки на id объекта (например, если атрибут - это ссылка на другой объект)
4	MULTILANG	VARCHAR2(4000)	Для хранения значений незначительных по длине текстовых полей. Предназначен для текстовых полей, значения которых должно быть уникально вне зависимости от текущего языка приложения(например поле шифр документа).
5	NUMBER	NUMBER	Для хранения значений числовых полей.
6	STRING	VARCHAR2(4000)	Для хранения значений незначительных по длине текстовых полей. Предназначен для текстовых полей, значения которых должно быть от текущего языка приложения

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

SQL> desc userstringvalueslog

Name Type Nullable Default Comments

ID NUMBER

ID_OBJECT NUMBER Y

ID_ATTRIBUTE NUMBER Y

OLD_VALUE VARCHAR2(4000) Y

NEW_VALUE VARCHAR2(4000) Y

MODIFIED_USER VARCHAR2(50) Y user

MODIFIED_TIME DATE Y sysdate

TYPE_OF_OPERATION VARCHAR2(20)

Рис. 2.7. ER-диаграмма аудита таблицы Userstringvalues.

ER-диаграмма объектов аудита данной таблицы приведена на рис.2.7. Кратко опишу основные поля таблицы Userstringvalueslog.

1. ID - первичный ключ.

2. ID_OBJECT - foreign key на id таблицы objects. Определяет объект, на который ввелся аудит.

3. ID_ATTRIBUTE - foreign key на id таблицы attributes. Определяет атрибут объекта, на который ввелся аудит.

4. OLD_VALUE - старое значение атрибута.

5. NEW_VALUE - новое значение атрибута.

6. MODIFIED_USER - пользователь, изменивший атрибут.

7. MODIFIED_TIME - время изменения атрибута.

8. TYPE_OF_OPERATION - тип операции, т.е. INSERT, UPDATE или DELETE.

Как было упомянуто выше с целью логирования были написаны триггеры, срабатывающие на каждую DML-операцию вышеперечисленных таблиц. В теле таких триггеров в зависимости от типа DML-операции(INSERT, UPDATE, DELETE) и типа данных изменненого атрибута осуществляется соответствующая запись в целевую таблицу лога (userclobvalueslog, userdatevalueslog, userdictionaryvalueslog, usermultilangvalueslog, usernumbervalueslog, userstringvalueslog), а также производится запись в пользовательскую плоскую таблицу соответсвующего объектного типа с целью немедленного изменения данных, показываемых пользователям информационной системы. Приведу код триггера USERSTRINGVALUES_AUDIT, который осуществляет логирование строковых данных в таблицу USERSTRINGVALUESLOG:

SQL> CREATE OR REPLACE TRIGGER USERSTRINGVALUES_AUID

2 AFTER INSERT OR UPDATE OR DELETE ON USERSTRINGVALUES FOR EACH ROW

3 BEGIN

4 IF inserting THEN

5 INSERT INTO USERSTRINGVALUESLOG(ID, ID_OBJECT, ID_ATTRIBUTE, OLD_VALUE, NEW_VALUE, TYPE_OF_OPERATION)

6 VALUES(SequencesData.createId(), :NEW.IDOBJECT, :NEW.IDATTRIBUTE, :OLD.value, :NEW.value, 'INSERT');

7 ELSIF updating THEN

8 INSERT INTO USERSTRINGVALUESLOG(ID, ID_OBJECT, ID_ATTRIBUTE, OLD_VALUE, NEW_VALUE, TYPE_OF_OPERATION)

9 VALUES(SequencesData.createId(), :NEW.IDOBJECT, :NEW.IDATTRIBUTE, :OLD.value, :NEW.value, 'UPDATE');

10 ELSIF deleting THEN

11 INSERT INTO USERSTRINGVALUESLOG(ID, ID_OBJECT, ID_ATTRIBUTE, OLD_VALUE, NEW_VALUE, TYPE_OF_OPERATION)

12 VALUES(SequencesData.createId(), :NEW.IDOBJECT, :NEW.IDATTRIBUTE, :OLD.value, :NEW.value, 'DELETE');

13 END IF;

14 END;

15 /

Триггеры на остальные таблицы лога (userclobvalueslog, userdatevalueslog, userdictionaryvalueslog, usermultilangvalueslog, usernumbervalueslog) аналогичны триггеры USERSTRINGVALUES_AUDIT. На поля MODIFIED_TIME и MODIFIED_USER установлены значения по умолчанию, которые определены как sysdate и user соответственно.

Для отображения на клиенте необходимо данные из таблиц логирования представить в виде XML-документов. Для этого существует пакет Datamodification, его листинг приведен в приложении 1. Аудит проводится по 3 параметрам: по атрибуту, по объекту и объектному типу. Соответственно этому приложению выводится 3 типа XML-документов. Например, для аудита выходной документ будет таким:

<attribute_summary ID="643968">

<transaction MODIFIED_TIME="19-11-2009 19:41:56" MODIFIED_USER="VMG">

<attribute ID_ATTRIBUTE="643968" TYPE_OF_OPERATION="INSERT" ATTRIBUTE_NOTE="имя" ATTRIBUTE_DATATYPE="MULTILANG">

<old_value_attribute></old_value_attribute>

<new_value_attribute>1</new_value_attribute>

</attribute>

</transaction>

</attribute_summary>

Верхний тег attribute_summary содержит один атрибут - это id атрибута. В нем вложенный элемент transaction, в котором 2 атрибута: MODIFIED_TIME - время транзакции, MODIFIED_USER - пользователь, осуществивший транзакцию. В элементе transaction - есть вложенный элемент attribute, который содержит 4 атрибута: ID_ATTRIBUTE - id атрибута, TYPE_OF_OPERATION - тип совершенной операции, ATTRIBUTE_NOTE - имя атрибута, ATTRIBUTE_DATATYPE - тип данных атрибута, а также содержит 2 вложенных элемента - old_value_attribute(определяет значение этого атрибута до транзакции) и new_value_attribute(определяет значение этого атрибута после транзакции).

Структура XML для объекта и объектного типа будет другой, более сложной. Так как объект представляет собой совокупность атрибутов - то нужно собрать аудит транзакций всех атрибутов объекта и представить в виде вложенных тегов XML-документа. Таким образом, будет добавлен верхний тег object_summary, содержащий id объекта, а в нем будет коллекция XML-элементов аудита по всем атрибутам данного объекта. Пример такого документа:

<object_summary ID="51994">

<transaction MODIFIED_TIME="19-11-2009 19:36:56" MODIFIED_USER="VMG">

<attribute ID_ATTRIBUTE="643968" TYPE_OF_OPERATION="UPDATE" ATTRIBUTE_NOTE="Name" ATTRIBUTE_DATATYPE="MULTILANG">

<old_value_attribute>9</old_value_attribute>

<new_value_attribute>12</new_value_attribute>

</attribute>

</transaction>

<transaction MODIFIED_TIME="19-11-2009 18:12:35" MODIFIED_USER="VMG">

<attribute ID_ATTRIBUTE="643968" TYPE_OF_OPERATION="UPDATE" ATTRIBUTE_NOTE="Name" ATTRIBUTE_DATATYPE="MULTILANG">

<old_value_attribute>7</old_value_attribute>

<new_value_attribute>9</new_value_attribute>

</attribute>

</transaction>

</object_summary>

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

<object_type IDOBJECTTYPE="1">

<objects_summary>

<transaction MODIFIED_TIME="19-11-2009 19:36:56" MODIFIED_USER="VMG">

<object_info object_id="51994">

<attribute ID_ATTRIBUTE="643968" TYPE_OF_OPERATION="UPDATE" ATTRIBUTE_NOTE="Name" ATTRIBUTE_DATATYPE="MULTILANG">

<old_value_attribute>9</old_value_attribute>

<new_value_attribute>12</new_value_attribute>

</attribute>

</object_info>

</transaction>

<transaction MODIFIED_TIME="19-11-2009 18:12:35" MODIFIED_USER="VMG">

<object_info object_id="51994">

<attribute ID_ATTRIBUTE="643968" TYPE_OF_OPERATION="UPDATE" ATTRIBUTE_NOTE="Name" ATTRIBUTE_DATATYPE="MULTILANG">

<old_value_attribute>7</old_value_attribute>

<new_value_attribute>9</new_value_attribute>

</attribute>

</object_info>

</transaction>

</objects_summary>

</object_type>

Так как объект представляет собой совокупность атрибутов - то нужно собрать аудит транзакций всех атрибутов объекта и представить в виде вложенных тегов XML-документа. Таким образом, будет добавлен верхний тег object_type, содержащий id объектного типа, а в нем будет находиться коллекция XML-элементов аудита по всем объектам данного объектного типа.

2.2.6 Реализация механизма поиска объектов

Поисковый механизм должен осуществлять поиск по объектам по определенным заранее неизвестным параметрам, задаваемым пользователями во время их работы. Так, например, пользователь захочет найти все фотодокументы выпущенные после 1930 до 1950 года, в Северо-Западном регионе или найти рукописи в которых есть определенное слово и т.д. Как видно, здесь будет осуществляться поиск по атрибутам с определенными критериями. Эти критерии описаны в таблице conditions. Ее структура:

1. ID - первичный ключ.

2. Смысловое описание параметра поиска.

На данный момент в таблице conditions заданы следующие параметры поиска:

Таблица 2.5. Возможные поисковые параметры.

ID	Смысловое описание параметра поиска
1	Содержит слово
2	Не содержит слово
3	Ровно
4	Не равно
5	Содержит
6	Больше
7	Больше или равно
8	Меньше
9	Меньше или равно
10	Не содержит
11	Не заполнено
12	Заполнено
13	Слово начинается

Понятно, что не всем атрибутам должны быть доступны все параметры поиска. По строковым атрибутам скорее всего будет осуществляться поиск по параметрам: “Содержит слово”, “Не содержит слово”, “Слово начинается” и т.д., однако не будет поиска по параметрам “Больше”или “Меньше или равно”. И для числовых типов должен осуществляться поиск по по параметрам “Больше”или “Меньше или равно”, но не будет осущестляться поиск по параметрам “Содержит слово”,“Не содержит слово”, “Слово начинается”. Эти соответствия задаются в таблице Conditiondatatypes, имеющей следующую структуру:

1. ID - первичный ключ.

2. IDATTRIBUTE - атрибут для которого задается соответствие.

3. IDCONDITION - поисковый параметр доступный для атрибута.

4. FDEFAULT - поисковый параметр для атрибута по умолчанию.

Таким образом, ER-диаграмма объектов, определяющих параметры поиска, приведена на рис. 2.8. Структура и назначение таблиц Attributes и Datatypes приведены выше, поэтому здесь их описывать смысла нету.



Рис. 2.8. ER-диаграмма объектов, определяющих параметры поиска.

Выбранные поисковые атрибуты необходимо где-то сохранить, чтобы в процессе поиска искать объекты, удовлетворяющие этим поисковым параметрам. С этой целью была создана временная таблица на время транзакции (т.е. использовалась конструкция temporary table SEARCHPARAMETERS on commit delete rows -которая позволяет создавать временные таблицы на уровне транзакции, так что при COMMIT или ROLLBACK данные из этой таблицы удаляются[5]). Таблица SEARCHPARAMETERS имеет следующую структуру:

1. ID поискового параметра - первичный ключ.

2. IDSEARCHOBJECTTYPE - id объектного типа, по которому осуществляется поиск.

3. IDATTRIBUTE - id атрибута, для которого задается поисковый параметр. Foreign Key для таблицы Attributes.

4. IDCONDITION - id поискового атрибута для параметра. Foreign Key для таблицы Conditions.

5. IDLANGUAGE - id языка, по которому будет осуществляться поиск. Foreign Key для таблицы Languages.

6. VALUE - значение поискового параметра(так если будет производиться поиск по параметру “Слово начинается с “утре”” - то значение VALUE будет “утре”, если по параметру “Больше 20” - то значение VALUE будет “20” и т.д.).

После выбора и инициализации поисковых параметров, а значит заполнения полей таблицы SEARCHPARAMETERS будет произведен поиск по объектам объектного типа поля IDSEARCHOBJECTTYPE. Поиск осуществляется с помощью пакета SearchData - его листинг в приложении 1.

Рис. 2.9. ER-диаграмма объектов, осуществляющие поисковый механизм.

Найденные значения вставляются во временную таблицу TEMPFOUNDOBJECTS. Она аналогично таблице SEARCHPARAMETERS является временной на уровне транзакции (т.е. с использованием конструкции on commit delete rows). Таблица TEMPFOUNDOBJECTS имеет следующую структуру:

1. ID - это ID найденного объекта.

2. OBJECTSERIAL - это серийный номер найденного объекта, задает порядок вывода найденный объектов.

Учитывая вышесказанное, ER-диаграмма объектов, осуществляющие поисковый механизм, будет следующей (см. рис. 2.9.).

2.3 Модель пользовательских данных

2.3.1 Общая архитектура пользовательских объектов БД

Общая архитектура пользовательских объектов БД приведена на рис. 2.10.

Рис. 2.10. Общая архитектура пользовательских объектов БД.

Архитектура пользовательских объектов БД состоит из 3 основных частей:

1. Объектов определяющих хранение фотодокументов архива.

2. Объектов определяющих хранение фонодокументов архива.

3. Всех остальных пользовательских объектов.

Подробное описание каждой из частей архитектуры пользовательских объектов БД привожу ниже.

2.3.2 ER-диаграмма фотодокументов архива

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

Рис. 2.11. ER-диаграмма фотодокументов архива.

Таблица Photodocuments определяет хранящиеся в БД фотодокументы архива. В таблице есть следующий колонки:

1. ID - первичный ключ. Определяет id фотодокумента, является внешним ключом к id таблицы objects.

2. SHOOTAUTHOR - Автор съемки. Существуют 3 колонки SHOOTAUTHOR: SHOOTAUTHOR1, SHOOTAUTHOR2, SHOOTAUTHOR3 соответственно для хранения инициалов автора съемки на русском, английском и немецком языках.

3. DEED - id акта приема-передачи фотодокумента на хранение.

4. ANNOTATION - аннотация.

5. KIND - определяет id вида фотодокумента.

6. SHOOTDATE - Дата съемки.

7. IMAGE - само изображение.

8. NUMBERNEGATIVES - количество негативов.

9. NOTESHOOTPLACE - Комментарий к месту съемки.

10. INSURANCECODE - Номер страхового договора на фотодокумент архива.

11. NOTE - Примечание.

12. DOCSIZE - id размера фотодокумента.

13. COMPILER - id cоставителя записи.

14. CODE -шифр фотодокумента.

Таблица SIZES определяет размеры документов, хранящиеся в БД. ЕЕ структура:

1. ID - первичный ключ.

2. NAME1 - размер документа на русском языке.

3. NAME2 - размер документа на английском языке.

4. NAME3 - размер документа на немецком языке.

Таблица STAFF определяет сотрудников, работающих в архиве. Структура таблицы:

1. ID - первичный ключ.

2. NAME1 - ФИО сотрудника на русском языке.

3. NAME2 - ФИО сотрудника на английском языке.

4. NAME3 - ФИО сотрудника на немецком языке.

5. AKKNAME1 - размер документа на русском языке.

6. AKKNAME2 - размер документа на английском языке.

7. AKKNAME3 - размер документа на немецком языке.

8. POSITION - id должности, занимаемой сотрудником.

Таблица Positions определяет должности, которые занимают сотрудники архива. Структура таблицы:

1. ID - первичный ключ.

2. NAME1 - Название должности на русском языке

3. NAME2 - Название должности на английском языке

4. NAME3 - Название должности на немецком языке.

Таблица ReceivingDeeds определяет акты приема-передачи. Структура таблицы:

1. ID - первичный ключ.

2. DEEDNUMBER - номер акта.

3. DEEDDATE - дата оформления акта.

4. INSPECTOR - id приемщика акта.

Таблица Inspectors определяет приемщиков актов. Структура таблицы:

1. ID - первичный ключ.

2. NAME1 - ФИО приемщика на русском языке.

3. NAME2 - ФИО приемщика на английском языке.

4. NAME3 - ФИО приемщика на немецком языке.

2.3.3 ER-диаграмма фонодокументов архива

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

Таблица Phonodocuments определяет хранящиеся в БД фонодокументы архива. В таблице есть следующий колонки:

1. ID - первичный ключ. Определяет id фонодокумента, является внешним ключом к id таблицы objects.

2. DEED - id акта приема-передачи фотодокумента на хранение.

3. CODE -шифр фотодокумента. Тип атрибута MULTILANG - т.е. значение шифра одинаково на всех языках, поддерживаемых БД.

4. NAME1 - Наименование фонозаписи на русском языке.

5. NAME2 - Наименование фонозаписи на английском языке.

6. NAME3 - Наименование фонозаписи на немецком языках.

7. TYPE - тип фонозаписи, внешний ключ к таблице MUSICTYPES.

8. CREATIONDATE - дата создания фонозаписи.

9. CREATIONPLACE - место создания фонозаписи, внешний ключ к таблице MUSICPRODUCTIONPLACES.

10. SHOOTAUTHOR - Автор съемки. Существуют 3 колонки SHOOTAUTHOR: SHOOTAUTHOR1, SHOOTAUTHOR2, SHOOTAUTHOR3 соответственно для хранения инициалов автора съемки на русском, английском и немецком языках.

11. NOTE1 - Примечание к фонодокументу на русском языке.

12. NOTE2 - Примечание к фонодокументу на английском языке.

13. NOTE3 - Примечание к фонодокументу на немецком языке.

14. COMPILER - составитель фонозаписи, внешний ключ к таблице STAFF.

15. COMPILEDATE - дата составления фонозаписи.



Рис.2.12. ER-диаграмма хранения фонодокументов архива.

Таблица MUSICTYPES определяет типы фонодокументов, хранимых в БД. Ее структура:

1. ID - первичный ключ.

2. NAME1 - Наименование типа фонодокумента на русском языке.

3. NAME2 - Наименование типа фонодокумента на английском языке.

4. NAME3 - Наименование типа фонодокумента на немецком языке.

Таблица MUSICPRODUCTIONPLACES определяет места издания фонодокументов, хранимых в БД. Ее структура:

1. ID - первичный ключ.

2. NAME1 - Наименование места издания фонодокумента на русском языке.

3. NAME2 - Наименование места издания фонодокумента на английском языке.

4. NAME3 - Наименование места издания фонодокумента на немецком языке.

Таблицы Insectors, Receivingdeeds, Staff и Positions описаны выше в разделе 2.7.1. ER-диаграмма фотодокументов архива.

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

Кроме фонодокументов и фотодокументов в БД хранятся новости, информация о выставках архива и веб-страницы сайта архива. ER-диаграмма вышеперечисленных пользовательских данных приведена на рис. 2.13. Кратко опишу структуру входящих в эту ER-диаграмму объектов БД:

Таблица EXHIBITIONS определяет информацию о проведенных или планируемых к проведению выставках. Ее структура:

1. ID - первичный ключ.

2. NAME1 - Наименование выставки на русском языке.

3. NAME2 - Наименование выставки на английском языке.

4. NAME3 - Наименование выставки на немецком языке.

5. NOTE1 - Примечание о проводимой выставке на русском языке.

6. NOTE1 - Примечание о проводимой выставке на английском языке.

7. NOTE1 - Примечание о проводимой выставке на немецком языке.

8. COMPILEDATE - дата составления записи. На значение поля установлено значение по умолчанию в виде текущего времени и даты.

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

1. ID - первичный ключ.

2. HEADER1 - Заголовок новости на сайте на русском языке.

3. HEADER2 - Заголовок новости на сайте на английском языке.

4. HEADER3 - Заголовок новости на сайте немецком языке.

5. CONTENT1 - Содержимое статьи о новости на сайте на русском языке.

6. CONTENT2 - Содержимое статьи о новости на сайте на английском языке.

7. CONTENT3 - Содержимое статьи о новости на сайте на немецком языке.

8. COMPILEDATE - дата составления новости. На значение поля установлено значение по умолчанию в виде текущего времени и даты.

Рис. 2.13. ER-диаграмма объектов БД, определящих хранимую информацию о выставках, новостях и вебстраницах веб-сайта.

Таблица WEBPAGES содержит информацию о веб-страницах сайта архива. Ее структура:

1. ID - первичный ключ.

2. NAME1 - Наименование веб-страницы на русском языке.

3. NAME2 - Наименование веб-страницы на английском языке.

4. NAME3 - Наименование веб-страницы на немецком языке.

5. CONTENT1 - Информация о содержимом веб-сайта на русском языке.

6. CONTENT2 - Информация о содержимом веб-сайта на английском языке.

7. CONTENT3 - Информация о содержимом веб-сайта на немецком языке.

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

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

Важно отметить, что пользователь информационной системы, подключаясь к БД из клиентского приложения не имеет гранта на просмотр пользовательских таблиц, он имеет доступ только к представлениям, которые сгенерированы на пользовательских таблицах. Это сделано для функционирования политики тщательного контроля доступа к объектам. Поясню: создается представление к пользовательской таблице с фильтрацией по функции checkrights пакета SECURITYDATA, которому передается в качестве параметра id объекта, для которого нужно определить доступ. Функция возвращает право пользователя на данный объект. Например, для таблицы NEWS будет создано представление NEWS_VIEW1(см. рис.2.14.).



Рис. 2.14. Представления пользователя приложения, определяющие хранимые в БД новости.

Код представления будет таков:

SQL> CREATE OR REPLACE VIEW NEWS_VIEW1

2 AS SELECT ID, HEADER1, BRIEFDESCRIPTION1, FULLDESCRIPTION1, COMPILEDATE

3 FROM NEWS

4 WHERE SECURITYDATA.checkRights(ID)>0

View created

Стоит обратить внимание что, в названии представления последним символом указана цифра1 - это обозначение языка системы, для которого представление сгенерировано. Т.к. в БД должна быть реализована поддержка 3 языков - то и представлений будет 3(см. таб.2.6.)

Таблица 2.6. Соответствие названия представления языку приложения.

№	Название представления	Язык БД, для которого представление создано
1	NEWS_VIEW1	Русский
2	NEWS_VIEW2	Английский
3	NEWS_VIEW3	Немецкий

Код представления соответственно для английского языка БД будет таков:

SQL> CREATE OR REPLACE VIEW NEWS_VIEW2

2 AS SELECT ID, HEADER1, BRIEFDESCRIPTION2, FULLDESCRIPTION2, COMPILEDATE

3 FROM NEWS

4 WHERE SECURITYDATA.checkRights(ID)>0

View created

Код представления соответственно для немецкого языка БД будет таков:

SQL> CREATE OR REPLACE VIEW NEWS_VIEW3

2 AS SELECT ID, HEADER3, BRIEFDESCRIPTION3, FULLDESCRIPTION3, COMPILEDATE

3 FROM NEWS

4 WHERE SECURITYDATA.checkRights(ID)>0

View created

Логика определения права пользователя на объект описана выше в главе “Реализация функциональности тщательного контроля доступа на уровне объектов.

Представления фонодокументов

Аналогично новостям для фонодокументов тоже будут сгенерированы 3 представления: Phonodocuments_View1, Phonodocuments _View2, Phonodocuments _View3(см.рис. 2.15.)



Рис.2.15. Представления пользователя приложения, определяющие хранимые в БД фонодокументы.

Представления фотодокументов

Для фотодокументов будут сгенерированы 3 представления: Photodocuments_View1, Photodocuments _View2, Photodocuments _View3(см.рис.2.16.)

Рис. 2.16. Представления пользователя приложения, определяющие хранимые в БД фотодокументы.

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

Аналогично новостям для веб-страниц тоже будут сгенерированы 3 представления: Webpages_View1, Webpages_View2, Webpages_View3(см. рис.2.17.)



Рис. 2.17. Представления пользователя приложения, определяющие хранимые в БД веб-страницы.

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

Для выстовок будут сгенерированы 3 представления: Exhibitions_View1, Exhibitions_View2, Exhibitions _View3(см.рис.2.18.)

Рис. 2.18. Представления пользователя приложения, определяющие хранимые в БД выставки.

3. Апробация функционирования БД

3.1 Описание работы БД как основной части информационной системы

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

Рис 3.1. Внешний вид интерфейса информационной системы.

Выбор объектного типа.

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



Рис. 3.2. Выбор механизма показа объектов (все объекты или только те, что удовлетворяют определенным критериям)

В случае выбора меню список будет осуществлен вывод в виде списка всех объектов выбранного объектного типа. Если же пользователь выбрал вывод объектов в виде параметра поиска - то ему будет предложено набрать поисковую форму, в которой он должен выбрать согласно алгоритму изложенному в главе “Реализация механизма поиска” атрибуты объекта, по которым ввести поиск (см. рис.3.3.) и задать поисковые условия, по которым осуществлять поиск по атрибутам объектов (см. рис. 3.4.). В этой форме фактически задаются поля таблицы SearchParameters описанной выше.

Рис. 3.3. Выбор атрибутов по которым искать объекты.



Рис. 3.4. Выбор поисковых условий по которым искать объекты.

После указания атрибутов и поисковых условий необходимо определить шаблон значения атрибута по которому ввести поиск (см. рис. 3.5.). Значение поискового параметра (так если будет производиться поиск по параметру “Слово начинается с “утре”” - то значение атрибута в данной поисковой форме (которое задаст значение поля VALUE таблицы SearchParameters) будет “утре”, если по параметру “Больше 20” - то значение VALUE будет “20” и т.д.).

Рис. 3.5. Выбор поисковых параметров.

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



Рис. 3.6. Выбор механизма показа объектов(все объекты или только те что удовлетворяют определенным критериям)

Также в техническом задании необходимо обеспечить поддержку как минимум 2 языков: английского и русского. Для переключения языка пользовательского интерфейса сделано соответствующий список (см. рис. 3.7.), который определит idlanguage таблиц objects, attributes и справочников, по которым будет ввестись работа информационной системы.

Рис. 3.7. Меню выбора языка информационной системы.

После вывода объектов в виде списка пользователю должна быть предоставлена возможность редактирования объекта. Алгоритм редактирования объекта описан выше в главе “Реализация функциональности добавления, редактирования и удаления объектов”.

Здесь я привожу (см. рис. 3.8.) вид пользовательского интерфейса при редактировании произвольного объекта, например, объекта новость с заголовком “Выставки петербурга конец XIX - начало ХХ века” объектного типа новости. В этой форме с помощью * пользователь определяет обязательные для заполнения атрибуты объекта. Если они остаются незаполненными то при сохранении объекта, система выведет информационное окно с сообщением об ошибке.

Рис. 3.8. Редактирование объекта новость с заголовком “Выставки петербурга конец XIX - начало ХХ века” объектного типа новости.

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

Пользователь запросил из под приложения следующую новость:

SELECT briefdescrription1 FROM news WHERE id = 1292983;

Запрос вернет следующее:

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

А затем обновил поле briefdescrription1 следующим образом:

UPDATE news

SET briefdescrription1 = to_clob('"Июль, август - традиционная пора всякого рода заплывов в нашем городе. Пусть даже вода в Неве не слишком теплая, но теплее уже не станет, А плавать хочется."')

WHERE id = 1292983;

COMMIT;

Соответственно вышеупомянутый запрос вернет следующее:

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

Cодержимое данного поля изменилось. Была произведена DML-операция над таблицей USERCLOBVALUES, а значит сработал триггер USERCLOBVALUES_AUDIT, который зафиксирует изменения в таблице USERCLOBVALUESLOG.

Пользователь системы замечает логическую ошибку в данных и хочет вернуть предыдущее значение. Для этого программист БД осуществляет запрос к логу clob данных:

SELECT ID, ID_OBJECT, ID_ATTRIBUTE, OLD_VALUE, NEW_VALUE, MODIFIED_USER, MODIFIED_TIME, TYPE_OF_OPERATION

FROM USERCLOBVALUESLOG

WHERE OLD_VALUE = to_clob('Июль - традиционная пора всякого рода заплывов в нашем городе. Пусть даже вода в Неве не слишком теплая, но теплее уже не станет, А плавать хочется.');

На данный запрос из БД вернутся следующие данные (см. рис.3.9.):

Рис.3.9. Возвращаемые данные из ДБ при запросе в аудит.

На основании этих данных можно осуществить DML-операцию, которая восстановит пользовательские данные. Ее код будет следующим:

UPDATE news

SET briefdescrription1 = to_clob('"Июль - традиционная пора всякого рода заплывов в нашем городе. Пусть даже вода в Неве не слишком теплая, но теплее уже не станет, А плавать хочется."')

WHERE id = 1292983;

COMMIT;

Тогда исходный запрос к данному объекту новости вернет иходные данные:

SELECT briefdescrription1 FROM news WHERE id = 1292983;

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

Перейдем теперь к рассмотрению работы политики тщательного контроля доступа к объектам. Напомню, в списке исходных требований 2 пунктом исходя из наличия лицензии на конкретный проект СУБД определена как Oracle версии - 10.2.0.3 Standard Edition. Кроме того, в 7 пункте списка сказано, что в БД необходимо разработать политику прав доступа к объектам в зависимости от пользователя. Политика безопасности должна обеспечивать разные права на объекты для владельцев объекта, для пользовательских групп и для пользователей, которые не являются ни владельцами ни входят в пользовательские группы. Продемонстрирую работу разработанного пакета SECURITYDATA.

Важно отметить, что пользователь информационной системы, подключаясь к БД из клиентского приложения не имеет гранта на просмотр пользовательских таблиц, он имеет доступ только к представлениям, которые сгенерированы на пользовательских таблицах. Это сделано для функционирования политики тщательного контроля доступа к объектам. Поясню: создается представление к пользовательской таблице с фильтрацией по функции checkrights пакета SECURITYDATA, которому передается в качестве параметра id объекта, для которого нужно определить доступ. Функция возвращает право пользователя на данный объект. Например, для таблицы NEWS будет создано представление NEWS_VIEW. Код представления будет таков:

SQL> CREATE OR REPLACE VIEW NEWS_VIEW

2 AS SELECT * FROM NEWS

3 WHERE SECURITYDATA.checkRights(ID)>0

View created

Логика определения права пользователя на объект описана выше в главе “Реализация функциональности тщательного контроля доступа на уровне объектов.

Итак, возьмем 2 произвольных объекта в таблице NEWS, скажем с id = 2000899675 и id = 2000899693:

SQL> select id from news where id = 2000899675 or id = 2000899693

ID

2000899675

2000899693

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

Проверим данные о владельце, праве владельца и праве всех остальных пользователей на данный объект:

SQL> COLUMN ID FORMAT A10

SQL> COLUMN owner FORMAT A10

SQL> COLUMN ORIGHTS FORMAT A7

SQL> COLUMN ARIGHTS FORMAT A7

SQL> select id, owner, orights, arights from objects where id = 2000899675 or id = 2000899693 or id = 2000899783;

ID OWNER ORIGHTS ARIGHTS

2000899675 PETROV 2 2

2000899693 PETROV 2 2

2000899783 PETROV 2 2

Таким образом, убеждаемся, что владелец всех 3 объектов - пользователь PETROV, владельцу дано право 2 на таблицу, всем остальным пользователям - тоже право 2. Изменим это следующим образом (см. табл. 3.1.):

Таблица 3.1.

ID	OWNER	ORIGHTS	ARIGHTS	RIGHTS OF SIDOROV
2000899675	PETROV	2	2	2
2000899693	PETROV	2	0	0
2000899683	PETROV	0	2	2

В качестве всех остальных пользователей использую пользователя SIDOROV. Значение его прав определено в колонке RIGHTS OF SIDOROV. Код который осуществит конструкцию прав, указанной в табл.3.1., будет следующим:

SQL> update objects set orights = 0 where id = 2000899783;

SQL> update objects set arights = 0 where id = 2000899693;

SQL> select id, owner, orights, arights from objects where id = 2000899675 or id = 2000899693 or id = 2000899783;

ID OWNER ORIGHTS ARIGHTS

2000899675 PETROV 2 2

2000899693 PETROV 2 0

2000899783 PETROV 0 2

Соответственно доступ для пользователя Petrov будет следующим:

Connected to Oracle Database 10g Release 10.2.0.3.0

Connected as petrov

SQL> select id from NEWS_VIEW where id = 2000899675 or id = 2000899693 or id = 2000899783;

ID

2000899675

2000899793

Соответственно доступ для пользователя Sidorov будет следующим:

Connected to Oracle Database 10g Release 10.2.0.3.0

Connected as sidorov

SQL> select id from NEWS_VIEW where id = 2000899675 or id = 2000899693 or id = 2000899783;

ID

2000899675

2000899783

Теперь проверим право 1. Напомню, что пользователю с таким правом на объект дается только право на просмотр объекта, на редактирование такого права нет. Установим права для пользователя PETROV права на объекты как показано в таблице 3.2.

Таблица 3.2.

ID	OWNER	ORIGHTS
2000899675	PETROV	2
1292983	PETROV	1
2000899683	PETROV	0

Соответственно доступ для пользователя Petrov будет следующим:

Connected to Oracle Database 10g Release 10.2.0.3.0

Connected as petrov

SQL> select id from NEWS_VIEW where id = 2000899675 or id = 1292983 or id = 2000899783;

ID

2000899675

2000899793

В приложении для пользователя Petrov на объект 1292983 будет установлено право 1, т.е. пользователь только сможет просматривать объект (см. рис.3.10.).



Рис.3.10. Просмотр объекта без права на редактирование объекта.

Если же в приложении для пользователя Petrov на объект 1292983 будет установлено право 2, то пользователь сможет просматривать и редактировать объект (см. рис.3.11.).

Connected to Oracle Database 10g Release 10.2.0.3.0

Connected as petrov

SQL> update objects set arights = 2 where id = 1292983;

SQL> select id, owner, orights, arights from objects where id = 1292983;

ID OWNER ORIGHTS ARIGHTS

1292983 PETROV 2 2

Рис.3.11. Просмотр объекта с правом на редактирование объекта.

3.2 Тестовые примеры (test cases)

Ввиду большого количества тестовых примеров проводимых в процесс разработки БД информационной системы, приведу в таблице 3.3. только наиболее интересные тест кейсы. Возможные приоритеты тест-кейсов в порядке убывания их статуса: Blocker, Critical, Major, Minor, Trivial.

Таблица 3.3. Test cases.

ID	Название	Цель	Среда выполнения	Пошаговое выполнение	Критерий выполнения	Приоритет
DB1	Поддержка объектов на русском языке	Проверка создания, редактиро-вания и удаления объектов на русском языке.	PL\SQL Developer 7.1.5.1398	1. Выбрать объектный тип, в котором есть атрибуты на русском языке. 2.Создать объект та-кого объектного типа. 3.Заполнить значения атрибутов объектного типа литералами на русском языке. 4.Сохранить в БД. 5. Выбрать этот объект из БД.	Наличие объектов и корректный вывод значений атрибутов объекта на русском языке.	Blocker
DB2	Поддержка объектов на английском языке	Проверка создания, редактирования и удаления объектов на английском языке.	PL\SQL Developer 7.1.5.1398	1. Выбрать объектный тип, в котором есть атрибуты на английском языке. 2.Создать объект такого объектного типа. 3.Заполнить значения атрибутов объектного типа литералами на английском языке. 4.Сохранить в БД. 5. Выбрать этот объект из БД.	Наличие объектов и корректный вывод значений атрибутов объекта на английском языке.

Подобные документы

• Разработка базы данных

  Инфологическая модель предметной области. Схемы простых объектов и их свойства. Построение реляционных отношений на основе инфологической модели базы данных. Сетевая и иерархическая даталогическая модели БД. Структура таблиц, реализованных в СУБД Oracle.
  
  курсовая работа [1,0 M], добавлен 10.06.2014
  

• Проектирование и разработка базы данных автоматизированной информационной системы предприятия

  Схема взаимодействия подразделений предприятия. Выбор и обоснование технологии проектирования базы данных. Описание объектов базы данных. Разработка запросов на выборку, изменение, обновление и удаление данных. Интерфейсы взаимодействия с базой данных.
  
  курсовая работа [1,4 M], добавлен 25.05.2023
  

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

  Семантическое моделирование данных. Основные понятия модели Entity-Relationship. Построение инфологической модели в виде диаграммы "Таблица-связь". Проектирование физической модели базы данных. Разработка формы заставки, главной, вторичных кнопочных форм.
  
  курсовая работа [1,5 M], добавлен 26.06.2012
  

• Разработка информационной системы для обслуживания предметной области "Картотека ГИБДД"

  Анализ проектирования баз данных на примере построения программы ведения информационной системы картотеки ГИБДД. Основные функции базы данных. Обоснование выбора технологий проектирования и реализации базы данных. Описание информационного обеспечения.
  
  курсовая работа [753,0 K], добавлен 27.08.2012
  

• Модификация информационной системы компьютерного магазина

  Разработка информационной системы учёта данных о клиентах, товарах и услугах в среде MS Access. Технология функционирования существующей ИС компьютерной компании. Модификация инфологической модели БД, проектирование новых экранных форм и отчетов.
  
  курсовая работа [1,5 M], добавлен 20.06.2014
  

• Разработка базы данных для хранения информации, необходимой для организации предоставления услуг

  Разработка информационно-аналитической системы агентства недвижимости. Обоснование выбора архитектуры базы данных и СУБД. Моделирование потоков данных (DFD диаграмм). Проектирование инфологической модели данных с использованием модели "сущность-связь".
  
  дипломная работа [5,4 M], добавлен 06.06.2013
  

• Теория проектирования. Создание базы данных

  Рассмотрение теоретических основ проектирования. Анализ предметной области и разработка таблиц базы данных. Заполнение таблиц, поиск данных с помощью фильтра. Создание форм, разработка запросов. Создание и настройка отчетов, составление приложения.
  
  курсовая работа [2,8 M], добавлен 01.06.2014
  

• Разработка базы данных "Автомобильное предприятие"

  Особенности разработки инфологической модели и создание структуры реляционной базы данных. Основы проектирования базы данных. Разработка таблиц, форм, запросов для вывода информации о соответствующей модели. Работа с базами данных и их объектами.
  
  курсовая работа [981,4 K], добавлен 05.11.2011
  

• Проектирование базы данных тренера спортивного клуба

  Описание предметной области разрабатываемой базы данных для теннисного клуба. Обоснование выбора CASE-средства Erwin 8 и MS Access для проектирования базы данных. Построение инфологической модели и логической структуры базы данных, разработка интерфейса.
  
  курсовая работа [3,8 M], добавлен 02.02.2014
  

• Разработка базы данных информационной системы склада косметики и парфюмерии компании "Белоснежка"

  Инфологическое моделирование предметной области. Построение диаграммы потоков данных. Обоснование выбора СУБД. Проектирование пользовательского интерфейса. Комплект поставки и порядок установки системы. Описание функционирования приложения и таблиц.
  
  курсовая работа [3,2 M], добавлен 23.08.2014
  

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам