...
The objects in the CourseManagement framework will be filled almost entirely with data from institutional systems. This page will outline each CourseManagement Object, the institutional data that will be referenced, and any implementation issues. Additionally, each CourseManagement object requires an EID to uniquely identify rows. The algorithm for generating each eid will be captured here.
EID Structure
A general requirement of both Hibernate and the CourseManagement framework is that each driving table must have a column that unqiuely identifies each row in the table. Given that most of our source systems do not use single-value primary keys, we will need to synthesize these EIDs. Generally this will happen as a string concatenation of the fields minimally sufficient to uniquely identify the row. For example, the AcademicSession object can simply use the unique term_code column from the source STVTERM table in Banner, while the EnrollmentSet object will need to concatenate the term_code and crn fields in order to guarantee uniqueness.
Given that these generated values have some structural meaning, the decision was made to encode them in ??? form. Therefore, each eid is prepended with a string of the form: http://ucdavis.edu/course/. After the heading, the object name or path to the object is recorded and then the unique value concatenation follows, resulting in the following final format: http://ucdavis.edu/course/<object-path-and-name>/<unique-values-concatenation>. The following are some examples of EIDs created for the system:
- http://ucdavis.edu/course/academicsession/200710
- http://ucdavis.edu/course/courseset/department/BIS
- http://ucdavis.edu/course/offering/BIS/001C/200710
- http://ucdavis.edu/course/enrollmentset/52525/200710/RE/01122133
Common Fields
All of the CourseManagement Objects share a set of fields in common. These fields seem to primarily be concerned with determining the actor that created or updated the data in the object, as well as when that happened. Luckily, the source systems all record activity dates for rows in source tables. So, we will be generically mapping the following columns thusly:
- createdBy: The name of the source system for the majority of columns. (This will almost always be 'BANNER')
- createdDate: The activity date from the source system's row.
- lastModifiedBy: The name of the source system for the majority of columns. (This will almost always be 'BANNER')
- lastModifiedDate: The activity date from the source system's row.
AcademicSession / UCD_CM_ACADEMICSESSION (AcademicSessionCmImpl)
...