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....
Related
I'm trying to create a small company database as a personal learning experience in PostgreSQL.
I'm trying to follow Derek Banas tutorial (which is really helpful) but there is something different how my products are processed.
So far I've made these tables as shown in the image Table list
In the components table I have a row 'where_used' where I wanted to put an reference INT to the product where it is used.
But as you can see, some components are used in multiple products. And I can only store one value?
So my question is:
Can someone point me in the right direction on how to get this working?
I tried googling for a solution,
But as I'm such a noob I do not know how to get the right keywords for the search...
In data modeling this technic of having multiple sub entities from a super entity is called Inheritage...
As an exemple, you can have a table that is called "Vehicle" and some child tables that are called "Planes", "Boats", "Car".
The main table (Vehicle) will have shared properties
The "Plane" table will have some properties specific to planes and so on...
Of course the Primary KEY of vehicle will be shared in an exclusive mode betwwen "Planes", "Boats" and "Cars"...
From a child point of view, the tables will have a PRIMARY KEY that is also a FOREIGN KEY.
So in your case you have a table 'COMPONENTS' that is linked to the table 'PRODUCTS'
You want to have a column in your table 'COMPONENTS' that you'll call 'where_used' that say if the component is used in x or y product.
There is different ways of doing it but this is what I would do :
Basically, you'll need 3 tables :
The first one is "COMPONENT" which store unique component values
The second one is "PRODUCT" which store every unique products
The third one is "COMPOSITION" (or whatever name you like) which is the associated table between "COMPONENT" and "PRODUCT" which will look like this :
COMPONENT_ID
PRODUCT_ID
1
1
1
2
2
3
2
1
Hope someone can guide a noob as I have done alot of googling and searching here as well but here's what I am trying to accomplish.
I have a program that upon registering it creates a table that is yours in the database. A workerID is generated upon registration on that workerID gets attached the table name that gets created for you.
For example after you register you get assigned a worker ID number of 10001. A table is then created for you named DB_10001.
Easy enough.
Within Table DB_10001 there is a column that Identifies who the project creator was (ID'd by workerID).
Worker ID: 10001 creates his or her own projects but sometimes, a project is assigned by another workerID and it is placed in DB_10001 table.
I want to create a trigger that if the PROJECT CREATOR (which is a column in DB_10001) is not the owner of the table (WorkerID: 10001), to be notified that the owner of that table (10001) of a pending project to they can either accept or reject.
Is it possible to put this trigger when the table is created???
Thanks in advance,
I'm making a database where I need to create a relationship between 'Modules' and 'Degree' - basically the modules make up the degree - such like:
Module CS 1 is part of Computer Science
Module CS 2 is part of Computer Science
Module PHIL 1 is part of Philosophy
etc.
My table format is as so:
Modules -> Form -> Degree
Modules contains Module Name, and Module ID (PK)
Form contains Module ID and Degree ID (both FK)
Degree contains Degree Name and Degree ID (PK)
I appear to have the issue that regardless, there will be a many-to-many relationship, as there will be multiple Module ID's which correlate to one Degree ID.
Is there a way around this?
This would not be a many-to-many relationship, in fact, that is the entire purposes of the "bridge" table Form.
See the picture below. In the basic ER Diagram (Entity Relationship Diagram, you can read about them here), you can see the following:
There is a ONE-TO-MANY relationship between Module and Form
(i.e., ONE Module ID can appear MANY TIMES in the Form Table, but that Module ID will only appear ONE time in the Module table)
There is a ONE-TO-MANY relationship between Form and Degree
(i.e., ONE Degree ID can appear MANY TIMES in the Form Table, but that Degree ID will only appear ONE time in the Degree table)
Your architecture and usage of a bridge table is indeed one way to eliminate a many-to-many relationship, good job.
I am fairly new with database design so thank you for all input for helping me with a little problem I have designing the structure of a database. Basically I want to set up a many-to-many-to-many relationship between 3 main tables and a forth that is linked to the third. I'll try to explain it using an example.
Suppose I have tables created to show the relationship between SCENE, ACTOR, and ACTION. SCENE can have more than one ACTOR, and each ACTOR can have more than one ACTION. This is what I have worked out so far:
Have an intermediate ScenesActors table that just lists the SceneID and ActorID (along with its own ID field [SceneActorID] as primary key).
You then have the ScenesActorsActions table which has the SceneActorID and ActionID (along with its own ID field [SceneActorActionID] as PK).
The ScenesActors table lists each actors are in which scenes.
The ScenesActorsActions table lists what they do.
Scenes --< ScenesActors >-- Actors
Actions --< ScenesActorsActions
However, in the design of my database, say Actions already has a one-to-many relationship with another table titled ActionPossibilities in which every row was a possible action that could take place (essentially making the possible actions that could occur dynamic). How then would you effectively create the relationship described above? The problem i am running into is that the primary key for the Actions table is used as a foreign key in the ActionPossibilities table. Is something like this possible under the current design?
Just have four tables: Scene, Actor, Action and ActionPossibilities. Scene and Actor should be simple: SceneID, SceneDescription, etc. Same for Actor. Action is your main table. It should have a FKs to SceneID, ActorID, and ActionPossibilitiesID (not the other way around). From there, you can query Action to get whatever combination of actors/scenes/actions you need.
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).