Tuesday, May 6, 2008
SIF Data Model ERD - Updated
The SIF Data Model Entity Relationship Diagram that I recently published as a Google Presentation has been updated to include two new areas: Special Programs and HR Finance. Assessments are likely to be next. Please feel free to nominate what you would like to prioritize. Enjoy!
Subscribe to:
Post Comments (Atom)
Posts
3 comments:
Hi Jason,
I would like to thank you for post. These ERDs are very good. Thanks for putting such wonderful resource on internet.
I have a question for you as well. In your SIF Data Model "workgroup/taskforce -- SIS", I did not get the implications of having SchoolYear in all tables as part of composite Pk. Couldn't it more flexible if there was a table for SchoolYear Which acts as FK to tables where SchoolYear is needed?
Thanks,
Mudit
You are welcome!
This is a very observant comment. The generic answer is that in a relational, application-centric data model a separate SchoolYear object/table makes sense. You then have to think about how the use cases for an interoperability data model, like SIF, may differ from a highly normalized, relational data model. I'll try to explain this further by providing some background, and then an example.
Historically, the composite key for an object instance, which is generally comprised of the root element's attributes, has had a special role with respect to SIF’s request/response mechanism. In SIF 1.x, Agents were required to support queries on these root attributes. This provided a clear, albeit limited, means to scope data requests. The inclusion of SchoolYear as a root attribute in many of the SIS objects makes it relatively simple for a requesting agent to query for “temporally sensitive” objects. If SchoolYear were to be normalized into a separate entity, subscribers would first have to synchronize this data before making time-scoped requests. Requesting data by SchoolYear is a very common thing to do, and thus why SchoolYear is present in the root element of many objects.
Take as an example a request for the SchoolCourseInfo object. The presence of @SchoolYear in the root element allows a requesting Agent to “ask” for all course information applicable to a specific school year by simply passing the value of the target school year, as opposed to a foreign key reference to the data. Another way to say this is that the design of SIF objects sometimes breaks the mold of data modeling best practices in order to support functionality needed by Agents. This is where the SIF data model and its API characteristics cross paths.
[Footnote] In SIF 2, responding Agents are required to support queries by all mandatory elements and attributes. This provides much richer support for scoping requests. However, many of the conventions of the SIF 1.x data model have carried over into the SIF 2 data model. Providing a better mechanism to clearly identify “key material” within data objects, perhaps for multiple purposes, has been identified as a need.
Ok. Now it makes good sense. :)
I never thought about the ERDs from SIF aspect. I was looking w.r.t relational model only.
Thank you!
Post a Comment