Блог

Я просмотрел множество потоков и не смог разобраться. Извините, если это дублирующий вопрос. Рассмотрим следующую настройку.

1) Сотрудник => (идентификатор, имя)

2) Отдел => (идентификатор, имя, местоположение, клерк, бухгалтер,менеджерсреднего звена,менеджер группы,региональныйменеджер,Активный)

В отделе может быть много клерков, бухгалтеров, менеджеров среднего звена и так далее. Это просто сотрудники из таблицы Employee. Нужна лучшая схема базы данных (гибкая, например, добавление нового столбца в качестве Divisional-Manager должно быть простым) для объекта Department без дублирования данных, БЕЗ аномалий обновления и без таблиц соединений.

Заранее спасибо! 🙂

Вам нужно что-то вроде этого;

 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
  

У вас есть отношения «многие ко многим», поэтому вам нужна третья таблица ассоциаций (junction) — вы не можете этого избежать.

DepartmentMember => (DepartmentID, EmployeeID, MembershipRole)

Почему вы этого не хотите?

 Employee =>(ID,name, department_ID, position_ID, Active)
Position =>(ID, name, Active)
Department => (ID,Name,location,Active)
  

Отдел => (идентификатор, идентификатор сотрудника, местоположение, активный) Сотрудник => (идентификатор сотрудника, имя, должность)

Я думаю, что это был бы гораздо лучший способ организации ваших таблиц. Предполагается, что active является свойством отдела, в противном случае переместите его в таблицу employee.

Предполагается, что сотрудник может работать только в 1 отделе. ЕСЛИ нет, то да, вам нужна третья таблица, чтобы избежать дублирования

Сотрудник

 ID, Name, EmployeeType, DepartmentID
(pk on ID, EmployeeType)
  

Отдел

 ID, Name, Active
  

Должность / Title очень сильно зависит от контекста отдела. Можно быть региональным менеджером в одном отделе и дополнительно занимать должность консультанта в другом отделе.

Тогда отдел и сотрудник — это «многие ко многим». Сотрудник на должность также относится ко многим. Если вам нужна гибкость, например, добавление нового названия для отдела, таблицы соединений необходимы. Вы не можете избежать этого.

Вы можете обратиться к следующей структуре таблицы для справки:

 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 )
  

Если позиция / заголовок исправлены на
Сотрудник вместо отдела.т.е.
сотрудник, который является клерком и может находиться в
эта позиция относится к одному или многим подразделениям.,
как мы можем это сделать?

Вы имеете в виду, что в крайнем случае многие сотрудники могут иметь свои собственные специальные должности? и они принадлежат многим отделам? Если да, предположим, что идентификатор сотрудника 123 имеет специальное название «The Special One» и принадлежит ИТ-отделу, отделу учета и отделу продаж . Сначала вы создаете этот заголовок (т. е. «Специальный») в Position таблице и получаете Position.PositionID .

Затем вы вставляете 3 записи для Employee.EmployeeID 123 в EmployeePosition таблицу, используя this Position.PositionID и идентификатор отдела ИТ, учетной записи, отделов продаж.