Класс моделирования / дизайн запроса

Question

Как бы я смоделировал такую ​​ситуацию? Как должна быть разработана база данных? Какие у меня должны быть занятия?

Постановка задачи: Каждый сотрудник принадлежит как минимум к одному проекту, каждый проект имеет много задач, каждая задача назначается как минимум одному сотруднику.

Я должен быть в состоянии произвести

• сотрудников, работающих над проектом.
• задачи, которые принадлежат проекту
• задачи, над которыми работает данный сотрудник.

и т. Д. *

Являются ли циклические / циклические отношения плохим замыслом, можно ли его устранить?

Как должны объекты, представленные в базе данных? Как должны быть представлены объекты с использованием классов?

Заранее спасибо,

Answer 1

Я постараюсь ответить на ваши вопросы настолько обобщенно, насколько это возможно, и избегать повторения конкретных структур таблиц, как в предыдущих ответах. Вообще говоря, циклические отношения между вашими сущностями не так уж плохи ... наоборот, они довольно распространены:

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

Хотя в проекте есть сотрудники ... и у сотрудника также есть проект (или, возможно, множество проектов, если сотрудник может работать над несколькими проектами одновременно). С точки зрения базы данных, когда вы создаете внешний ключ, эта «круговая» связь существует независимо от того, хотите вы этого или нет.

Более важный вопрос, с концептуальной точки зрения, имеет ли значение, знает ли Сотрудник, в какой проект (ы) он входит? Хотя, вероятно, очень важно, чтобы Проект знал, над чем работают сотрудники ... может быть не важно, чтобы Сотрудник знал, над каким проектом он работает. Это то, что называется «Навигация», и в отличие от нашей структуры базы данных, мы МОЖЕТ контролировать это с нашими классами. Объект Project будет иметь коллекцию объектов Employee, но объект Employee не обязательно должен иметь свойство Project (или коллекцию Projects).

Я не могу дать вам никакого стандартного ответа относительно судоходства. Это обычно субъективно, и зависит от потребностей вашего бизнеса. Если бизнес, в котором вы моделируете, имеет понятие, что сотрудник знает, над какими проектами он работает, и эти знания важны для завершения процессов, которые будет выполнять ваша бизнес-логика ... тогда вам нужны эти циклические отношения. То же самое касается навигации между сотрудниками и задачами, проектами и задачами и т. Д.

Answer 2

Вы ничего не упомянули о требованиях к производительности или использованию, поэтому я собираюсь дать общий ответ и обновлю свой ответ, если вам потребуется более конкретная информация. Для таблиц БД я предлагаю общий нормализованный подход по этим направлениям.

tblProject
    ProjectID
    ProjectDescription etc.

tblTask
    TaskID
    TaskDescription etc.

tblEmployee
    EmployeeID
    Name etc.

tblProjectTasks
    ProjectTasksID
    ProjectID
    TaskID

tblTaskAssignments
    TaskAssignmentsID
    TaskID
    EmployeeID

Другим правильным подходом было бы создание таблицы, определяющей проект, и другой таблицы для определения списка проектов. То же самое будет верно для задач и сотрудников. В реальных приложениях эти сущности часто бывают хорошо определены в более общих таблицах, так же как вы можете создать класс, содержащий другие четко определенные объекты. Например, вы не упомянули ресурсы проекта, кроме сотрудника. Эти ресурсы могут быть представлены в схеме, которая определяет тип ресурса, свойства ресурса и т. Д., А затем присоединяет ресурс к проекту и / или задаче.

Вы также можете создать таблицу, представляющую сотрудников проекта, но данные в ней будут избыточными, поскольку вы можете найти сотрудников, назначенных для проекта, путем объединения других таблиц. ИМХО, такого рода дублирование будет оправданным только в том случае, если таблицы огромны, и этот конкретный тип запросов используется очень часто. Но я все равно сначала рассмотрю другие подходы.

Вы также спрашивали о занятиях. Трудно быть слишком конкретным без лучшего понимания ваших целей. В типичном дизайне ОО классы должны четко представлять проект, задачу и сотрудника. Но вам нужно будет адаптировать его под свои конкретные потребности.

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

начать с базы данных и работать оттуда. Мне нужно больше информации, чтобы рекомендовать структуру класса. Вы хотите / нуждаетесь в объектах для сотрудников? или они будут собственностью проекта? и т.д ..

Дизайн БД:

Projects
    ProjectID
    ProjectName...
    EmployeeID

Tasks
    TaskID
    ProjectID
    TaskName...
    EmployeeID

Employees
    EmployeeID
    EmployeeName...