1. One end of the line, refers to the **max** number of times that an instance of one entity can be associated with instances in the related entity. It can be **one**, **many** or **none**
2. The second, describes the **min** number of times one instance can be related to others.
It can be **zero** or **mandatory**
The combination of those two indicators create relations, you can get more information [here](https://community.mis.temple.edu/mis3506digitaldesignfall2018/files/2018/10/Adam-Alalouf_Cardinality.pdf)
Events will be the accumulation of the following tables :
-`event`
-`registration`
-`registration_user`
-`event_user`
This part of the database takes care of schools activities with time.
The `event` table contains the following relations:
-`parentId` that is associated to himself. This association can be better explained if we take a look at the `path` column. An event can be based on a parent event (ex: the event `/madere/div-01/piscine-rust` is associated to this parent event `/madere/div-01`).
-`registrationId` that is associated to the `registration` table. An event can have multiple registrations, but a registration can only be associated to one event, this being the parent event of the registration table.
-`objectId` that is associated to the `object` table, this column will identify which object is associated to which event. An object can have multiple events but must have at least one.
The `event_user` contains the associations between events and users. This will contain information on which users are registered to which event. An event can have multiple users and a user can have multiple events, this way being a many to many relationship.
The `registration` table contains all objects/activities that need registration. Having the following relations:
-`parentId` that is associated to himself. As said above (in the events), it has the same use.
-`objectId` that is associated to the object table, this is the object reference to the registrations.
---
The `registration_user` table is a relationship many to many between `registration` and `user`. This table contains all users that are registered to an event.
-`registrationId` a registration can have multiple users.
-`userId` a user can have multiple registrations.
---
### Objects
Object will be the accumulation of the following tables :
-`object`
-`object_child`
-`object_status`
-`object_type`
This part of the database defines the structure of the content.
The `object` table contains the following relations:
-`referenceId` that is associated to himself, an object can have none or many references. This attribute allows the creation of duplicates and allows each campus to create their own objects.
The `object_child` table contains the encapsulation of objects. An object can have multiple children and a child must have one object parent. This table contains the following relationships to the object table:
-`parentId` that associates the parent object to the child object.
-`childId` that belongs to the parent object.
Both child and parent must have at least one association to the `object` table, and the `object` table can have multiple relations with the `object_child` table.
But `piscine-go` can be the **parent object** of all the quest, exams and raids (those being the **child objects**). And so on... creating a finite cycle.
The `user_role` contains information on which users are associated to which role. A user can have multiple roles and a role can be associated to multiple users.
-`eventId` that associates the event in which the user was rewarded. Example: the user can be rewarded for an exercise `/madere/piscine-go/quest-01/make-it-better` and the parent event of that exercise will be `/madere/piscine-go`.
-`objectId` that associates the object in which the user was rewarded. Example: if a user passes an exercise (object), the reward will be associated to that object.
---
#### Results
Results will be the accumulation of the following tables:
-`audit`
-`match`
-`progress`
-`result`
This part of the database defines the users/students progress in the school.
The `audit` table contains all information related to the audit system and it is one of the ways of obtaining results. This table contains the following relations:
-`groupId` that associates the group being audited.
-`auditorId` as the name says, it is linked to the user table and has a relation of many to one. This column will be the auditor.
-`resultId` that associates the audit to the result. An audit can have one or no results (pending on the auditor review). While the results must have at least one audit.
The `match` table is another way of obtaining a result. This table is used in bonus exercises to match two students. The following relations are established:
-`userId` this will be the user wanting the match to happen.
-`matchId` this is a self related id, a match can be made by matching other students or it can be none. If the latter is none it means that the student is waiting for the match, otherwise it is a match.
-`eventId` that associates the event to the current match. Example: a user can be waiting for the exercise `/madere/piscine-go/quest-01/teacher` that is located in the `/madere/piscine-go` event.
-`objectId` that associates the object to the current match, this being the bonus exercise that the user is doing.
---
The `progress` table is the summary of multiple results. As the names says this is the students progress. The following relations are established:
-`userId` that associates an user with a progress. A progress must always have a user associate to it and a user can or cannot have multiple progresses.
-`groupId` this association allows groups to have progress. This is a many to none or one connection, meaning that a progress can have none or one group and a group can have multiple progresses.
-`eventId` that associates which event the user has progressed on.
-`objectId` that associates which object the user has progressed on.
