3. Methods of Implementation of
Entities
Two separate databases one with a more simplified ‘gene’
and ‘disease’ for gameplay and one with those tables with
more attributes so we can determine how they are linked.
Diseases have a type attribute, but this idea I’m not so keen
on since a gene MIGHT be linked to a type and for data
sorting I prefer many entities. If type is just simply a type
however, it could be just a disease
Disease is a subtype of a type because a gene can be linked
to a type of disease, but we can use a simple join statement
to statistically analyze the types that a certain gene is linked
to. Though it is an idea if we want to make a disease a certain
subclass of a type or another disease
Not all tables will be used for the game itself, since the game
doesn’t deal with the specifics, but for analytical purposes
they should be kept to help sort the information.
5. Specifics (Constraints and such)
Since a gene/it’s mutation is unique in
itself, the gene name would be it’s
unique identifier.
The number of chromosomes only
needs to be added if anueploidy is
true otherwise it is assumed that it is a
normal number, that can be set as a
default or left out
7. Game Specifics
It would have to integrate the general genetic
linkage schema with the player’s choices
Player’s default high score would be 0
The subclass ‘correct’ is relevant for
gameplay purposes as some might get
confused at how to find the right answer. I
would suggest an SQL statement
implementing a join and checking if there are
any answer/question combination, or a
boolean to check if it’s correct for each
question, but although included on the same
schema, is just an alternate implementation
and can safely be removed
