UU Database

Database structure requirements

Naming Conventions

1. All tables should have names of two or three words, separated with underscore. The combination of first letters of these words should be unique in the whole database. In this document, this combination, followed with underscore ('_'), is called table name prefix. Example: teachers_list, course_group_list.
2. Every field in every table should have table name prefix, followed by the field name. Example: teachers_list(tl_id), course_group_list(cgl_id).
3. Every index name should start from "ndx_", followed with the table name prefix, and the field names, included in the index, separated with underscore.
4. The primary key name should start from "pk_" followed by the table name prefix
5. The foreign key name should start from "fk_" followed by the table name prefix and foreign table name prefix

Structure Requirements

1. Tables in the database are placed in two domains: main and logs. The logs domain contains tables that contain access logs and statistics information. These tables may be emptied at any given moment without affecting the actual data.
2. Every table should have a unique primary id (integer,auto-increment), logically not connected to the actual data.
3. Any application that connects to the database, should have only read-access to the tables. All the modification operations, including insert, update, delete operations, should be performed in the stored procedures. The stored procedures should be implemented in a stored procedure language (most likely PL/SQL or equivalent), that doesn't allow to create a stored procedure without an integrity check. Integrity check should validate every object used in the stored procedure.
4. Any transaction, performed by the application, should include only one stored procedure call.
5. The important corner-stones tables should have triggers, logging any modifications in these tables as a set of user name, modification date and time, modification type. (If this is accepted, I'd provide the implementation details).
6. Under no circumstances tables should use automatic cascade-delete on foreign keys. For any delete of detail records, stored procedure should verify the access rights for the given group of the records within the table (assuming that the user is granted access to the stored procedure removing records).

Security Requirements

1. The security policy should provide several access roles. Besides the role, every user is granted the set of the (objects,projects,courses) he can access. Modification of access to the critical objects is only allowed if person has relation to the (objects,projects,courses). Every user may be granted several roles, if underlying database supports that.
2. We have to implement at least the following database roles:
   1. DBO/DBA and backup (already implemented)
   2. Customer service role has access to read everything (may be but security tables), access to all maintenance and all security stored procs
   3. User role has access implemented through the stored procedures using ACL.
   4. Reports role has read access to everything but security tables, access to reporting stored procs

   Automated maintenance should use either "Customer Service", or "Backup" roles..

3. The most interesting case is the access to shared objects. A shared object, included in the course, can be accessed by user using stored procedures. If the user needs to modify a shared object, the modification request is made through the stored procedure. Any details of the versioning are encapsulated within the modification stored procedure. However, the stored procedure must validate the access right of the user upon the modification attempt. Only the owner of the shared object may modify it without creating a new version of the object.

Database objects

The database objects represent entities of the project. The following entities are the most important for this project:

The study information is presented with: course, topic, unit, explanation, keyword, reference, problem, test, competition, work-flow, homework, excersize, game, faculty, objective, through-problem, dialogue-of-texts. Any of these can be shared objects.

The users of the system are described with: User, user levels, user groups, user group types.

The financial relations are described with: Company, company types, subscription, subscription types, rate, payments.

User Managed Objects (UMOs)

Some of the database objects can be managed by users. That includes (but isn't limited to) creating new UMOs, connecting the existing UMOs to other UMOs, modifying UMOs, and access permissions management.

All the different types of the UMO are still stored in the database exactly the same way. This allows to implement the wide range of the operations (stored procedures) covering common (for all UMO types) actions such as creating a new UMO, creating a UMO version, etc. Every UMO has a single (common for all versions of this UMO) 'base' record. Base record owns the UMO version records (one per UMO version), and every version record owns 'content' records (one per content language). This structure allows creating multiple versions per UMO, and every version may provide content in one or more languages.

One of the most important properties of UMO is versioning. That means, that modification of existing published UMO is always done by creating a new version of the UMO, modifying that new version to acceptable state, and publishing it. The old versions of the UMO are kept in the database for future references (if needed). The number of the UMO versions isn't limited. The latest available version is considered as default version, however if there is a need to use an older version of the UMO - it may be used (if permissions are enough, of course).

Access permissions is another important access of the UMOs. UU database defines multiple access permission types that may be assigned to groups. Every UMO connects to one or more groups like 'Students', 'Teachers', 'Administrators' that have different set of permissions. Users can be included into groups to get access permissions to UMOs connected to groups. Users included into 'Administrators' group of the UMO can include or exclude users in/from UMO user groups. The global 'Public' group automatically includes all users. So, if UMO grants any permissions to the 'Public' group then all the users receive these permissions. The most popular permission to grant this way is 'View'.

All UMOs are equal, but some UMOs are more equal than others :) Even though all the UMOs are stored in the database the same way, some of them may have extra actions not typical for others. These actions are implemented as stored UMO-type specific procedures.

Security implementation

Most modern databases allow to define primitive access permissions (SELECT,UPDATE,DELETE) on the table level, or even on the level of table column. The general limitation of this approach is that it doesn't offer any access restrictions on the row level. One of the ways to implement different restrictions for the same user to different records within the same table is to implement all the access to the database tables throw stored procedures while revoking all the access rights from the users on the restricted tables. Stored procedures, in that case, must be created with SECURITY DEFINER attribute. Such stored procedures can be called by regular users but use their creator's permissions when access the tables.

For the regular users (not database administrators), the user information is stored in the person_list table, including known user information along with login name and encrypted password. A user id (a primary key from person_list table, or pl_id) is used as primary user identification. However, any permissions to any object are granted to groups of users and not to particular user. The permissions to an object fro a user can be determined by combining group permissions (from the groups user belongs to) for the object.

Every stored procedure that supports access restrictions must check if the current user has enough permissions to perform an operation. The user credentials are obtained during logon (session start). Logon to the system creates temporary table that stores current user information. Without that table, most of the stored procedures would generate exception requiring to login first.

ACL implementation

ACL is implemented on object type and object id basis. The ACL table contains references to the group id, the object type id, and the object (object id), accompanied with the access field. An access field is an integer that contains a bit combination of the available access values:

A particular person has a permission to object that combine permissions of all groups of th object, the person is a member of.

ACL entries are maintained with the stored procedures acl_grant and acl_revoke. Upon execution, stored procedures check if the user has "Modify" right on the object, and then modifies the access for the group. If the required ACL entry doesn't exist it is created.

ACL entries perform slightly differently for the open server and proprietary server configurations. For the open server, the special right bits (Study..Link) are always set, allowing unlimited Study..Link use.