You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Monday:



perMIT

Data Tables

"Qualifier modifies the scope within an A-spec."

Qualifier hierarchies are a tree structure.  A leaf can have more than one parent, but circular  references are not allowed.

Each distinct qulalifier hierarchy is encapusulated by the qualifier type.

E.g. qualifier type of HR Org units is one tree strucuture.

        qualifier type of Fund Centers and Funds is another tree structure.

TERM: "Primary authorizer" - a person(s) within a department that can grant authorizations  regarding the department. Who they grant that authorization to is not limited to people within  the department.

There is a function HR_PRIMARY_AUTHORIZER and a function  FINANCIAL_PRIMARY_AUTHORIZER the qualifiers are a DEPARTMENT code.

Schema exists on Troles and Roles in schema subdirectory? Should get a copy and use Visio to  create diagrams to see how these compare with Jim's diagrams.

Qualifier descent table updated by bulk feeds, as well as UI triggering stored procedures. One or  two at time via stored procedures are OK. Updating 200, the bulk feed is more efficient.

Include two views of the qualifier descendent table:

  1. Same table as today
  2. Same table as today, but also includes where the parent and child have the same ID

View B means that you can do a single select statement instead of two, for the case where the  user has a direct A-spec assignment instead of via inheritance.

Visio diagrams: try connecting Visio to roles using my roles username and password...

Vast majority of functions don't have parent / child relationship. We don't have  function  descendent table that is equivalent of the qualifier descendent table.

Suppressed QualName: business reason, make few people able to determine who is doing  particular types of researcher: animal, reactor, P4....

Visio reverse engineer:

Data Source Name:

Description:

TNS Service Name: roles.mit.edu or troles.mit.edu

User ID: pbh

Afternoon meeting: implied authorizations

(Paul 30 minutes late due to other meeting)

Some constraints maintained via a generic stored procedure. One that is not likely to modified by  any other sites because it is helping to provide the referrential integrity.

Qualifier_subtypes:

We can have subtypes within a qualifier hierarchy

e.g EHS r_set can have subtypes of principal investigator, room_set, room,...

Subtype_descendent_subtype is not derived from anything. It is manually entered. It is the table  that shows that Principal Investigator  is a higher level then the ROOM_SET, and ROOM.

Function_load_pass is missing from current document. Jim will add.

URL to show some of the rules. Jim will send or put in wiki.

Tuesday:



perMIT:

Qualifiers vs. Object

Qualifiers belong to a heirarchy

Subject

Function

qualifier

Subject

Verb

object

Who

What

where


Should permit add a second optional qualifier? (4 columns)

perMIT - Tuesday afternoon

Master Dept. Hierarchy

https://mv-ezproxy-com.ezproxy.canberra.edu.au/mdept/\\

If Jim were redoing qualifier hierarchy section of Roles, he would implement it more like the  master dept. hierarchy. Allows for multiple types in single heirarchy. Also means that certain  objects don't need to be duplicated.

Should perMIT do this? We could put in the tables and columns, but have them default to the way  that we have qualifiers implemented today.

Bigger meeting topic: should we change the data model of the qualifiers so that a single object can  exist in two hierarchies.

Allows for some very sophisticaded reporting, but need think through the UI issues of  creating the qualifiers.

Here's an object. What views do you want it to appear in? What are the parents and  children in each of the views?

Friday: revisiting the DB schema. How to restructure the qualifiers


 

  • No labels