Difference between revisions of "Data Model Creation"
|Line 10:||Line 10:|
==Team Members ==
==Team Members ==
Latest revision as of 14:18, 10 May 2015
This section contains tasks associated with creating various data models and schemas. Following example shows how to structure the attributes for various entities.
- Build the data model Django classes
- Include the GitHub link for implementation
- 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||User Profile, Worker, Requestor||dataModelsPrototypes|
|Durim||Project, Module, HIT, HITWorker, HITWorkerResults, WorkerModuleApplication, ModuleCategory,Qualification, Currency, UserPreferences||betzy-models|
|Elsa||Project, Module, Template, TemplateItem, TemplateItemProps, ActivityLog, ProjectCategory, Category, Qualification, QualificationItem||betzy-models|
|Karthik Bhat||User(additonal features if any), WorkerTest|
|Nitin Jamadagni||User(additonal features if any), WorkerTest|
|Saisudeep||User(additonal features if any), WorkerTest|
|Karthik Senthil94||User(additonal features if any), WorkerTest|
|Neil||Updated the record timestamps tracking||turingModel-timestampUpdates|
Targeted Modules & Focus
- User Management
- 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
- 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.
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.
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.
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.