30-Nov-200630-Nov-2006 Sakai Data Work GroupSakai Data Work Group 11

SakaiAssessing Interest in the Formation and Viability

of aData Work Group

30-Nov-2006 Sakai Data Work Group 2

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.

30-Nov-2006 Sakai Data Work Group 3

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

30-Nov-2006 Sakai Data Work Group 4

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

30-Nov-2006 Sakai Data Work Group 5

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.

30-Nov-2006 Sakai Data Work Group 6

- 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<nn>- Unique Indexes should end with _U<nn>- Primary keys should be <table_name>_PK- Foreign Keys should should be <table_name>_FK<nn>- Check constraints should end with _CK<nn>- Not Null constraints should end with _NN<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

30-Nov-2006 Sakai Data Work Group 7

Potential Data (cont) Standards & Practices• Name Shortening Algorithm (if necessary)

– If length <Prefix>_<OBJECT_NAME>_<suffix> is greater than 30 then <OBJECT_NAME_> 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 <Prefix>_<Object_Name>_<Suffix> greater than 30 then truncate <Object_Name> so that overall length is <= 30

– Example: OSP_ANUNBELIEVABLYVERYLONGINDEX_NAME_Iwould becomeOSP_ANUNBLVBLYVRYLONGNDX_NM_I

30-Nov-2006 Sakai Data Work Group 8

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.

30-Nov-2006 Sakai Data Work Group 9

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

30-Nov-2006 Sakai Data Work Group 10

Next Steps

• Group Discussion