Hi Im trying to get the following result below
We have three tables Employee, Permission, and Reporting(manager)
Supposed to be managers should only be assigned to employees in locations that they have permission too but this isn't what happening. The reporting table overides this and we must get the employees
Here's the result we need either of the two
Basically the result must show the employees that are assigned to managers even though the managers don't have permission to the employees locations. eg. (Employee 1 is assigned as manager of employee 21 even though employee 1 doesn't have manager permission for location 25)
I'm having a hard time with the conditions to join the three table the produce the results we need
I am learning to program with SQL and have just been introduced to self-joins. I understand how these work, but I don't understand what their purpose is besides a very specific usage, joining an employee table to itself to neatly display employees and their respective managers.
This usage can be demonstrated with the following table:
EmployeeID | Name | ManagerID
------ | ------------- | ------
1 | Sam | 10
2 | Harry | 4
4 | Manager | NULL
10 | AnotherManager| NULL
And the following query:
select worker.employeeID, worker.name, worker.managerID, manager.name
from employee worker join employee manager
on (worker.managerID = manager.employeeID);
Which would return:
Sam AnotherManager
Harry Manager
Besides this, are there any other circumstances where a self-join would be useful? I can't figure out a scenario where a self-join would need to be performed.
Your example is a good one. Self-joins are useful whenever a table contains a foreign key into itself. An employee has a manager, and the manager is... another employee. So a self-join makes sense there.
Many hierarchies and relationship trees are a good fit for this. For example, you might have a parent organization divided into regions, groups, teams, and offices. Each of those could be stored as an "organization", with a parent id as a column.
Or maybe your business has a referral program, and you want to record which customer referred someone. They are both 'customers', in the same table, but one has a FK link to another one.
Hierarchies that are not a good fit for this would be ones where an entity might have more than one "parent" link. For example, suppose you had facebook-style data recording every user and friendship links to other users. That could be made to fit in this model, but then you'd need a new "user" row for every friend that a user had, and every row would be a duplicate except for the "relationshipUserID" column or whatever you called it.
In many-to-many relationships, you would probably have a separate "relationship" table, with a "from" and "to" column, and perhaps a column indicating the relationship type.
I found self joins most useful in situations like this:
Get all employees that work for the same manager as Sam. (This does not have to be hierarchical, this can also be: Get all employees that work at the same location as Sam)
select e2.employeeID, e2.name
from employee e1 join employee e2
on (e1.managerID = e2.managerID)
where e1.name = 'Sam'
Also useful to find duplicates in a table, but this can be very inefficient.
There are several great examples of using self-joins here. The one I often use relates to "timetables". I work with timetables in education, but they are relevant in other cases too.
I use self-joins to work out whether two items clash with one another, e.g. a student is scheduled for two lessons which happen at the same time, or a room is double booked. For example:
CREATE TABLE StudentEvents(
StudentId int,
EventId int,
EventDate date,
StartTime time,
EndTime time
)
SELECT
se1.StudentId,
se1.EventDate,
se1.EventId Event1Id,
se1.StartTime as Event1Start,
se1.EndTime as Event1End,
se2.StartTime as Event2Start,
se2.EndTime as Event2End,
FROM
StudentEvents se1
JOIN StudentEvents se2 ON
se1.StudentId = se2.StudentId
AND se1.EventDate = se2.EventDate
AND se1.EventId > se2.EventId
--The above line prevents (a) an event being seen as clashing with itself
--and (b) the same pair of events being returned twice, once as (A,B) and once as (B,A)
WHERE
se1.StartTime < se2.EndTime AND
se1.EndTime > se2.StartTime
Similar logic can be used to find other things in "timetable data", such as a pair of trains it is possible to take from A via B to C.
Self joins are useful whenever you want to compare records of the same table against each other. Examples are: Find duplicate addresses, find customers where the delivery address is not the same as the invoice address, compare a total in a daily report (saved as record) with the total of the previous day etc.
I need to select all users from custom departments. Each department can have more important department above itself, but there is also possibility that department can be kind of main department.
Example with main department (main department column checked)
First department
Second department under first department < This one is main department
Third department under second department
Fourth department under second department
Fifth department under fourth department
Now we need to show users from second, third, fourth and fifth department.
Users table has: department_id, which means to which department user belongs.
Departments table has: department_id, department_id_above and is_main_department columns.
Thanks for your attention.
From what you've written so far the below could be of help. But this is just from guessing.
https://en.wikipedia.org/wiki/Hierarchical_and_recursive_queries_in_SQL
Have you tried it?
I have the following tables: Department, Section, Employee,Manager, and Position. The relations between the tables are as follows:
Each Department contains many sections
Each Department contains many positions and each position might be shared with different departments
Each department section has a manager
Each manager might has different positions, for instance, Urology Department Chairman is a position as manager, and as an employee he is a Urology Consultant. As an employee, he has two positions.
As you can see from the image above
DepartmentSections is a Join table between Departments and Sections
DepartmentPositions is a Join table between Departments and Positions
My problem now, How I should configure Managers? I am thinking of making two relations, first between the Manager and DepartmentSections and between the Manager and DepartmentPositions, the problem here is that I will get two DepartmentId fields in the table Manager.
Is there any mistake in my analysis? how to build this model in order to avoid 2 DepartmentId in the table Managers?
Some thoughts on your post. It is not an answer (too long to comment) but might help a bit.
Each Department contains many sections
From this I guess that you don't need the lookup table DepartmentSections since this sentence describes one-to-many and not many-to-many relationship. You could add the DepartmentId in the Sections table.
Each department section has a manager
So you could add the ManagerId to Sections table.
Now for positions and managers, If I understood correctly, I would add the ManagerId to DepartmentPositions.
I have a core data project which has a fairly simple data model but there is one feature that I am having trouble implementing. It is a really basic feature so I know it must be able to be implemented but I am, unfortunately, stumped.
Rather than burden you with the project details I will instead use an employee scenario to explain.
Here is the data model
Entity = Employee
Attributes:
firstName
lastName
Relationships:
grade
department
Entity = Grade
Attributes:
grade
Relationships:
employeeGrade
Entity = Department
Attributes:
department
Relationships:
employeeDepartment
employeeGrade is a many-to-one relationship with grade from the Employee Entity
employeeDepartment is a many-to-one relationship with department from the Employee Entity
All attributes are strings.
I have a table set to add grades to the grade entity.
I have another table beneath the grade table to display the list of employees who have the grade that is selected in the grade table.
I want to display the first name, last name and department for each employee in this table. By using array controllers and bindings in IB, displaying the first and last names is no problem but getting the department to display is what is proving problematic for me. It is as you can see a many to one relationship and I cannot figure out how to set this up with bindings so that the department for the employee is shown in the table.
I can easily populate a popupmenu cell with the all departments but I simply want to display only the appropriate department in a text cell
I know the answer must be simple but after days of searching the net and experimenting I am lost.