I'm creating 2 test tables in my oracle 10g database: STAFFS and DEPARTMENTS. Neither table has any primary keys, constraints, joins or any other thing since I don't know any of those anyway. Both are just plain tables with their fields.
In DEPARTMENTS, I have 2 fields: DEPT_NAME and DEPT_CODE. This table will serve as a reference table.
In STAFFS, I have 4 fields: STAFF_ID, STAFF_NAME, DEPT_NAME, and DEPT_CODE.
Say I change the DEPT_NAME of a staff record, how do I make the DEPT_CODE for that staff also change? I've tried creating triggers but all I get is either some mutating error thing or some recursive have been reach error.
Simple solution.
Remove DEPT_NAME column from STAFFS table.
JOIN DEPARTMENTS table using DEPT_CODE when ever you want to do so
This is called normalisation
Related
My teacher asked us to select from a 1:1 table called Employee; the supervisor and their role, and each employee they supervise with their role (employee is the primary key and those are the only 3 values in the table).
A 1:1 relationship are two tables with only one possible matching id.
It assumes that each supervisors only has one employee. so your query would look something like this.
SELECT Employee.Name, Employee.Role, supervise.Name, supervise.Role
FROM Employee
INNER JOIN supervise
ON Employee.EmployeeId = Supervise.EmployeeId
However, do note that in a real world context. This should have been a 1:N (One-To-Many) as each supervisors can have many employees.
Usually a 1:1 relationships are only used when you want to extended a table that you have no access or cannot modify. Otherwise, you would just add more columns to that original table. (or if you are working with a very old database system and you reach the max number of columns)
Table Department:
DeptId
Name
Table Team
TeamId
*DeptId (FK)
Name
Table Employee
EmpId
*DeptId
*TeamId
I am making some updates on an old project, but I don't know why the old programmer designed those tables like this (like putting both DeptId and TeamId in the Employee table).
I find this useless because I can get the department from the Team table, and there's no need to put both FK IDs into the Employee table, TeamId is enough.
Is there any other reason that could force me to put both FKs in that table?
Thank you.
As the data model is written, an employee could be a member of a team that is not in his or her department.
That is probably possible, for instance, if the employee is temporarily on loan.
My bigger problem with the data model is that the relationships between employee and team and employee and department vary over time. So, I would have three tables for each entity. The only relationship in the tables would be between team and department (because that presumably does not change over time).
Then I would have two junction tables, one employeeDepartments and one employeeTeams that capture the changing relationships over time.
I have the following 3 tables:
employees
departments
employees_departments (join table between employees and departments with additional info)
The department also has a column manager_id which is a foreign key to the employees table (a department has a manager from the employees table).
I have a requirement in which I must place a constraint in which no employee under a manager can have a higher salary than the manager.
My attempt at solving this:
ALTER TABLE employees
ADD CONSTRAINT check_salary
CHECK (salary > (SELECT salary
FROM employees e2
INNER JOIN employees_departments ed2 ON e2.id_employee = ed2.id_employee
INNER JOIN departments d2 ON d2.id_department = ed2.id_department
WHERE e2.id_employee != manager_id (but how do I get the manager id)
AND d2.id_departament = manager_department_id (again don't know how to do get it)
)
I get an error that subqueries are not allowed. Is this even possible to do in a constraint? How can it be modeled in a normal query?
I must also add that I have close to none experience with SQL Server and very little with SQL in general.
Any help greatly appreciated!
Even if you could do this, what would you expect to happen when the data changes such that for some rows the constraint fails (like a manager gets a salary reduction)? Sounds like this might be a bad problem/business rule description.
If it's purely an insert/update time check then use code or (yuk) a trigger.
Another alternative might be to use an updatable view which only selects employees that earn below their manager (i.e. everyone). By updating and inserting there you might be able to make it work in every case because if the insert/update into the view would not satisfy the view's criteria it will reject it.
Read up on the view and specifically the WITH CHECK OPTION.
https://learn.microsoft.com/en-us/sql/t-sql/statements/create-view-transact-sql
I looked for this and did not find a solution that would apply to my scenario.
I'm building a database of game devs and I wish to generate a connections table:
I have the following:
Employee
(
name, date of birth, department they work at, task they do
)
Department
(
department name
)
Task
(
task name
)
and I need to generate a connections table that shows which department contributes to which task. I would do that by checking for each employee their department (only one) and task (also only one) and upon a match, the department contributes to that task.
That is the idea but I have to clue how to code it using Oracle
SELECT DISTINCT "department they work at", "task they do"
FROM Employee;
You should first work out an entity-relationship diagram, that lists the entities you use and with what attributes (and which primary keys), and the relations between those entities. Relationships can be: 1-to-1, 1-to-many and many-to-1, and many-to-many.
In the last case (M:N relation), the implementation in database tables requires an extra table to record such a M:N relationship.
The way to implement a 1:N relationship in a table is adding a foreign key in the child table to the primary key of the parent table.
EDIT: I see that you now supplied some details, and it is clear now that EMPLOYEE table is in fact the connection table, so you could simply query that table and show the DEPTID and TASKID (both the primary keys of their respective tables) to have a connection between departments and tasks. See the query in the other answer, and just add an ORDERBY on DEPTID, to show results in the order of DEPTID.
I have a table students with the following fields.
Id,FirstName,SecondName,Photo,Student_ID
I also have a table called class_of_2011 with the fields
Id,FirstName,SecondName,Photo,Student_ID,Subjects
I want to select some specific students from table students and have them in table class_of_2011,but I already have the names in table students.I am thinking the only way to do this is to copy the names i want to the table class_of_2011,but since there will be a class of 2012 and beyond,I feel like I will be simply copying data from one table to the other.
Is repeating myself inevitable in my case?
It looks like this could be normalized easily. Why not have your class_of_ tables simply have a foreign key to the student table's id column?
StudentId,Subjects
In this way, one student record could be associated with several classes, in case someone is on the 5-year plan.
I'm assuming that the Student_ID field in the Students table is their id number or something, and not the primary key of that table.
Students Table
Id,FirstName,SecondName,Photo,Student_ID
Subjects Table
Id,Subject
Student_Subjects Table
Id,Student_Id,Subject_Id,Year
You may then assign a student multiple subjects, for multiple years.
The class_of_2011 table should contain the primary key of the students table and none of the other "repeated" data. All of the other columns you're interested in can then be obtained by joining the two columns together in a query.
I would restructure the data if possible... Something like....
Student Table
ID, Name, Address, other common specific to student
GraduatingClass Table
YearGraduate, StudentID
Enrollment Table
StudentID, ClassID, SemesterID