SQL Database Design Timesheet Employee vs Crews - sql

First question here so please let me know how to ask the question better if below is unhelpful.
TLDR - Should I have separates employee times tables for employees assigned to crews and those who are not?
I'm trying to design database, following 'Database Design for mere mortals' book, that tracks employees times. I'm trying to replace the weekly timesheets and crew paper sheets (with start & end times for the crew) being used. There are also individual employee weekly timesheets for those not assigned to crews. Also crew sheets sometimes have an asterisk with if someone is sick etc.
There is a relationship of Projects to crews (1:N) and for the individual employee not assigned to crews are assigned to the project.
Employees are assigned to crews, normally 1:1 but headache comes when 1:N.
'Has' Relationships
So at the moment the are different types of crews say A, B, C, D, E.
Crews D & E will just fill in weekly timesheets (project, names and times, so crews D and E will both be on this same project) and the daily sheets don't include times. Sometimes like 10% of the time employees will be on both D & E on the same day.
A, B, C will have daily times on the daily sheet, but if an employee is on crew C these times take precedance over the times on sheets A or B (if they are also on A or B).
The obvious answer to have {employee, datetimestart, datetimeend} won't work as I care where the times have come from (crew, individual if exception to the crew e.g. sick, individual not assigned to a crew).
I can extend to have {employee, crewtype, datetimestart, datetimeend} this doesn't take care of when employee is both on D & E. I can put DE or F in this case?
Then how do I deal with those assigned to the project only?
if I have {employee, crewtype, projectref, datetimestart, datetimeend} the projectref is redudant and can be derived from crewtype when this is not null. Is this a reasonable approach or would having separate tables be better?
EDIT - or should I have one table {crewid, datetimestart, datetimeend} - derive the times for employees from the crew-employee relationship, and have a separate {employee, datetimestart, datetimeend, category} with category saying if exception (e.g sick) or non-assigned individual?

There are a lot of complicated rules in this description. If you want to create a schema that will never break these rules it will likely be a very complicated normalised schema. I would suggest that some of the rules will be best catered for in your application logic.
In terms of how you store the date, remember that you always need to cater for the exception cases, so something that happens 10% of the time, or 1% or one in a thousand still needs to be catered for, otherwise you just cant save the data.
I would tend to design for the most detailed level, which might be employee,crew,project,date,times, and possible also add an allocation column that defaults to 1, but could be 0.5 if the person is half allocated to two crews at the same time.
You could then write queries so that if a person is allocated to a crew, they get the crew time by default unless they have some overridden values, or whatever other rules you need.
Really, this is the sort of iterative modelling you would do with your business users as you tease out the design. Not always easy in a real-world scenario.
Sorry there is no definitive model here, but maybe a few tips to consider that might help along the way. Good luck with it.

Related

Assigning multiple values to a single planning entity instance

I'm working on a project in OptaPlanner which is close to the nurse roster example. Besides assigning the employees to shifts i also need to assign the employees to small assignments within the shift. The required number of employees that need to be assigned to the small assignments is not an integer it is a rational number , and every employee besides having a skill (that is required by the small assignment) has a performance meter for that skill that is also a rational number.So the employees needed to meet the required number can be variable based on their performance ,and i can't create N different instances of the small assignment and let OptaPlanner assign an employee to it.
Is there a way to create a single instance of the small assignment ,and have something like a list where employees can be added or removed and the required number is changed accordingly based on the performance that the employee has for that small assignment,in other words can the planning variable be a list that contains the employees assigned?

tour start as an additional planning variable in Optaplanner VRPTW - a good idea?

Hi and happy new year to all Optaplanner users,
we have a requirement to plan tours. These tours contain chained and time-windowed activities (deliveries) executed by a weekly changing number of trucks.
The start time of a single tour can vary and is dependent on several conditions (i.e. the goods to be delivered must be produced, before the tour can start; only a limited number of trucks can be served at the plants gates at the same time; truck must be back before starting a new tour). Means: also the order of tours can vary and time gaps between the tours of a truck can occur.
My design plan is, to annotate TourStartTime as a second planning variable in Optaplanners VRPTW-example and to assign TourStartTime to 2-hours time grains (planning horizon is 1 week and tours normally do not start during night times; so the mentioned time grains reflect a simplified calendar for possible tour starts).
The number of available trucks (from external logistic companies) can vary from week to week. Regarding this I wanted to plan with a 'unlimited' number of trucks. But the number of trucks per logistic company, that can be actually assigned with deliveries, should be controlled by a constraint (i.e. 'trucks_to_be_used_in_parallel').
Can anybody tell me, if this is a feasable design approach, or where do I have to avoid traps (ca. 1000 deliveries/week, 40-80 trucks per day) ?
Thank you
Michael
A second planning variable is possible (and might be even the best design depending on your requirements), but it will blow up the search space and maybe even custom course grained moves might become needed to get great results.
Instead, I 'd first investigate if the Truck's TourStartTime can be made a shadow variable. For example, give all trucks a unique priority number. Then make a Truck's TourStartTime a shadow variable: the soonest time a truck can leave. If there are only 3 lanes and 4 trucks want to leave, the 3 trucks with the highest priority number leave first (so get the original TourStartTime, the 4th truck gets a later one).

Coupling between classes

Let's assume we have two classes: Patient and MedicalExamination. We want to get all examinations for a specific patient. Which one is better:
patient.getExaminations();
examination.get(patient);
How would you implement the second way? It would force you to loop over all examinations and see which one are about your patient.
The first method however will allow each patient to hold its own examinations and thus immediately retrieve it. Therefore my preference goes to this method.
Give the object as much information as you reasonably should (without lowering security concerns) so it can operate on its own.
Basically, an examination cannot exist without a patient. Therefore Patient would be the root entity of the aggregate Patient - MedicalExamination, and as such Patient (or PatientRepository) would be the way to retrieve patient details and examinations:
patient.getExaminations();
A doctor usually have a file for each patient, in each patient's file, there is a list of medical examination.
So, you get the patient from the doctor office, then you get the examination from the patient's file.
so:
patient.getExaminations();

query for development of a rota application

how can we prepare a rota application which changes the shift so that all the employees get to work in different shifts and in the month end the number of shifts done by all the employees should be the same..
Any help?
Okay, if I understood correctly, the problem you want to solve is the following:
Input:: You define S different Shifts for a Month M, and you have E employees.
Output:: Given the input, you have to define a schedule for each employee, that is, assign Shifts from S to them along the month M. When doing so, you must meet two objectives:
All Employees get to work in different Shifts
The total amount of Shifts assigned to each Employee must be the same
To achieve this, there are lots of possible algorithms. Off the top of my head, here's one in C-style pseudocode (you write in VB.NET):
CircularArray shifts = GetDefinedShifts();
foreach(day in Month){
foreach( employee in Employees ){
employee.Schedule.AssignShift( Month, day, shifts.Current() );
shifts.Next();
}
}
A CircularArray goes back to the first element when you call Next standing on the last one. However, this algorithm fails if #E == #S: every employee gets always the same shift. So it's not that easy. But this naive algorithm can get you started thinking a better one. If I come up with something better, I'll post it.
On the other hand, why reinvent the wheel? There are open source solutions available, such as this one. And there's a list of similar software here.

Recurring Orders

Hi everyone I'm working on a school project, and for my project I chose to create an ecommerce system that can process recurring orders. This is for my final project, I'll be graduating in May with an associates in computer science.
Keep in mind this is no where a final solution and it's basically a jumping off point for this database design.
A little background on the business processes.
- Customer will order a product, and will specify during checkout whether it is a one time order or a weekly/monthly order.
- Customer will specify a location in which to pick up their order (this location is specific only to the order)
- If the value of the order > 25.00 then it is accepted otherwise it is rejected.
- This will populate the orders_test and order_products_test tables respectively
Person on the back end will have a report generated for deliveries for the day based on these two tables.
They will be able to print it off and it will generate a list of what items go to what location.
Based on the following criteria.
date_of_next_scheduled_delivery = current date
remaining_deliveries > 0
Once they are satisfied with the delivery list they will press "Process Deliveries" button.
This will adjust the order_products_test table as follows
Subtract 1 from remaining_deliveries
Insert current date into date_of_last_delivery_processed
Based on delivery_frequency (i.e. once, weekly, monthly) it will change the date_of_next_scheduled_delivery
status values in the order_products_test table can either be active, hold, or canceled, expired
I just would like some opinions if I am approaching this correctly or if I should scratch this approach and start over again.
A few thoughts, though not necessarily complete (there's a lot to your question, but hopefully these points help):
I don't think you need to keep track of remaining deliveries. You only have 2 options - a one time order, or a recurring order. In both cases, there's no sense in calculating remaining deliveries. It's never leveraged.
In terms of tracking the next delivery date, you can just keep track of the day of the order. If it's recurring -- monthly or weekly, regardless -- everything is calculable from that first date. Most DB systems (MySQL, SQL Server, Oracle, etc) support more than enough date computation flexibility so that you can calculate this on the fly, as opposed to maintaining such a known schedule.
If the delivery location is only specific to the order, I see no use in creating a separate table for it -- it's functionally dependent on the order, you should keep it in the same table as the order. For most e-commerce systems, this is not the case because they tend to associate a list of delivery locations with accounts, which they prompt you about when you order more than once (e.g., Amazon).
Given the above, I bet you can just get away with 2 of your 4 tables above -- Account and Order. But again, if delivery locations are associated with Accounts, I would indeed break that out. (but your question above doesn't suggest that)
Do not name your tables with a "_test" suffix -- it's confusing.