Suppose I have employees and departments and employee role where one employee can belong to a different department with a different role.
For example, Emp 1 belongs to Dept 1 with a role manager. where the same employee can belong to Dept 2 with a role service-man.
Each employee also has a child hierarchy like Emp 2, Emp 3 belongs to Dept 1 with role assistant and their parent is Emp 1.
In this case what will be the best solution for designing this concept. Please share your opinion.
Consider the entities and attributes:
Employees:
id,
name
Departments:
deptID,
dept_name
Roles:
role_id,
role_name
I'll try to state the business domain as you've outlined it, and then turn that into a schema suggestion.
The system has 0 or more employees
The system has 0 or more departments
The system has 0 or more roles
<<EDIT: your comment says that the "parent" role is department-specific>>
An employee belongs to 1 or more departments, and within that department has exactly one role and one parent (a parent is another employee)
Employee
------------
Employee_id (pk)
Name
Roles
------
Role_id (pk)
Name
Departments
-----------
Department_id (pk)
Name
Employee_deparment_role
-------------------------
employee_id (pk, fk)
department_id (pk, fk)
role_id (pk, fk)
Parent_id (pk, fk to employees)
This model only captures one state - it doesn't allow people to change departments or roles, or "parent", but you didn't mention that as a requirement.
Related
I am developing a online job portal website. In class diagram I generalized Employer & Employee as Members class & I put 'MID' as primary key. Now I am confused how to create tables for Employer & Employee?
Here is tables you required:
Member
========
Id (or MId) (PK)
... (Specifications you need)
Employer
========
Id (PK)
MId (FK to Member table)
... (Specifications you need)
Employee
========
Id (PK)
MId (FK to Member table)
EId (FK to Employer table)
... (Specifications you need)
I have 2 tables I plan on creating, Employee and Student. Employee and Student tables have some common fields and also some different ones. Is it a good idea to put those same fields in a common table like Person and then relate them?
For example, both Employee and Student have FirstName and LastName fields.
PersonType
personTypeID (1 ,2 )
personTypeName (student,employee )
Person
PersonID
PersonType (foreignKey From PersonType)
PersonName
PersonSurname
Employee
EmployeeID (ForeignKey from Person table and also primaryKey of this table, since all employees are person or you can make a unqiue empID for this table and make a column like fkPersonID which must be unique fot this table as well)
EmployeeDepID (fk from departmens)
Budget
and so on
Students
Exactly same approach as Employee table.
Since you didn't mentioan about for a student which might be an employee or vice versa i didn't consider this situation. Assuming that a student might be an employee as well just create a column in students table which is fkEmpID from employee table. But in this situation if you create fkPersonID in both employee and student table you have to guarantee these two columns matches. To provide in your student table get both (fkPersonID, fkEmpID) and match them (fkPersonID,fkEmpID) this is called multi-column foreign keys.
I need to create an ER where users can add and delete their personal contacts.
Contacts can be any person including other users.
Users can also check who of the other users have added them to their contact list.
I don't know how to start. Can someone please help me draw this ER?
Person
PersonID (PK)
OtherUserInfo...
Contact
PersonId (FK to UserID)
contactId (FK to ContactID) Composite PK these 2 together.
PersonProfile
PersonID (FK to userID)
PersonCategoryID (FK to UserCategoryID) Composite PK these 2 together.
PersonCategory
personCategoryID (PK)
PersonCategory (User, Contact etc) depending on if a user can be a contact or just a contact or just a user.
when a user adds a contact the entry is put in Person table and an associated record is in personProfile with a personcategoryID for contact and the contact is linked to the person putting in the etnry via contact table
If a person is added as a contact from the other users, (found by joining person to personprofile where personcategory links to "user" entry, then an entry is saved in contact with the personId doing the seach and the personid of the contact they just added.
if a person is removed from personporfile as a contact, all entries in contact table for that contactId are removed as that person is no longer a valid contact. (assuming history isn't needed)
Just my thoughts... there's lots of ways to skin this cat based on additional requirements, desired growth etc.
I'm not a DBA and I don't know what is the best solution. I have two tables,
Custumers Table
CustomerId (primary key, identity)
...
and
Suppliers Table
SupplierId (primary key, identity)
...
and I want to store multiple telephone number and multiple emails. I thought to create two other tables, Emails and Telephones and use those in join with my Custumers and Suppliers, something like
Telephones Table
Id
UserId (reference to SuppliersId or CustomerId)
Value
...
But if I use as key for custumers and suppliers an Identity I'll have for sure problems. I'm thinking to do something like
Telephones Table
Id
SuppliersId
CustumersId
Value
...
But I don't know if is a good design. Any advice?
Thank you
One idea:
Entity (ID (PK), {common fields})
Customer (ID (PK), EntityID (FK), {other fields})
Supplier (ID (PK), EntityID (FK), {other fields})
Telephone (ID (PK), EntityID (FK), Value)
This also has the added advantage of reducing duplication between Customer and Supplier.
A good design would be
Customers: Table of customers - CustomerId, Other columns
Suppliers: Table of suppliers - SupplierId, Other columns
Telephones: Table of telephones - TelephoneId, other columns
CustomerTelephones: CustomerId, TelephoneId
SupplierTelephones: SupplierId, TelephoneId
my advise is that you assign an ID for the table then add a reference field with the same datatype with the SupplierID and CustomerID
The other answers are decent beginner solutions, but they all have the same fundamental flaw in that Customer or Supplier are Relationships and not their own unique entities. A Customer is not a person, it's a relationship between you and a person.
In fact a person could be an Employee, Customer, Supplier all at the same time, or over time.
A Customer or Supplier could also be a Business, with many involved people.
Here is the correct answer:
PARTY
id
type {individual, organization, automated_agent}
org_name null
first_name null
last_name null
PARTY_RELATIONSHIP
from_party_id FK PARTY
type {supplier_of, customer_of, ...}
to_party_id FK PARTY
from_date
to_date null
Usage:
Insert into party (id, type, org_name) values (1, 'organization', 'Raw Steel Co');
Insert into party (id, type, f_name, last_name) values (2, 'individual', 'Davide', 'X');
-- Raw Steel Co is both a customer of and supplier to you:
Insert into party_relationship values (1, 'supplier_of', 2, getdate(), null);
Insert into party_relationship values (1, 'customer_of', 2, getdate(), null);
Now, some people don't like Single Table Inheritance because of the nulls, but goddam it is easier to work with. Use Class Table Inheritance if you're finicky.
The 'type' columns should be foreign keys to type tables.
you can do like
Customers: Table of customers - CustomerId, Other columns
Suppliers: Table of suppliers - SupplierId, Other columns
Telephones: Table of telephones - TelephoneId,TypeId,TypeName, other columns
where TypeName will be Customers or Suppliers, ant TypeId will be id of the resp.
I went through many threads and couldn't figure it out. Sorry if this is a duplicate question. Consider the following setup.
1) Employee => (ID,Name)
2) Department => (ID,Name,location,Clerk,Accountant,Middle-manager,Group-manager,Regional-manager,Active)
Department can have many Clerks, Accountants, Middle-managers and so on. They are just employees from the Employee table. Need a better database schema (flexible like, adding up a new column as Divisional-Manager must be easy) for Department entity with NO data duplication, NO update anomalies and NO / less junction tables.
Thanks in advance! :)
You need something like this;
CREATE TABLE department(
dept_id int NOT NULL,
dept_name char(10) NULL,
CONSTRAINT PK1 PRIMARY KEY NONCLUSTERED (dept_id)
)
go
CREATE TABLE department_employee(
id int NOT NULL,
dept_id int NOT NULL,
emp_id int NOT NULL,
CONSTRAINT PK3 PRIMARY KEY NONCLUSTERED (id)
)
go
CREATE TABLE employee(
emp_id int NOT NULL,
emp_name char(10) NULL,
CONSTRAINT PK2 PRIMARY KEY NONCLUSTERED (emp_id)
)
go
ALTER TABLE department_employee ADD CONSTRAINT Refdepartment1
FOREIGN KEY (dept_id)
REFERENCES department(dept_id)
go
ALTER TABLE department_employee ADD CONSTRAINT Refemployee2
FOREIGN KEY (emp_id)
REFERENCES employee(emp_id)
go
You have a many-to-many relationship so you need a third association (junction) table - you can't avoid it.
DepartmentMember => (DepartmentId, EmployeeId, MembershipRole)
Why don't you want this?
Employee =>(ID,name, department_ID, position_ID, Active)
Position =>(ID, name, Active)
Department => (ID,Name,location,Active)
Department =>(ID,employeeID,location,active)
Employee =>(EmployeeID,name, position)
I think that would be a much better way of organizing your tables. This assumes that active is a property of the department, else move it to the employee table.
Assuming an employee can only work in 1 department. IF not, then yes, you need a third table to avoid duplication
Employee
ID, Name, EmployeeType, DepartmentID
(pk on ID, EmployeeType)
Department
ID, Name, Active
Position/Title is very much contextual
to Department. One can be a
Regional-Manager in one department and
can additionally takes Consultant
position in another department.
Then , the department and the Employee is many-to-many. The Employee to the position is also many-to-many. If you need flexibility ,like adding a new title for a department , the junction tables are necessary. You cannot avoid it.
You can refer to the following Table structure for reference:
Employee
-----------------------
EmployeeID (PK)
EmployeeName
Active
Department
-------------------------
DepartmentID (PK)
DepartmenName
Location
Position
----------------------------
PositionID (PK)
PositionDescription (eg.Clerk, Accountant etc)
EmployeePosition
----------------------------
EmployeeID (FK to Employee.EmployeeID )
DepartmentID (FK to Department.DepartmentID)
PositionID (FK to Position.PositionID )
If the Position/Title is fixed to
Employee instead of Department.i.e. An
employee who is clerk and can be in
that position to one or many dept.,
how can we go about it?
Do you mean that in an extreme case , many employees can have their own special titles ? and they belong to many departments? If yes ,suppose a employee ID 123 has a special title called "The Special One" , and it belongs to the IT , Account and Sales department . You first create this title (i.e "The Special One" ) in the Position table and get the Position.PositionID.
Then you insert 3 records for Employee.EmployeeID 123 into EmployeePosition table using this Position.PositionID and the Department ID of IT , Account , Sales departments.