Избежание дубликатов при разработке отношений Один-ко-многим - PullRequest
0 голосов
/ 05 мая 2011

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

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

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

В отделе может быть много клерков, бухгалтеров, менеджеров среднего звена и так далее.Они просто сотрудники из таблицы Employee.Нужна более совершенная схема базы данных (например, гибкая, добавление нового столбца в виде Divisional-Manager должно быть легко) для подразделения Department без дублирования данных, NO аномалий обновления и таблиц соединений NO / less.

Заранее спасибо!:)

Ответы [ 6 ]

1 голос
/ 05 мая 2011

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

department employee ERD

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
1 голос
/ 05 мая 2011

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

DepartmentMember => (DepartmentId, EmployeeId, MembershipRole)

Почему ты не хочешь этого?

0 голосов
/ 05 мая 2011

Позиция / Название очень контекстно в отдел. Можно быть Региональный менеджер в одном отделе и может дополнительно принять консультанта должность в другом отделе.

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

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

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 имеет специальное название «Особый» и принадлежит отделу информационных технологий, учета и продаж. Сначала вы создаете этот заголовок (то есть «Особый») в таблице Position и получаете Position.PositionID.

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

0 голосов
/ 05 мая 2011

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

Сотрудник

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

Отдел

ID, Name, Active
0 голосов
/ 05 мая 2011
Employee =>(ID,name, department_ID, position_ID, Active)
Position =>(ID, name, Active)
Department => (ID,Name,location,Active)
0 голосов
/ 05 мая 2011

Department => (ID, employeeID, location, active) Employee => (EmployeeID, name, position)

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

...