Modelo Entidad Relación

Modelo Entidad Relación

consulte ejemplos en: 

La plataforma Blackboard: Actividades- Nancy Jaimes Rojas - Administrar Tecnologías de la Información- Semana 07: 08 Noviembre a - Material de Apoyo- Modelo Entidad Relación Ejemplos.pdf

Es la representación (Abstracción) de la realidad para poder comprenderla y expresarla.

Este modelo permite plantear un diseño conceptual de la base de datos a crear.

El diseño de una base de datos son figuras llamadas diagramas entidad-relación para luego convertirlo en un diseño lógico.

Características:

Solo refleja  que hay datos

Incluyen todos los datos relevantes del sistema en estudio.

No está orientado a aplicaciones específicas

No tiene restricciones de espacio, almacenamiento y tiempo de ejecución.

Abierto a la evolución del sistema

Es el modelo conceptual más utilizado

Elementos del modelo E/R

Entidad: Cualquier objeto real o abstracto que existe y acerca del cual se quiere almacenar datos.  Conjuntos de instancias, ocurrencias.

Se representa colocando el nombre de la entidad en un rectángulo.

Atributo: Propiedades y características de las entidades.  Son valores simples que se pueden decir de la entidad.  Se representa con un ovalo.

Se pueden presentar atributos de relaciones entre entidades.

Relación: Es una asociación entre 2 o más entidades.  Normalmente son verbos o formas verbales.  Se presenta entre un rombo.

         

  Compra = { <C1, P1>, <C1, P2>,<C2, P3>,<C3, P3>}

Tipos de relaciones explicadas con el ejemplo de relación. (ver documento Conceptos Modelo Entidad Relación access, Documentos de Apoyo)

1 a 1: A cada ocurrencia de la entidad CLIENTE le corresponde una y solo una ocurrencia de la entidad PRODUCTO

1 a varios (1:N): A cada ocurrencia de la entidad CLIENTE le corresponden varias ocurrencias de la entidad PRODUCTO y a cada  ocurrencia de la entidad PRODUCTO le corresponden solo una ocurrencia de la entidad CLIENTE.

Muchos a muchos (N:N):  A cada ocurrencia de la entidad CLIENTE le corresponden varias ocurrencias de la entidad PRODUCTO y a cada  ocurrencia de la entidad PRODUCTO le pueden corresponder varias ocurrencias de la entidad CLIENTE.

Relaciones entre tablas

Access  es un  gestor de base de datos relacional, entre otras cosas, porque permite establecer vínculos o relaciones entre las tablas que lo componen. El objetivo de estas relaciones sería principalmente evitar la duplicidad de información y en consecuencia, optimizar el rendimiento de la base de datos.

Nota

Las relaciones son sin lugar a dudas uno de los conceptos de base de datos más complicados de entender pero no te preocupes, con algunos ejemplos y algo de práctica no tendrás ningún problema para establecer relaciones entre tablas.

Objetivos

• Comprender y establecer las relaciones entre tablas como paso imprescindible para aprovechar todo el potencial de nuestra base de datos.

• Distinguir los distintos tipos de relaciones.

• Configurar relaciones.

• Establecer las relaciones de la base de datos de ejemplo.

Concepto de relación

Las relaciones son un tema complejo pero veamos un sencillo ejemplo con las tablas Alumnos y Cursos para entenderlo mucho mejor. Inicialmente nuestras tablas estarían definidas del siguiente modo:

En la tabla Alumnos tenemos toda la información que necesitamos sobre nuestros alumnos como:

• Su número de expediente.
• Su nombre y apellidos.
• Su fecha de nacimiento.
• El grupo al que pertenece el alumno.
• La ubicación del grupo, es decir, el aula donde están los alumnos de ese grupo (Primera planta, edificio anexo, etcétera).
• Cualquier tipo de comentario de interés: grupo de compensatoria, apoyo, etcétera.

Para la tabla Grupos nos podíamos conformar con la denominación del grupo (1A, 1B, 3A...) pero le hemos añadido algunos datos que nos pueden resultar de interés:

• Número total de alumnos que tiene el grupo.
• El lugar donde se encuentra ubicado: Aula de música, Aula 205 Edificio principal, etcétera.
• Cualquier otro dato de interés: Compensatoria, grupo de apoyo, etcétera.

Si saber nada de bases de datos y de relaciones podemos, darnos cuenta que al comprobar los datos incluidos en las tablas de Alumnos y Grupos existe información que se repite en ambas:

Esta situación no es demasiado favorable cuando trabajamos con bases de datos donde habitualmente la cantidad de información que se maneja es importante. La solución pasa por RELACIONAR las tablas con información coincidente de modo que no exista duplicidad de información. Todo esto, traducido a un lenguaje más natural sería: "Para qué escribir dos veces lo mismo, si puedo hacerlo una sola y trabajar del mismo modo".

Volviendo a nuestro ejemplo, si relacionamos las tablas Alumnos y Grupos mediante el nombre del grupo sería suficiente con indicar en la tabla Alumnos este valor para obtener el número de alumnos del grupo, su ubicación y las posibles observaciones:

Tipos de relaciones

No siempre las condiciones para establecer vínculos entre dos tablas son iguales, la manera en que se relacionan las tablas entre sí da lugar a comportamientos diferentes. En la estructutura de cualquier base de datos encontramos principalmente tres tipos de relaciones que se describen del siguiente modo:

• Uno a muchos.
• Muchos a muchos.
• Uno a uno.

De todas ellas, la más utilizada y recomendable en la mayoría de los casos será el modelo Uno a muchos como veremos a continuación.

Uno a muchos

Veamos el primer modelo de relación tomando como referencia las tablas Alumnos y Grupos. Cualquier alumno (MUCHOS) pertenece sólo a un grupo (UNO), un alumno no puede estar en más de una clase. Pues bien, ni más ni menos que este sería el argumento de una relación MUCHOS A UNO.

Otro ejemplo, sabemos que cada profesor pertenece únicamente a un departamento, pero en cada departamento existe más de un profesor. De aquí podemos extraer una relación UNO a MUCHOS entre las tablas Departamentos y Profesores

En las relaciones de uno a muchos cada registro de una tabla A, a la que llamaremos tabla primaria, puede estar enlazado con más de un registro de otra tabla B, a la que llamaremos tabla secundaria. En cambio, cada registro de la tabla B sólo puede estar enlazado a un registro de la tabla A.

Nota

Uno a muchos o muchos a uno únicamente se diferencia en el sentido de la relación, es decir, si la tabla primaria se encuentra a la izquierda o derecha de la relación. En realidad se trata del mismo tipo de relación y sin lugar a dudas, la que más se utiliza.

 

Uno a uno

Las relaciones uno a uno no son demasiado frecuentes pero existen así que debemos conocerlas. Buscando alguna coincidencia en nuestro entorno que nos pueda servir como ejemplo encontramos el vínculo entre un tutor y su grupo. Como sabemos, un profesor puede ser tutor de un sólo grupo (UNO) y del mismo modo, cada grupo sólo puede tener un tutor. Esta sería una relación UNO a UNO

Cada registro de la tabla A se relaciona con un único registro de la tabla B y cada registro de la tabla B sólo se relaciona con un elemento de la tabla A. Como hemos comentado, este tipo de relaciones son poco comunes.

Muchos a muchos

Resumiendo lo visto hasta ahora podemos decir que el tipo de relación ideal es uno a muchos o muchos a uno. Las relaciones uno a uno no aportan demasiado a la base de datos, simplemente nos ayudan a tener mejor organizada la información pero poco más. Veamos qué ocurre con las relaciones muchos a muchos.

Por ejemplo, si queremos conocer los profesores que dan clase a un grupo o los grupos a los que da clase un profesor determinado, necesitamos en principio dos tablas: Profesores y Grupos. ¿Y cuál sería la relación entre estas dos tablas? Pues bien, para establecerla podríamos leer que un profesor da clases a varios grupos (1A, 1B, 2C, etcétera) y un grupo recibe clases de varios profesores (Carlos Pérez, Antonio García, etcétera). Por lo tanto, nos encontramos entre una relación MUCHOS A MUCHOS

Desde un punto de vista teórico diríamos que en las relaciones Muchos a muchos a cada registro de la tabla A se le pueden asociar varios registros de la tabla B y cada registro de la tabla B puede estar relacionado con más de un registro de la tabla A.

Otros ejemplos para ilustrar este modelo de relación podrían ser:

• Los alumnos que participan en las actividades deportivas del centro. Concretamente un alumno podría participar en más de un deporte (Fútbol, Baloncesto, etcétera) y a su vez cada equipo está formado por varios componentes. Esta relación también sería del tipo Muchos a muchos.
• Con las actividades extraescolares ocurre lo mismo. Un alumno puede asistir a más de una (manualidades, música, idiomas, etcétera) y en cada      una de ellas, encontraremos a varios alumnos.

Problemas y solución para las relaciones Muchos a muchos

Las relaciones Muchos a muchos no son recomendables y debemos tratar de evitarlas utilizando TABLAS INTERMEDIAS en las que se utilizarían relaciones de uno a muchos. Una tarea sencilla como podría ser obtener un listado de todos los profesores que imparten clases en 1ºB se convierte en una verdadera pesadilla si mantenemos esta relación. La solución pasa por crear una TABLA INTERMEDIA que nos permita dividir la relación MUCHOS A MUCHOS en dos relaciones UNO A MUCHOS como puedes ver en la figura

2.34.

Figura 2.34 

Importante

En documentación relacionada con bases de datos también podrás encontrar que utilizan otra terminología para identificar las relaciones, concretamente es común utilizar: uno a varios, varios a uno, varios a varios, etcétera.

Establecer relaciones entre tablas

Como requisito indispensable para establecer una relación entre dos tablas es necesario que ambas tablas tengan un campo en común. Observa la figura 2.35.

Figura 2.35 

Muy importante, los campos que se utilicen para establecer la relación entre las dos tablas deben ser del mismo tipo (INTEGER, TEXTO, SMALL INTEGER, etcétera). Habitualmente se suelen utilizar tipos enteros (INTEGER) para este propósito, aunque nos valdría igualmente cualquier otro tipo siempre y cuando sea el mismo en las dos tablas. Además, debes tener en cuenta lo siguiente:

• La propiedad Tamaño del campo debe ser igual en ambas tablas.
• Si el campo en la tabla primaria está definido como de Valor automático en la tabla secundaria debe estar definido como INTEGER.

El campo común debe ser Clave principal en la tabla primaria