How can i design a database schema to handle employee scheduling? - sql

I'm working on an employee scheduling client to help some folks create a schedule for their job. It should be able to count the hours each employee is scheduled and keep track of this.
The important part is this: I have one database table, employees, that stores employee information, such as employee id, name, and contact information. The difficult part is designing a table that stores the schedule itself. I thought about designing a table where each entry has an employee id, a date, and a shift time, but this seems incredibly inefficient.
What i am asking is this: How can i design the database and tables to allow for multiple employees per shift time, and multiple shifts per day? Also, how would i access this multiple table information from my code?
PERTINENT INFORMATION:
I am using c++ with Qt libraries.
It is in progress, so anything i have can be changed to allow for simpler database structures or access.

Related

SQL - MS Access Form design - add data of ISA relationships

I'm taking a DBMS course and I need to design and build my own DB. I have a database for a hospital where doctors,nurses,support staff etc are in a ISA relationship to an Employee entity with the rest of the data like the name, address , salary and the rest of the employee data.
Designing a form, I want to be able to add an employee with all of their data in one form.
Is there a way to do a "conditional table" of sorts where if i select "doctor" from a drop-down i get to add to the doctor table too, and same for the rest of the entities under the ISA relationship?
Thx!
As a general rule, when dealing with data, you do NOT flip or switch tables for a given form or relatonal database design.
So, for example. If I have a table of customers. Well, now if I want to mark some of the customers as plumbers, and others as doctors? I don't create two tables.
All I would do is add ONE column to that customers table and it would simply allow me to set the type of customer. The reason for this design is "many" but some significant reasons are:
For each new type of customer, you would not create a new table. Worse, all of the forms, the reports, the SQL, the code you write? Well, all of that code would have to be modified EACH time you create a new table. So, you SIMPLY cannot adopt a design in which the concept of changing a table is part of that process.
Forms are bound to ONE table. For related data, you in most cases will use a sub form.
So, think of even a accounting system. They can have huge numbers of customers, and as a result, you can "query" that table to give you all customers. Or you might ask how many accounting firms are in the customer list. Or make a report that summeries by customer type a "count" of each type of customer.
So, buidling forms, or reports? They cannot on the fly "change" the tables they are using.
So, in place of a tables called:
SalesJan
SalesFeb
SalesMar
etc.
Well, now you can't query sales from Jan to mar, because the data is in different tables.
So, what you do is have ONE table called "sales", and you add ONE column of the date. Now, at the start of each new month, you don't have to create a new table.
Now, of course in some cases it makes sense to create a separate table. For example, a table of customers, and a table of employees in a database is just fine. It makes sense in this case to use two tables, since the information about a customer and what they can do and the kind of information is VERY different then how you would deal with employees.
So, with above? Well, if I need to print mailing labels for all customers and all employees? That would require two different reports. And very likely the table structure for the two tables is different.
Bottom line:
If you working on design or form or report? And you needing to try and change the table that the form/report/code etc is going to operate on? This is a sign that your design approach has gone complete off the rails and is the wrong design.
So, in the case of doctors, nurses etc.? Well, they are all hospital staff, and MOST of the basic information about such employees will be common, much the same, and thus a SINGLE table of "employees" makes the most sense. You would only need a nice "employee type" combo box on that one form, and thus you can add/enter/edit/search any employee in that one table.
The fact that you "want to search" for a employee show that all these people "are" employees and thus belong in one table. And the basic information about all employees is going to be the same anyway. If you find you are attempting to create a new table but with near identical structures over and over, then just like a new table for each month sales, or a new table for each new kind of employee? Simply add the "one" column that allows you to make that distinguish, and not a whole new table.
Now one COULD even attempt to put patients in the same table, but then again, dealing with patents as opposed employees is a considerable different kind of "thing".
So employees are employees - even different kinds. (manager, cleaning staff etc.).
And patients are patients - even different kinds (long term care, emergency etc.).

design database model and related sql queries

Develop the rdbms for the administrative structure of an organisation. Each employee belong to a certain dept and is associated with multiple projects. each manager is an employee who manages several projects as well as several employee. Each project executes for a certain duration. employees stay in organisations for a certain duration.
Queries:
find no of employees who has worked is every project
find max no of employees working at a time in project 'x'
find the unproductive managers who manages less than 5 project in last 1 year
find the dept whose employees handled maximum project in last 1 year
edit:
I am not able to decide how to deal with the time constraint in the last 3 queries.
I have made 3 tables:
EMPLOYEE with attributes: emp_id,name,dept,manager_id where emp_id is primary key and manager_id is self referential foreign key
PROJECT with p_id,p_name,manager_id where p_id is primary key
ALLOTMENT with emp_id,p_id where both attributes make a composite primary key
The above helps me answer the first query but how do I add the time constraints to answer the rest of the queries. Do I need date-time attribute or a simple duration attribute will work or something else is required here? please help.
ALLOTMENT is the intersection between EMPLOYEE and PROJECT. It records the employees working on a project.
However, employees join projects and leave projects. Projects grow and shrink in their resourcing. So clearly ALLOTMENT needs columns to indicate the time span of a particular assignment, say START_DATE and END_DATE.
Once you add those columns you will be able to answer the remaining questions. Some of them will remain tricky (especially 2) but at least you will have the information required.
Incidentally, you probably ought to have a DEPARTMENT table but you can write those queries without it. Also, in real life a PROJECT would have an initiation date and (we hope) a completion date. However they too are not required for the queries you have to write.
In the project table consider adding two columns start_date and duration| End_date of the project. I think this will be sufficient for you to work through the last 3 queries.
You can consider having another column No_of_Employees_under_project in project table, which is normalized and will dynamically reflect employees joining or leaving the project. This column should be added only after measuring the gain against the cost of normalization.

How do I filter out records from Table B based on a field in Table A?

Because it may be relevant, the DBMS I am using is Teradata.
I have two tables named Table A and Table B. Table A contains employee personal and company data (company-issued ID, name, pay type, etc.), and Table B
contains information concerning the jobs each employee has held or is currently holding. The primary key for both tables is the employee's company-issued ID number.
Currently, I am trying to write a query that partly entails retrieving an employee's current position.
This seems like it should be easy, especially since Table B stores "effective" dates and "expiration" dates for each job, however, there is a problem.
In the company I work for, there are two different systems used to track employees. Each system is identified by human resources code.
The codes for each system and which employees are included in that system are as follows:
If you work in a retail store in a non-managerial position, your
system is identified by code "1".
If you work in a retail store in a
managerial position or you work for corporate, your system is
identified by code "2".
Each record in Table B has a field indicating which HR system that particular job is tied to.
Occasionally, someone working at a store in a managerial position may need to have a record in the system identified by code "1" in order to have access to
some store-level systems they need to do their work. When this happens, another job record is added to Table B for that employee that is tied to system "1". In such cases, for that particular employee, their two most current records in Table B will correspond
to their actual position within the company while the other will be the additional record created for them. Additionally, these records often have "effective" dates that are later than the "effective" date for the employee's actual job.
In my query, I need to obtain each employee's actual job from Table B. It is known that every genuine system "1" employee is hourly, while everyone in
system "2" is salaried. Table A has a field indicating each employee's current pay type.
So, basically, for each employee included in my query, I need to filter out any cases where an employee has a system "1" record in Table B while Table A indicates that
the employee is salaried and not include them when calculating the employee's actual current position.
I apologize for the "wall of text" here, but I feel this problem is fairly complex, so I wanted to be sure you were aware of all the relevant details.
Admittedly, I am still learning SQL, so if there are any constructs or aggregate functions that can help, please let me know.
Thank you for your time.

Timesheet Database schema

There is an old timesheet application being used in my company and i am going to rewrite it in asp.net.
There are other tables which can be linked to new Timesheet table like employee table but my main concern here is the Project and Project_Activity table.
In the current system, there is a one project and a activity table which are linked to the timesheet table seperatly and user has to spend alot of time on selecting activities code they worked on for specific project.
I have came up with the new idea; Project manager will have to fill up a project template and link all the activities code with the one project before starting this project. This way user will have to select the project only and it will automatically bring the associate codes for them.
Here is the logical schema design.
I like to know if this design will work okay? and is it okay to link Project_Activity table with timesheet?
PROJECT
PK_PROJECT_ID,
NAME
PROJECT_ACTIVITIES
PK_PA_ID,
DESCRIPTION,
FK_ACTIVITY_ID,
FK_PROJECT_ID
ACTIVITIES
PK_ACTIVITY_ID,
DESCRIPTION
TIME_SHEET
PKID,
EMP_ID,
FK_PK_PA_ID,
DATE,
HOURS
PROJECT --> PROJECT_ACTIVITIES <-- ACTIVITIES
|
|
|____TIME_SHEET
Note: Timesheet table has many other fields which are not a part of this question.
I'm assuming an Activity can refer to only one Project?
If so, you don't really need the Project_Activity table, just put the foreign key to the Project table in the Activity table.
If an Activity can refer to more than one Project, then your schema is fine, you have effectively decomposed the many-to-many relationship between Project and Activity. :)
In general the schema is OK. I would not use the naming convention you have, as I find it hard to read. No harm in using full words, but that's an aside.
What I would change is the Timesheet table. Do this instead:
PKID,
EMP_ID,
FK_PK_PA_ID,
STARTDATE,
ENDDATE
This will allow you to easily query who was doing what during a given time more easily. You can also allow records to have a NULL ENDDATE to show an activity currently being worked on.
I would add a trigger to make sure that for the same EMP_ID, a record's STARTDATE and ENDDATE never come between a STARTDATE and ENDDATE of other records (no overlap).

Creating Table Relationships

I am working on a VB.net (VS-2010, Win XP Pro 2 SP3), Employee Management Project. I need to keep track of Employee Leave Attendance and also each Equipment assigned to an Employee. How can I achieve this using SQLlite.
It will be very useful if you could provide me with examples as I am completely new to the field of SQL and VB.net
I think this can be done with two tables where one has the primary key while the other has a foreign key, but I am not sure. Also how many tables will I need for storing data in Leave and Equipment Form.
I went through other questions but I was unable to figure out a solution for my problem.
(Sorry, I cannot provide with images as this site prevents me from posting images without 10 reps)
Most problems are only as complex, and as simple as you make them. Out of habbit, nearly all tables end up with a unique ID field. There are exceptions, which I will call "link" tables, eg, ones that provide connection details between two data tables.
Now, in your senario
You would need a "holiday" table, where each row will contain the employee unique ID and either a start/finish date, eg, if they take half a day, it needs to be visible, or, just a year and value, eg in 2011, I booked, 2 lots of 35 hours, and 1 lot of 4 hours eg, Ive taken 2 weeks and half a day.
For the equipment, you would need a data table, since an item can only got to 1 employee, it depends if you're going to use this for booking or not, but if its just like a library, eg I currently have a loaner laptop, then you can just have an employee field in the equipment table. If you need a booking system, then you would require link tables and more complex.
Best way to work out your tables is to try and group your data, and then write the items on peices of paper and see how you as a human do it. After a while you end up able to do so in your head.