| Core tables |
| Table or view | Table or view name | Description |
|---|
| table | AUTHORIZATION |
Each record represents an Authorization, which contains a
Person (from the PERSON table), a Function (from the FUNCTION
table) and a Quailfier (from the QUALIFIER table) plus some
flags and other information. This table is denormalized, because
of decisions made in 1997 related to our expectations for
performance at that time. Note that the qualifier_type for
the Function must match the qualifier_type for the Qualifier,
and this is enforced by the stored procedures that create and
update authorizations. |
| table | CATEGORY |
Each record represents a Function Category, or application
area for which Authorizations can be granted.
Each Function has exactly one Function Category. Therefore,
each Authorization has exactly one Function Category. |
| table | FUNCTION |
Each record contains a Function, which is the business function
that a person gains authority to do (or role that a person
takes on) when an Authorization is granted.
|
| table | FUNCTION_CHILD |
Some Functions have "child" Functions. If you have an Authorization
for Function X and Qualifier Q, and Function Y is a child of
Function X, then you also have an implied Authorization for Function Y
and Qualifier Q. Each record in the FUNCTION_CHILD table represents
one parent/child pair of Functions. Usually, the parent Function
and child Function must have the same Qualifier Type. (There are
exceptions when the set of Qualifiers of one Qualifier Type are
a subset of Quailfiers of another Qualifier Type.)
Most Functions
have neither a parent Function nor a Child Function, so most
Functions have no corresponding records in this table. Note that
unlike the QUALIFIER_CHILD table, the FUNCTION_CHILD table has
no corresponding "FUNCTION_DESCENDENT" table. Thus, if there
is a parent/child record for Function X and Function Y (making
X a parent of Y), and there is a parent/child record for
Function Y and Function Z (making Y a parent of Z), it is not
the case that Function X is a parent of Function Z unless someone
manually adds a specific parent/child record for
Function X / Function Z. |
| table | PERSON |
Each record represents one Person. The table contains a record
for all people who currently have a valid Kerberos principle at MIT,
plus a few special-case usernames that represent servers that
also have Authorizations in the Roles Database. |
| table | PERSON_TYPE |
Each record represents a Person Type, e.g., EMPLOYEE, STUDENT, or
OTHER. Each Person has exactly one Person Type. |
| table | QUALIFIER |
Each record represents one Qualifier, a financial, HR, academic,
or other unit that makes up the third part of an Authorization. The
Qualifier "qualifies" the area in which a person is authorized
to perform a given Function. |
| table | QUALIFIER_CHILD |
The QUALIFIER_CHILD table defines the hierarchy of Qualifiers of
a given Qualifier Type. Each record represents a parent/child
pair of Qualifiers within a given hierarchy of Qualifiers (and
therefore the parent and child Qualifiers in one record must have
the same Qualifier Type). Each record represents only a direct
parent/child relationship between two (different) Qualifiers.
Each Qualifier of a given Qualifier Type,
except for the root, has at least one parent Qualifier (and in
rare instances, more than one parent Qualifier). Many, but not
all Qualifiers have one or more child Qualifiers. Parent/child
links cannot create cycles or loops. In other words,
if you follow the chain of child, grandchild, great grandchild,
etc., Qualifiers under a given Qualifier, you can never
get back to the original Qualifier. |
| table | QUALIFIER_DESCENDENT |
The QUALIFIER_DESCENDENT table is derived from the QUALIFIER_CHILD
table. Each record in this table represents an ancestor/descendent
link between two Qualifiers. It contains one record for each link
between a Qualifier and its immediate children, plus one record
for each link between a Qualifier and its grandchildren, plus
one record for each link between a Qualifier and its great
grandchildren, etc.. Within each ancestor/descendent pair,
both Qualifiers must have the same Qualifier Type. |
| table | QUALIFIER_TYPE |
Each record defines a "type" of Qualifier, e.g., 8-digit HR org unit,
Fund/Funds Center, Academit org unit, etc.. Each Qualifier has
exactly one Qualifier Type. There is one root Qualifier for each
Qualifier Type (although the root is currently not recorded
in the QUALIFIER_TYPE table). |
| table | SUPPRESSED_QUALNAME |
This table is currently only defined on the test Roles Database,
and has not yet been defined on the production database. Some
Qualifier Types are flagged as IS_SENSITIVE='Y' in the QUALIFIER_TYPE
table. Qualifiers for these Qualifier Types have a their
qualifier_name suppressed (i.e., set to "(value suppressed)"
in the QUALIFIER table to prevent unauthorized users from viewing
them. For these Qualifiers, the actual qualifier name is recorded
in the table SUPPRESSED_QUALNAME, which is under tighter access
control.
|
| The following 3 tables are used to determine
which functions and qualifiers can be picked by FINANCIAL and
HR PRIMARY AUTHORIZERs when they create authorizations. |
| table | DEPT_APPROVER_FUNCTION |
Some Functions, i.e., financial approver Functions, are
specific to certain DLCs. If you are a Financial Primary Authorizer
within a given DLC, you should be limited to assigning the
financial approver Functions related to your DLC. The table
DEPT_APPROVER_FUNCTION maps function_id's to their related dept_code,
so that the Roles application can limit which financial approver
Functions can be granted according to the DLC for which a
person is a Financial Primary Authorizer.
The data in this
table are derived each night from other tables by a program.
The program fix_dept_appr_func.pl combines data from the
flat file data/pa.approver_functions with data from tables
PRIMARY_AUTH_DESCENDENT, QUALIFIER, and WH_COST_COLLECTOR
to build a list of approver functions mapped to each DLC, and
use it to update the table DEPT_APPROVER_FUNCTION. |
| table | PA_GROUP |
This table contains one record for each type of Primary Authorizer,
e.g., HR and FIN. See the section "Adding another type of Primary
Authorizer" within the document
sys_admin_tasks.html. |
| table | PRIMARY_AUTH_DESCENDENT | ... |
