Início / dba / Perguntas / 77550
Accepted
Lambo Jayapalan
Asked: 2014-09-25 11:33:36 +0800 CST

Tabela de arquitetura com vários caminhos para tabelas pai comuns

  • 772

Estou querendo saber como arquitetar um banco de dados quando há vários caminhos (por meio de chaves estrangeiras) para uma tabela pai comum.

Por exemplo, tenho as seguintes tabelas:

Table: Students
PK StudentId

Table: Classes
PK: ClassId

Table: ClassStudents
PK: ClassStudentId:
FK: StudentId
FK: ClassId

Table: ClassAssignments
PK: ClassAssignmentId
FK: ClassId
FK: Assignment

Agora vou criar uma nova tabela que armazena os envios de Tarefas de cada aluno. Qual é a melhor maneira de estruturá-lo de forma que um aluno de outra turma não possa ser adicionado a uma tarefa desta turma?

TABLE: ClassStudentAssignments
FK: ClassAssignmentId
FK: ClassStudentId

Existe uma maneira de lidar com isso no design do banco de dados ou teria que ser feito apenas por meio da lógica de negócios?

Agradecemos antecipadamente por qualquer ajuda.

database-design

2 respostas

  1. Você está pensando sobre isso incorretamente. O envio de um trabalho de um aluno não matriculado no curso correspondente, se for corrigido, não é fundamentalmente diferente de um envio devidamente enviado e corrigido de um aluno que posteriormente abandona o curso. Permitir que a entrada da nota exista no banco de dados, observando que quando o relatório final das notas dos trabalhos para cada curso for gerado, a junção (interna) falhará para todos os envios de alunos não matriculados no curso no momento do exame . Isso é suficiente para implementar adequadamente a lógica de negócios.

    • 1
  2. Best Answer

    Aluno ( student_id) existe.

    student {student_id}
     PK {student_id}

    A classe ( class_id) existe.

    class {class_id}
   PK {class_id}

    Aluno ( student_id) assiste à aula ( class_id).

    student_class {student_id, class_id}
           PK {student_id, class_id}
          FK1 {student_id} REFERENCES student {student_id}
          FK2 {class_id}   REFERENCES class {class_id}

    Tarefa ( task_id) existe.

    task {task_id}  
  PK {task_id}

    A classe ( class_id) recebe uma tarefa ( task_id).

    assignment {class_id, task_id}
        PK {class_id, task_id}      
       FK1 {class_id} REFERENCES class {class_id}
       FK2 {task_id}  REFERENCES task {task_id}

    Aluno ( student_id) presente na aula ( class_id) apresentou solução para a tarefa ( task_id), atribuída à turma.

    solution {student_id, class_id, task_id}
      PK {student_id, class_id, task_id}
     FK1 {student_id, class_id} REFERENCES student_class {student_id, class_id}
     FK2 {class_id, task_id}    REFERENCES assignment {class_id, task_id}

    Observação:

    ... quando há vários caminhos (através de chaves estrangeiras) para uma tabela pai comum ...

    Esta é a causa raiz do problema. Não existe tal coisa no modelo relacional; chaves estrangeiras são restrições , não caminhos de navegação. Você está arrastando a terminologia OO para um banco de dados relacional e esses dois não correspondem - os paradigmas são diferentes.

    • 0

relate perguntas