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).
Related
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.
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.
I am building a database for contracting company. I am facing a problem with the following situation:
For each project, there are many activities and similarly for each activity there are many sub-activities.
For example, Hospital building construction is the project. One of its activities is the emergency building construction. This activity has many sub-activities; one of them is electrical wiring. I decided to create the following tables:
Project and Activity. These two tables have the relation many-to-many. Therefore, I created a table called FollowUpSchedule which has Project ID and Activity ID.
My question is how to build the Sub-activity table and connect it to the activity? Should I create another table that has the activity ID and the sub-activity ID?
As i understood it, i can think of two options:
First solution
Create another table to hold the sub reports, as you mentioned.
Activity Table
ActivityID
Activity Name
SubActivity Table
ID
ActivityID
Name
Second solution (I prefer it)
Change the Activity table to support child parent structure.
If every sub activity is belongs to parent activity you can implement hierarchy structure
Your table structure should be something like this:
ActivityID
ParentID (0 - in case of root)
Activity Name
And etc....
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.
For my application there are several entity classes, User, Customer, Post, and so on
I'm about to design the database and I want to store the date when the entities were created and updated. This is where it gets tricky. Sure one option is to add created_timestamp and update_timestamp columns for each of the entity tables but that isn't that redudant?
Another possibility could be to create a log table that stores this information, and it could be made to contain keep track of updates for any entity.
Any thoughts? I'm leaning on implementing the latter.
The single-log-table-for-all-tables approach has two main problems that I can think of:
The design of the log table will (probably) constrain the design of all the other tables. Most likely the log table would have one column named TableName and then another column named PKValue (which would store the primary key value for the record you're logging). If some of your tables have compound primary keys (i.e. more than one column), then the design of your log table would have to account for this (probably by having columns like PKValue1, PKValue2 etc.).
If this is a web application of some sort, then the user identity that would be available from a trigger would be the application's account, instead of the ID of the web app user (which is most likely what you really want to store in your CreatedBy field). This would only help you distinguish between records created by your web app code and records created otherwise.
CreatedDate and ModifiedDate columns aren't redundant just because they're defined in each table. I would stick with that approach and put insert and update triggers on each table to populate those columns. If I also needed to record the end-user who made the change, I would skip the triggers and populate the timestamp and user fields from my application code.
I do the latter, with a "log" or "events" table. In my experience, the "updated" timestamp becomes frustrating pretty quick, because a lot of the time you find yourself in a fix where you want not just the very latest update time.
How often will you need to include the created/updated timestamps in your presentation layer? If the answer is anything more than "once in a great great while", I think you would be better served by having those columns in each table.
On a project I worked on a couple of years ago, we implemented triggers which updated what we called an audit table (it stored basic information about the changes being made, one audit table per table). This included modified date (and last modified).
They were only applied to key tables (not joins or reference data tables).
This removed a lot of the normal frustration of having to account for LastCreated & LastModified fields, but introduced the annoyance of keeping the triggers up to date.
In the end the trigger/audit table design worked well and all we had to remember was to remove and reapply the triggers before ETL(!).
It's for a web based CMS I work on. The creation and last updated dates will be displayed on most pages and there will be lists for the last created (and updated) pages. The admin interface will also use this information.