We're thinking about relational data applications differently.
Our database system (RafikiDB) is designed for fast development and simple (essentially automatic) user security and permissions management.
We built this to build school software (RafikiSIS), but it could be used to build almost anything.
Interested?
RafikiSIS is schoool software to complement, improve and extend the PowerSchool SIS.
Rafiki is Swahili for friend. RafikiSIS focuses on relationships, getting better information to the people most engaged with each student - parents, teachers, mentors, coaches.
Sitting alongside PowerSchool, RafikiSIS allows schools to enjoy the strengths of PowerSchool with two primary additional benefits:
- One single "portal" website for parents, students, staff, and other stakeholders for information from PowerSchool (grades and schedule, etc.), information from other data systems (LMS, accounting, cafeteria, buses, etc.), or new information managed in the RafikiSIS system.
- An administrative system to manage more student and parent information than is currently available inside PowerSchool, a way to manage new types of information that does not fit easily into PowerSchool data structures, and an easier way to manage security for all school data.
Specific benefits include:
- Parents have one portal website for all school related information - and they sign in once for all their children.
- Administrators can manage more information about students and parents than with PowerSchool alone.
- Administrators can manage almost any other type of information related to the school or to students, enabling new functionality and reporting.
- Administrators can make that new information available securely for specific appropriate users - parents, students, or staff.
- Data from other school systems (LMS, accounting, etc.) can be securely linked to and displayed to appropriate users as well - providing one website for all school information.
- Administrators can manage new student activities (sports, clubs, mentoring, etc.) and new relationships to define additional student "stakeholders" like grandparents, guardians, coaches, mentors, support staff, etc.
- All users (students, parents, staff and other stakeholders) use the same portal with automatically personalized menus, search capabilities, and permissions to gain precisely appropriate access to information based on specific roles with specific students.
- Just right information access and personalized menus are determined "automatically" through "normal" administrative data management. There is no additional layer of security management required. And, this security/permissions model can be applied to all data at the school - not just the data inside RafikiSIS.
A few screen shots:
The sidebar "menu" is unique for each user based on their relationships.
Further Details for each "entity" (person, course, group, etc.) are easily accessible.
Users can search for anything - and skip the menus.
Historic data is available with a quick selection of year or school term.
Coming in the future:
- a comprehensive parent/staff/student communication system - tracking all communication among student stakeholders
- a data porting system that moves or copies data from one system at a school to another (i.e. from an LMS like Google Classroom to an SIS like PowerSchool).
If your school could benefit from this system,
RafikiDB is the secure, flexible database that makes RafikiSIS possible. It could be used in other industries and markets - especially any place where user permission to access information is based on relationships.
Everthing in RafikiDB is stored as either an Entity (with associated Attributes) or a Relationship between Entities.
This design allows for rapid model and application modifications simply by defining new Entity Types and new Relationship Types.
Access to information (i.e. Permissions and Security) is defined by Relationship patterns.
See the following example of Entities and Relationships:
- A Person Entity could have a FATHER relationship to another Person Entity
- that second Person might have a STUDENT relationship to a Course Entity
- the Course entity might have a HAS_TEACHER relationship to another Person Entity
- that person entity might have a CONTACT relationship to an Email Address Entity.
Now consider a relationship pattern such as:
- FATHER → STUDENT → HAS_TEACHER → CONTACT
We could assign READ Permission to that relationship pattern. If (and only if) the relationship between a user and the data the user is trying to read matches that pattern, the user can read the data.
The above example would mean that a father of a student who is enrolled in a course can see the email address of the teacher teaching that course.