Unha relación de un a moitos nunha base de datos ocorre cando cada rexistro da Táboa A pode ter moitos rexistros vinculados na Táboa B, pero cada rexistro da Táboa B pode ter só un rexistro correspondente na Táboa A. Unha relación de un a moitos. unha base de datos é o deseño de base de datos relacional máis común e está no corazón dun bo deseño.
Considere a relación entre un profesor e os cursos que imparten. Un profesor pode ensinar varios cursos, pero o curso non tería a mesma relación co profesor.
Polo tanto, para cada rexistro dunha táboa de profesores, pode haber moitos rexistros na táboa de cursos. Esta é unha relación de one-to-many: un profesor de varios cursos.
Por que establecer unha relación de un a moitos é importante
Para representar unha relación de un a moitos, necesitas polo menos dúas táboas. Vexamos por que.
Quizais creamos unha mesa de profesores na que queremos rexistrar o nome e os cursos impartidos. Poderiamos deseñalo así:
Teacher_ID | Teacher_Name | Curso |
---|---|---|
Profesor_001 | Carmen | Bioloxía |
Profesor_002 | Veronica | Matemáticas |
Profesor_003 | Jorge | Inglés |
E se Carmen ensina dous ou máis cursos? Temos dúas opcións con este deseño. Poderiamos agregar-lo ao rexistro existente de Carmen, así:
Teacher_ID | Profesor _Name | Curso |
---|---|---|
Profesor_001 | Carmen | Bioloxía, matemática |
Profesor_002 | Veronica | Matemáticas |
Profesor_003 | Jorge | Inglés |
O deseño anterior, con todo, é inflexible e pode causar problemas máis tarde ao tentar inserir, editar ou borrar datos.
Fai que sexa difícil buscar datos. Este deseño viola o primeiro principio de normalización da base de datos, Primeiro Formulario Normal (1NF) , que indica que cada célula da táboa debería conter unha única e discreta información.
Outra alternativa de deseño podería ser simplemente engadir un segundo disco para Carmen:
Profesor _ID | Profesor _Name | Curso |
---|---|---|
Profesor_001 | Carmen | Bioloxía |
Profesor_001 | Carmen | Matemáticas |
Profesor_002 | Veronica | Matemáticas |
Profesor_003 | Jorge | Inglés |
Este adhírese a 1NF pero aínda é un deseño de base de datos pobre porque introduce unha redundancia e pode innecesariar unha base de datos moi grande. Máis importante aínda, os datos poderían volverse inconsistentes. Por exemplo, ¿e se o nome de Carmen cambiou? Alguén que traballa cos datos podería actualizar o seu nome nun rexistro e non actualizar no segundo rexistro. Este deseño viola Second Normal Form (2NF), que se adhire a 1NF e tamén debe evitar o despedimento de varios rexistros separando subconxuntos de datos en varias táboas e creando unha relación entre eles.
Como deseñar unha base de datos con moitas relacións
Para implementar unha relación de un a moitos na táboa de Profesores e Cursos, dividimos as táboas en dúas e enlácelos usando unha chave estranxeira .
Aquí eliminamos a columna do curso na táboa de Profesores:
Profesor _ID | Profesor _Name |
---|---|
Profesor_001 | Carmen |
Profesor_002 | Veronica |
Profesor_003 | Jorge |
E aquí está a táboa de cursos. Teña en conta que a súa clave externa, Teacher_ID, vincula un curso a un profesor na táboa Teachers:
Course_ID | Nome do curso | Teacher_ID |
---|---|---|
Curso_001 | Bioloxía | Profesor_001 |
Curso_002 | Matemáticas | Profesor_001 |
Curso_003 | Inglés | Profesor_003 |
Desenvolvemos unha relación entre a Mesa dos Profesores e os Cursos usando unha clave externa.
Isto nos di que tanto a Bioloxía como a Matemática son ensinar por Carmen e que Jorge ensina inglés.
Podemos ver como este deseño evita os posibles despedimentos, permite aos profesores individuais ensinar varios cursos e implementa unha relación de un a moitos.
As bases de datos tamén poden implementar unha relación de un a un e unha relación de moitos a moitos.