1

I am designing an ERP like app for a local martial arts studio. Currently, the main functionality is to keep attendance records to training sessions. To do so, I have designed the following data model:

Data Model

Some relations are:

  • A martial art practitioner can practice more than one martial art. But they must practice at least one martial art (I couldn't express the latter in my diagram).
  • An instructor for a given martial art must be chosen among the practitioners of that martial art.
  • In order to be counted as present or absent in a training session, a student should have had registered for that training session slot beforehand.

This is my first data model, so I am guessing that I have at least a couple of mistakes here. Could you please point out my mistakes here, if any?

2
  • 2
    Data models are usually not good or bad in themselves - they must reflect the things and their relations you are modelling. This latter part is what we don't know anything about.
    – dezso
    Apr 11, 2017 at 6:33
  • @dezso Added some relations.
    – Utku
    Apr 11, 2017 at 8:28

1 Answer 1

3

There's a lot of redundancy between the mma and the bjj tables. If the only real data difference between an MMA practitioner and a BJJ practitioner is the belts and stripes, I'd consider pushing the unique fields from mma_practitioner and bjj_practitioner tables into the martial_arts_practitioner table; including adding a field indicating whether a given practitioner is mma or bjj (if mutually exclusive), or small fields (bit or 1 character) mma and bjj (if someone can be in both).

Even if other practitioner types will be added later, I'd still recommend this change; creating and maintaining an entire set of roster and session tables for each practitioner type wouldn't necessarily scale well. If there are more significant differences that aren't obvious, that could change this recommendation, but I can't think of anything off the top of my head.

An additional thought: it looks like instructors and students are both kept in the same table. This may make sense (especially if an instructor can also be a student in some other class or practition type). However, there are likely to be a number of fields unique to teachers (certifications, wages/salary, etc.) that would not apply to students. Similarly, there are likely to be a number of fields unique to students (grades, source [for marketing to other students], etc.) that wouldn't apply to instructors. And, presumably, every class/training session must have an instructor. It might make sense to have students and instructors in separate tables.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.