OSIMS

The key to any student based information has to be the students.  They are, afterall, the reason we’re building the system.  In this assessment system we’ll be tying all sorts of data to these students.  They’ll be enrolling in schools and classes, participating in educational programs, taking assessments and accumulating requirements toward graduation and certification.  Because they are so central, it’s important to closely consider what needs to be tracked and how it will be most useful.

Just the Basics
When determining what qualifies as student information there are a myriad of possible fields.  Things such name, nickname, birth date, gender, graduation year, school of enrollment and native language quickly come to mind.  The easy thing to do would be to start building a students database table and adding all these fields and more as needs arise.  But I think it’s important to put a little more though into the system and the manner in which we’ll want to access the information.

Instead of creating a table that’s thirty or forty fields long, I’m going to choose a few key pieces of information which will help me to identify unique students and use those to create my students table.  I’ll be leaving off a lot of information so that it can be incorporated in ways that make it more useful in the future.  Perhaps the biggest surprise is that I’ve decided to not even include gender in the students table.

Here are the pieces I feel are necessary to identify unique students:

Unique Interal ID Number
First Name
Middle Name
Last Name
Birthdate
and an
External ID (or two).

For school district staff to be certain they have the correct students, name and birthdate is usually more than sufficient.  In practice that only falls apart when you have twins (whose first names can sometimes be similar) or when the district contains two students with the same name (think John Smith and the like) and who are roughly the same age.  Then you really have to scrutinize the birthdates and at times make a few calls to determine you’ve got the right student.  Such instances, while rare, are virtually unavoidable.

Most data we receive into this system should, hopefully, identify the student by a unique numerical identifier which I’ll store in external id.  Although I’ve only defined one external id per a student at this time, I may reconsider and add a second.  In practice students can have as many unique student ids as there are data systems.  In the last seven years I’ve seen a district go through two and a half primary datasources which has left us with two district assigned ID numbers for kids.  The state of Oregon maintains it’s own unique identifier for each student in the state.  Food services, migrant services and other programs each assign students from their own set of identification numbers.  Even other tracking tools give students their own ID numbers.  In an ideal world one student ID would be sufficient, but I can easily see how my particular case may require at least a district and state identification number.

But why not gender?

There are some very common ways in which student data is grouped and analyzed, one of which is gender.  Though it can be enlightening and entertaining, we aren’t likely to group students by first name and compare all the Johns’ test scores to the Joes’.  We may, however, want to compare schools, ethnicities, poverty, English proficiency, or gender.  I’ve made the concious decision not to include gender in the students table because I want to include it alongside all those other indicators for reporting purposes.  The case could be made that districts may wish to analyze data by age and that birth date is the gateway to that element.  This is a valid point, but in the past eight years I’ve only had age requested once, and grade level was a fair proxy for that information.  If the need is great enough, it could be fulfilled by creating a process that extracts date of birth and fills the related indicator for age.

In Conclusion

I’m designing the student table with only the most basic and necessary pieces of information.  Any indicators which are likely to be requested for reporting purposes are being left to a separate process.  I’ll explain the process for these indicators in a future post.

Filed under:
Uncategorized by Brian Bain