4.2 Entity Relationship Diagram
The ER diagram details the database structure currently implemented for the current milestone. The ER diagram is simplified as compared to the original plants below in the platform design as the database is used locally for a single user on browser.
The database is implemented on indexedDB (noSQL). An external open-source library, alasql, which is able to mimic SQL structure is used. However, direct interaction is used on indexedDB when alasql failed to implement certain features.
The ER diagram details the database structure that we are planning to implement for platform, if time permits.
We will be implementing the database with SQL, Heroku and SQLite3.
| Details | |
|---|---|
| Description | The user table stores the details of the users which includes user ID, username and email. These attributes must be unique to each user. |
PrimaryKey |
User ID. This is generated in our backend to uniquely identify a user. |
| Details | |
|---|---|
| Description | The Organization will be interacting with the folders and file manager. |
PrimaryKey |
Organization ID + User ID |
| Extra Note | An organization can have multiple parents and multiple children to allow a more flexible way in setting permission controls. However, a cycle whereby an organization may become a parent or grandparent or ... ancestor of itself. The solution for this use case will be handled by the back-end to prevent this. |
| Details | |
|---|---|
| Description | A session is a timed event that an organization can create for a single file. |
PrimaryKey |
Session ID |
|Extra Note|The session password can act as a first line of authorization for the audience like in the use case of a lecture session or a project meeting.|
| Details | |
|---|---|
| Description | To group the files |
PrimaryKey |
Folder ID + Organization ID |
|Extra Note|The folder main role is to store permission data for our software engineers to identify permission. Similar to folders in Windows, the folder are unique individuals who can only have at most 1 parent folder.
Similar to the organization, it is possible for a folder to be an ancestor of itself. The solution will be handled by the back-end of the software to prevent this.|
| Details | |
|---|---|
| Description | To handle files that the organizations (users) have created. |
PrimaryKey |
Organization ID + File ID |
|Extra Note|The file manager main role is to store permission data for our software engineers to identify who has the permission to access the file.|
| Details | |
|---|---|
| Description | Store images |
PrimaryKey |
Image ID |
| Details | |
|---|---|
| Description | To store text by paragraphs. |
PrimaryKey |
File ID + Text ID |
| Extra Note | The implementation will not be discussed in the ER diagram but the paragraphs order will be stored in another entity and each paragraph will be tied to some annotations. |
| Details | |
|---|---|
| Description | To store the order of the paragraph texts |
PrimaryKey |
File ID + Order Number + Paragraph Number |
| Extra Note | The paragraph order is useful to act as a pointer to keep the annotations in-line. |
| Details | |
|---|---|
| Description | To categorize the annotations. |
PrimaryKey |
Annotation ID |
| Extra Note | The annotations will be pinned to the paragraph to ensure it will not be messed up when the user sorts its notes. |
| Details | |
|---|---|
| Description | To store the annotation files |
PrimaryKey |
Annotation Number |