Changes between Initial Version and Version 1 of RelationalModel

Timestamp:

04/18/26 20:26:24 (2 weeks ago)

Author:

231141

Comment:

--

RelationalModel

@@ +1 @@
+= Relational Model =
+
+== Relational diagram ==
+
+[[Image(RelationalModel.jpg)]]
+
+== Descriptive documentation and argumentation ==
+
+=== User and Role Modeling ===
+The system models all users through a central User entity, which contains common attributes such as email, name, and contact information. The roles of users are separated into Client and Worker entities, both referencing the User entity. This approach avoids data duplication and allows flexible role management.
+
+=== Task Request and Offer Mechanism ===
+The system uses a unified !TaskOffer entity to model all interactions between clients and workers related to task assignment.
+
+A !TaskRequest is created by a client and represents a request for a specific task, including details such as category and location. While a !TaskRequest is in an open state, both clients and workers can initiate interactions through !TaskOffer.
+
+Clients can actively send !TaskOffers to selected workers suggested by the system after creating the !TaskRequest through the matching system mentioned later. These offers include a proposed price and represent direct invitations to perform the task.
+
+At the same time, workers can browse open !TaskRequest entries and submit their own !TaskOffers, effectively applying for the task by proposing a price.
+
+Each !TaskRequest can have multiple !TaskOffers, potentially with different prices and initiated by either clients or workers.
+
+Sending a !TaskOffer does not assign the task. A !TaskRequest remains open until one of the offers is accepted.
+
+The acceptance of a !TaskOffer depends on the direction of the interaction:
+ * workers accept offers that were initiated by clients
+ * clients accept offers that were initiated by workers
+
+In the case of client-initiated offers, multiple workers may receive offers simultaneously, but the task is assigned to the first worker who accepts the offer. Once an offer is accepted, all other offers related to the same !TaskRequest are automatically discarded.
+
+In the case of worker-initiated offers, the client reviews all submitted offers and selects one worker. The task is assigned only to the worker whose offer is accepted by the client.
+
+This mechanism enables a negotiation-like system. If a worker does not agree with the proposed price, they can submit a new !TaskOffer with different terms.
+
+Once a !TaskOffer is accepted, it is converted into a !Task, and all other offers related to the same !TaskRequest are discarded.
+
+This ensures that each !TaskRequest results in exactly one assigned worker, while still allowing flexible and parallel interaction between clients and workers during the offer phase.
+
+=== Category and Matching ===
+Tasks are categorized using the Category entity, while workers can be associated with multiple categories through the Worker_Category relationship. 
+
+Each worker specifies their location and a service radius, which defines the geographical area in which they are willing to accept tasks. Task requests also include location data.
+
+This enables efficient matching between task requirements and worker capabilities, as well as filtering based on location constraints, ensuring that task offers are sent only to suitable and geographically relevant workers.
+
+=== Pricing and Badge System ===
+The system includes a Badge entity that determines the minimum price a client or worker can offer within a specific category. Each worker can have different badges for different categories, modeled through the Worker_Badge relationship.
+
+This ensures that pricing is controlled and reflects the worker’s experience and rating history.
+
+=== Task Lifecycle ===
+The Task entity represents the execution phase of the process. It contains attributes such as status, start time, and completion time. This allows tracking of the full lifecycle of a task from acceptance to completion.
+
+=== Communication ===
+A Message entity is used to support communication between users. Messages are linked to a specific Task, ensuring that communication is contextual and organized.
+
+=== Payment System ===
+The Payment entity handles financial transactions between clients and workers. It includes payer and payee references, as well as payment status and amounts. The relationship between tasks and payments is managed through the Task_Payment entity.
+
+=== Reviews and Trust System ===
+After completing a task, both users can leave a review through the Review entity. This enables a mutual rating system that contributes to building trust within the platform.
+
+For workers, ratings are used to calculate badges within specific categories, which directly influence the price range of services they can offer or can be offered in that category.
+
+For clients, their rating is visible to workers during the offer phase, influencing workers’ decisions when accepting or rejecting task offers.
+
+This mechanism ensures accountability and encourages reliable behavior from both sides.
+
+=== Complaint Handling ===
+The Complaint entity allows users to report issues related to a task. This entity is linked to both users and tasks, enabling proper tracking and resolution of disputes.
+
+=== Notifications ===
+The system includes Notification and NotificationType entities, allowing users to receive updates related to tasks, offers, and payments. Notification preferences are managed through NotificationPreference.
+
+=== Location Handling ===
+The Location entity is used to store geographical data such as address and coordinates. It is linked to both users and task requests, enabling location-based matching.