Data Model Creation

From crowdresearch
Revision as of 12:54, 18 April 2015 by Avrimmit (Talk | contribs) (Team Members)

Jump to: navigation, search

Introduction

This section contains tasks associated with creating various data models and schemas. Following example shows how to structure the attributes for various entities.

Tasks:

  1. Please add your proposal under the sections below
  2. Include the GitHub link for implementation

Technology:

  1. PostgreSQL

Targeted Modules & Focus

  • User Management
    • Login
    • Create Account
    • User Roles
    • User Profiles
  • Dashboard for workers
    • List of Available jobs
    • Selecting a desired job.
    • Executing & Submit the job
    • Profile with list of jobs completed and payment accumulated.
    • Publish tasks
  • Dashboard for requestors
    • Create Project & design Tasks
    • Create Qualification
    • Publish Tasks
    • Review Results
    • Mechanisms for viewing the jobs that workers executed.
    • Profile with list of jobs that were requested and the amount of money spent on each.
  • DataModels supporting above functionalities


Data Model 1

Data Model Example

Fig 3. Data Model Example
  • User - This is the Django User model, it provides functions like create_user and it's used for login/logout.
  • UserProfile - Inherits from the User model, it extends it with more information about the user.
  • Worker - Inherits from the UserProfile, this will be the worker profile.
  • Requester - Inherits from the UserProfile model as well, it contains the requester profile. *
  • Skill - This model is used to maintain the skills, allows subskills as well.
  • WorkerSkill - Maps the skills to workers, it allows skill verification.
  • Tests - These will be tests for skills WorkerTest - Maps the tests to workers, the result and so on.
  • Project - This is the project itself which is led by one Requester ProjectRequester - defines the requester and the collaborators of a project.
  • ProjectModule - A module is a set of HITs, this defines the project modules, with a description, template, status and so on. A project can have many
  • Template - this will be the template model which contains the defined templates by the user (the html source).
  • Qualification - There are module based qualifications and there can be as many qualifications as needed.
  • QualificationItem - Defines the actual qualification parts, using the workerAttribute, operator, value1 and value2. This allows the requester to create any kind of qualification e.g. username='john', age>20, country = 'USA', approvalRate>'80%' and so on. There will be complex qualification clauses combined with binary operators. #There will be an option to specify the type of the Qualification it could be STRICT or ALLOW_APPLICATIONS, where strict would make these hits appear only to the workers who pass this qualification, and *ALLOW_APPLICATIONS would allow for example new users to apply for the modules even though they don't fullfill the requirements of the qualifications.
  • WorkerApplications - Here we *maintain the worker applications for modules/projects, the requester can review these applications and approve or deny them. Approving them would mean that a new qualification *would be added to the module itself username='approved username' ORed with everything else.
  • HIT - This will be the hit model, every hit belongs to a project module. HITWorker - *This will contain the workers which are working on the hits.
  • HITResult - Maintains the results submitted by the workers, it works together with the specified template for the module. *There will be result requirements which are pretty much the same as "qualifications", but they will be applied to the results instead of workers, e.g. SELECTLIST1 IS NUMERIC AND *SELECTLIST1 BETWEEN 1 AND 10 TEXTFIELD1 is $ANIMAL_NAME and so on.

Link to GitHub

Data Model 2

In this section we will define the user model in more detail.


Users data model.png

The aim of this model is for it to be extensible, non-redundant and modular.


A single user is defined, from which the "type" determines if it is a requester or worker (or maybe a moderator in some particular cases). The same basic information need to be created for all users. From there, each user can have other modules. All users require a "work profile", which will keep track of their skills, their reputation or rating and other specification necessary for them to depict when they are working. Users might also require a "social profile". This profile is very useful in cases where teams want to work on empathy or other social aspects. Linked to it are activities related on a social basis. More information can be acquired from this model (e.g. all users involved in a particular activity) if the right query is performed.

Data Model 3

In this section we will define the HITS model in more detail.


Hits data model.png

The aim of this model is for it to be extensible, robust, non-redundant and modular.

A single HIT and its characteristics are defined under "HIT". Pricing is considered as a separate table or module in case some teams want to incorporate their own pricing methods and tactics. The "HT_Q&A" keeps track of questions asked about HIT and how they were answered.

Data Model 4

This is another proposed overall data model design.


Pentagram data model.png

The diagram is self explanatory w.r.t. in attributes ,primary/foriegn key relations.The SUBMISSION_TABLE is created at runtime for any JOB entry created. Multiple SUBMISSION_TABLEs are created, one for each JOB .This involves the time taken for running DDL queries at the RDBMS level,which is acceptable at the time of creating tasks.

Team Members

  • Directly-Responsible Individual (DRI) Durim Morina
  • Coordinators (horizontal team): Gaby, Elsa, Neil, Saiph, Durim
  • Systems team will test all the models before they goto branch
Member Model Link to the Git
Saiph
Gaby
Saisudeep
Durim
Elsa
Soroosh
Karthik Bhat
Nitin Jamadagni
Saisudeep
Karthik Senthil94