1. 30-Nov-2006 Sakai Data Work Group 1 1 Sakai Assessing Interest in the Formation and Viability of a Data Work Group

2. 30-Nov-2006Sakai Data Work Group2 Purpose of the Sakai Data Work Group Recommend to the Sakai Governing Body, a Minimal set of Data Standards & Practices that are designed to : –Ease Integration of Sakai Modules into the Sakai System –Ease Integration of Sakai Data into Enterprise Databases, Data Warehouses, Data Marts, Decision Support Systems, etc. Upon approval by the Sakai Governing Body, Implement, maintain and publish that Minimal set of Data Standards & Practices Review adherence to the approved Data Standards & Practices Assist developers of Sakai Modules with compliance to the approved Data Standards & Practices.

3. 30-Nov-2006Sakai Data Work Group3 Objective of This Session Assess the interest in the formation of the Sakai Data Work Group If the interest is there, –solicit volunteers to serve –present some discussion starters ideas and concepts of potential data standards and practices. - Determine next steps of the Sakai Data Work Group

4. 30-Nov-2006Sakai Data Work Group4 Potential Data Standards & Practices Columns that identify/describe/measure exactly the same thing should be named the same (between tables not within). Columns that do NOT identify/describe/measure exactly the same thing should be named differently. This would preclude the use of the generic column name of ID

5. 30-Nov-2006Sakai Data Work Group5 Potential Data (cont) Standards & Practices Prefixing Object Names –Objects that share a common functionality should begin with a Reserved Standard Prefix that: starts with a letter which may be followed 0.. 2 alphanumerics ends with an underscore –Examples: OSP_ (open source portfolio), GB_ (gradebook), etc. –A process for reviewing and reserving functional prefixes will need to be designed and implemented. Sakai Project Module developers should be encouraged to reserve early or run the risk of having to change an available prefix if their choice is taken or fails to adhere to the standard format.

6. 30-Nov-2006Sakai Data Work Group6 -Table objects should end with _T -Fact Tables should end with _FT or _F -Dimension (Lookup) Tables should end with _DM or _D -Sequences should end _S -Views should end with _V -Non-unique Indexes should end with _I -Unique Indexes should end with _U -Primary keys should be _PK -Foreign Keys should should be _FK -Check constraints should end with _CK -Not Null constraints should end with _NN -Constraints of Primary Key, Foreign Key and Unique Indexes should have the same name as its corresponding index Potential Data (cont) Standards & Practices Suffixing Object Names

7. 30-Nov-2006Sakai Data Work Group7 Potential Data (cont) Standards & Practices Name Shortening Algorithm (if necessary) –If length _ _ is greater than 30 then should be shortened by extracting vowels in order (aeiou) in the object name only (omit prefix and suffix) that are not at the beginning First extracts A’s Then E’s (if necessary) Repeat for each vowel until length <= 30. –If, after all vowels have been removed and length of _ _ greater than 30 then truncate so that overall length is <= 30 –Example: OSP_ANUNBELIEVABLYVERYLONGINDEX_NAME_I would become OSP_ANUNBLVBLYVRYLONGNDX_NM_I

8. 30-Nov-2006Sakai Data Work Group8 Potential Data (cont) Standards & Practices Foreign Keys –Foreign Key Column Name should match the names used to name the primary key columns of its parent table. For Example, today in table NODE_T –NODE_T.NODE references its parent AGENTGROUP_T.ID –Since the parent and child column names do not match,this adds complexity for report writers and future developers in that they must run special queries to determine the foreign key relation Data Design Best Practices recommends –Renaming AGENTGROUP_T.ID to ID in AGENTGROUP_T to AGENTGROUP_ID (objects [generic ID] that do NOT identify/describe/measure the same thing should be NOT be named the same) –Renaming NODE_T.NODE to NODE_T.AGENTGROUP_ID to facilitate the identification of Foreign Keys for report writers and future developers –It eases migration from SAKAI into other databases, data marts, data warehouses, decision support systems etc.

9. 30-Nov-2006Sakai Data Work Group9 Potential Data (cont) Standards & Practices General Recommendations : - Avoid special characters like spaces, slashes, at_signs, etc. -Keep object names to the singular (EMPLOYEE) instead of (EMPLOYEES) - Uses Primary Keys wherever possible

10. 30-Nov-2006Sakai Data Work Group10 Next Steps Group Discussion