@ -10,9 +10,9 @@ An entity can have several relations to other entities. Those relations are repr
### Relationships cardinality
Relationships have a cardinality, normally they have two indicators that are shown on both sides of this line.
Relationships have a cardinality, normally they have two indicators that are shown on both sides of the line.
1. The first 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** or**many** or **none**
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**
@ -40,11 +40,11 @@ The `event` table contains the following relations:
- `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 event can have multiple objects but must have at least one.
- `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 event 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 `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.
This table also contains an association to the **group** table. Users can or cannot have groups, the concept is the same as in `userId` but groups can be none.
@ -77,23 +77,23 @@ 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 permits each campus to create their own objects.
- `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.
- `authorId` that is associated to the user table and this is the author of that object/content.
---
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:
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.
example:
Example:
Campus `madeira` is a **parent object** of `piscine-go`, therefore the latter is the **child**.
Campus `madeira` is a **parent object** of `piscine-go`, therefore the later one is the **child**.
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 cycle.
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.
---
@ -116,11 +116,11 @@ The `role` table contains permission roles for each user.
---
The `user_role` contains information on which users are associated to which role. A user can have multiple roles and a role can have multiple users.
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.
---
The `group` table is the link between projects/objects and a group of users. This table contains the following relations:
The `group` table is the link between projects and a group of users. This table contains the following relations:
- `eventId` that associates which group is related to which event.
- `captainId` that associates the captain's user.
@ -128,22 +128,22 @@ The `group` table is the link between projects/objects and a group of users. Thi
---
The `group_user` table contains the relation between groups and users. A group can have several users and so do the users, which can contain multiple groups.
The `group_user` table contains the relation between groups and users. A group can have several users and so do the users.
---
The `token` table stores the tokens id from the hasura authorization variables for each user. This table as no relation between other tables.
The `token` table stores the tokens ids from the hasura authorization variables for each user. This table has no relation between other tables.
---
The `record` table takes care of students records for example: bans. All relations in this table are with the table user.
The `record` table takes care of students records (bans). All relations in this table are with the table user.
---
The `transaction` table takes care of rewarding the user, by accumulating the user's **xp**. This table contains the following relations:
- `userId` that represents the user rewarded
- `eventId` that associates the event in which the user that 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`.
- `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.
---
@ -163,11 +163,11 @@ The `audit` table contains all information related to the audit system and it is
- `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 (depending on the auditor review). While, the results must have at least one audit.
- `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 users/students. The following relations are established:
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.
