클래스 모델링/디자인 쿼리

Question

어떻게 그러한 상황을 모델링합니까? 데이터베이스는 어떻게 설계되어야합니까? 어떤 수업을해야합니까?

문제 선언문 : 각 직원은 최소한 하나의 프로젝트에 속하고 각 프로젝트에는 많은 작업이 있으며 각 작업에는 적어도 한 명의 직원이 할당됩니다.

나는 프로젝트를 진행

• 직원을 휘젓다 할 수 있어야한다.
• 프로젝트에 속한 작업
• 주어진 직원이 작업하고있는 작업. 등

...

순환/순환 관계에 나쁜 디자인인가는 그것을 제거 할 수 있습니까?

데이터베이스에서 엔터티는 어떻게 표현되어야합니까? 엔티티는 클래스를 사용하여 어떻게 표현되어야합니까?

미리 감사드립니다.

Answer 1

으로 시작하여 데이터베이스에서 작업하십시오. 클래스 구조를 추천하기 위해서는 더 많은 정보가 필요합니다. 당신은 직원을위한 객체가 필요합니까/필요합니까? 또는 그들이 프로젝트의 자산이 될 것인가? 등

DB 설계 :

Projects 
    ProjectID 
    ProjectName... 
    EmployeeID 

Tasks 
    TaskID 
    ProjectID 
    TaskName... 
    EmployeeID 

Employees 
    EmployeeID 
    EmployeeName... 

Answer 2

당신은 성능이나 사용 요구 사항에 대해 아무것도 언급하지 않았다, 그래서 일반적인 방법으로 대답 할거야 당신이 더 필요하면 내 대답을 업데이 트됩니다 특정 정보. DB 테이블의 경우 이러한 라인을 따라 일반적인 정규화 된 접근 방식을 제안합니다.

tblProject 
    ProjectID 
    ProjectDescription etc. 

tblTask 
    TaskID 
    TaskDescription etc. 

tblEmployee 
    EmployeeID 
    Name etc. 

tblProjectTasks 
    ProjectTasksID 
    ProjectID 
    TaskID 

tblTaskAssignments 
    TaskAssignmentsID 
    TaskID 
    EmployeeID 

또 다른 유효한 접근법은 프로젝트 목록을 정의하는 테이블과 다른 테이블을 정의하는 것입니다. 작업과 직원들도 마찬가지입니다. 실제 응용 프로그램에서는 다른 잘 정의 된 객체를 포함하는 클래스를 설계하는 것처럼 이러한 엔티티가보다 일반적인 테이블에서 잘 정의되는 것이 일반적입니다. 예를 들어, 직원 이외의 프로젝트 리소스는 언급하지 않았습니다. 이러한 리소스는 리소스 유형, 리소스 속성 등을 정의하는 스키마에 표시 될 수 있으며 리소스를 프로젝트 및/또는 작업에 조인합니다.

Project Employees를 나타내는 테이블을 만들 수도 있지만 다른 테이블을 조인하여 프로젝트에 할당 된 직원을 찾을 수 있으므로이 테이블의 데이터는 중복됩니다. IMHO, 이러한 종류의 중복은 테이블이 거대하고이 특정 유형의 쿼리가 자주 사용되는 경우에만 보증됩니다. 그러나 나는 다른 접근법을 먼저 고려할 것입니다.

당신은 또한 수업에 대해 질문했습니다. 목표를 더 잘 이해하지 않으면 너무 구체적이지 않습니다. 일반적인 OO 디자인에서 클래스는 Project, Task 및 Employee를 분명하게 표현해야합니다. 그러나 당신은 당신의 특정한 요구에 맞게 맞추어야합니다.

Answer 3

나는 데이터베이스 설계를 위해 이런 짓을 할 것이다 :

Create Table Projects 
(
    ProjectID int Identity(1,1), 
    ProjectName varchar(50) Primary Key NonClustered, 
    OtherStuff varchar(255) 
) 
CREATE CLUSTERED INDEX IX_PROJECTS_ID ON dbo.Projects(ProjectID) 

Create Table Employees 
(
    EmployeeID int Identity(1,1), 
    EmployeeName varchar(50) Primary Key NonClustered, 
) 
CREATE CLUSTERED INDEX IX_EMPLOYEES_ID ON dbo.Employees(EmployeeID) 

Create Table ProjectEmployees 
(
    ProjectID int, 
    EmployeeID int, 
    Constraint pk_ProjectEmpoyees Primary Key (ProjectID, EmployeeID) 
) 

Create Table Tasks 
(
    TaskID int Identity(1,1), 
    TaskName varchar(50) Primary Key NonClustered, 
    AssignedEmployeeID int, --NOTE: assumes only 1 employee per task 
    OtherStuff varchar(255) 
) 
CREATE CLUSTERED INDEX IX_TASKS_ID ON dbo.Tasks(TaskID) 

Create Table TaskPrecedents 
(
    TaskID int, 
    PrecedentTaskID int, 
    PrecedentType Char(2) --Codes, you'll have to work these out 
    Constraint pk_TaskPrecedents Primary Key (TaskID, PrecedentTaskID) 
) 

Answer 4

내가 할 수있는만큼 일반적인 방식으로 귀하의 질문에 답하고 이전과 같이 특정 테이블 구조를 반복하지 않도록하려고합니다 응답. 프로젝트는 직원이

There are many Projects 
Projects have Employees 
Projects have Tasks 
Employees are assigned some Tasks 

동안 ... 그리고 직원은 아마도 프로젝트를 가지고 (또는 : 일반적으로, 당신의 개체 간의 순환 관계가 반대로 ... 나쁜 일이 아니다 말해서, 그들은 매우 일반적이다 직원이 한 번에 둘 이상의 프로젝트에서 작업 할 수있는 경우 많은 프로젝트). 데이터베이스 관점에서, 외래 키를 생성 할 때 원할 것인지의 여부에 관계없이 "순환"관계가 존재합니다.

더 중요한 질문은 개념적 관점에서 볼 때 종업원이 어떤 프로젝트 (들)의 일부인지 아는 것이 중요합니까? 프로젝트가 직원들이 무엇을하고 있는지를 아는 것이 매우 중요합니다 ... 직원이 프로젝트를 잘 알고있는 것은 중요하지 않을 수 있습니다. 이것은 "탐색 가능성"이라고하며 데이터베이스 구조와 달리 CAN 클래스에서이를 제어 할 수 있습니다. Project 객체에는 Employee 객체의 컬렉션이 있지만 Employee 객체에는 Project 속성 (또는 Project 컬렉션)이 반드시있을 필요는 없습니다.

탐색 가능성과 관련하여 제공 할 수있는 답변이 없습니다. 그게 보통 주관적이고, 귀하의 비즈니스 요구에 달려 있습니다. 비즈니스 모델링에 직원이 어떤 프로젝트를 수행하고 있는지 파악하고 비즈니스 논리가 수행 할 프로세스를 완료하는 데 지식이 중요한 경우 ... 원형 순환 관계가 필요합니다.