Relación
Describe cierta dependencia entre entidades o permite la asociación de las mismas.
Ejemplo:
Dadas dos entidades "Habitación 502" y "Mark", es posible relacionar que la
habitacion 502 se encuentra ocupada por el huésped de nombre Mark.
Tipos de Relaciones
Relaciones "uno a uno"
Estas relaciones entre bases de datos se dan cuando cada campo clave aparece sólo una vez en cada una de las tablas.
Tomando un ejemplo del mundo real, una clara relación de "uno a uno" podría ser, el nombre de cualquier persona y su número de teléfono. Si partimos del supuesto en que cada persona tiene un solo número de teléfono, se podría hablar de una relación "uno a uno".
Gráficamente, se podría representar de la siguiente manera:
Este tipo de relaciones se caracteriza porque cada uno de los campos define a aquél con el que se relaciona. Es decir, conociendo el nombre de una persona podemos conocer su número telefónico. O si sabemos su número telefónico, podemos identificar al dueño. En estos cases, se suele aconsejar incluir todos los datos dentro de una sola tabla.
Relaciones de "uno a varios"
El ejemplo del caso anterior (cada persona, un teléfono), si bien es correcto teóricamente, es muy improbable desde el punto de vista de la realidad. Con la gran expansión de los teléfonos, por lo general, cada persona tiene un número de teléfono fijo, y además del teléfono móvil. Debemos tener en cuenta que del de su casa también tendrá un número de teléfono de empresa, y que quizá también sus móviles estén divididos en ocio y trabajo.
Por ello, debemos tener nuestras bases de datos preparadas para ello. Este tipo de relaciones es conocido como "uno a varios", y se podría representar de la siguiente manera:
En este caso, lo aconsejable no es almacenar todos los datos en una sola tabla, sino lo eficiente es hacerlo en tablas separadas, utilizando el identificador ID para relacionarlas.
Echemos un vistazo a la figura anterior. En la taba Nombre almacenamos el nombre y apellido, con su ID o número identificador. En la otra tabla, Teléfonos, almacenamos únicamente números de teléfono, con su correspondiente número identificador, en este caso TID. La manera en que se relaciona una con otra es mediante el identificador ID, que está presente en ambas tablas.
A simple vista podemos advertir que la primera de las personas de la tabla nombres, Juan Timaná, tiene 2 números telefónicos, pues su ID, que en este caso es 1, aparece en dos de los teléfonos de la otra tabla.
De este modo será mucho más sencillo cambiar, eliminar o ampliar los números de teléfono en la misma tabla.
Si estas tablas están creadas en MySQL, la sentencia que nos ayudaría a encontrar todos los teléfonos de una determinada persona sería:
SELECT n.nombre, t.telf
FROM nombre n
INNER JOIN telefonos t ON n.id = t.id
WHERE n.nombre = "Juan Timaná"
FROM nombre n
INNER JOIN telefonos t ON n.id = t.id
WHERE n.nombre = "Juan Timaná"
Relaciones de "varios con varios"
La última de las relaciones que podemos encontrar es la de "varios con varios". Dado que en la vida las cosas rara vez son sencillas, éste será el tipo de relación que nos encontraremos más a menudo.
Volviendo al tema de los teléfonos, hemos encontrado la manera de relacionar cada una de las personas con sus diversos teléfonos: el de su casa, el de su empresa, el móvil. Pero no será extraño tener en nuestra base de datos diversas personas que trabajen en la misma empresa, por lo que el número de su trabajo será el mismo, o miembros de una misma familia, por lo que compartirán el mismo teléfono de su hogar.
¿Cómo tratar este tipo de relaciones? Si nos limitamos a repetir dicho número de tablas, estaremos creando problemas de redundancia de datos, que a largo plazo lastrarán la rapidez y eficacia de nuestras tablas.
Este tipo de relaciones podría ilustrarse de la siguiente manera:
Como vemos, cada elemento de la base de datos puede relacionarse libremente con uno o varios miembros de las distintas tablas.
En estos casos no hay una regla fija a la que podamos acogernos, pero lo aconsejable es aproximarse lo más posible a la realidad, y no dudar en establecer tablas intermedias que nos ayuden a asociar mejor los datos.
Volviendo al tema de los teléfonos, imaginemos que varias personas de nuestra tabla trabajan en la misma empresa ACME Productions tiene varias líneas, por lo que los números de teléfono de trabajo de estas personas serían varios. ¿Cómo representarlo en nuestra base de datos?
En este caso hemos creado una tabla intermedia llamada "empresas". En la tabla "nombres" incluimos un nuevo campo TID, que se relaciona con la tabla "empresas", y es esta tabla la que se relaciona directamente con los teléfonos. De esta manera, podemos almacenar todos los datos con facilidad sin tener que repetir un sólo número telefónico.
Diagrama entidad-relación
Formalmente, los diagramas E-R son un lenguaje gráfico para describir conceptos. Informalmente, son simples dibujos o gráficos que describen la información que trata un sistema de información y el software que lo automatiza, pasos a seguir para el diagrama entidad-relación:
- Una entidad se relaciona con otra entidad con una línea continua, ya que no lleva flechas, es solo una dirección continua.
- Toda relación debe de llevar una cardinalidad (determina el nivel de cardinalidad).
- Una relación entre dos entidades siempre se va a dar por medio de un rombo (si tienes una entidad alumno, otra materia, se traza una línea en el medio de la línea se pone un rombo, dentro del rombo se pone "el alumno se inscribe", el nivel seria uno a muchos ya que el alumno se inscribe a varias materias).
- Cada entidad deberá tener sus elementos.
Entidad
Se representa mediante un rectángulo o "caja" etiquetada en su interior mediante un identificador. Ejemplos de entidades habituales en los sistemas de información son: factura, persona, empleado,salario etc.
Atributo
Se representan mediante un círculo o elipse etiquetado mediante un nombre en su interior. Cuando un atributo es identificativo de la entidad se suele subrayar dicha etiqueta.
Relaciones
Se representa mediante un rombo etiquetado en su interior con un verbo. Este rombo se debe unir mediante líneas con las entidades (rectángulos) que relaciona.
Por motivos de legibilidad, los atributos no suelen representarse en un diagrama entidad-relación, sino que se describen textualmente en otros documentos adjuntos.
INTEGRIDAD REFERENCIAL |
Cuando se define una columna como clave foránea, las filas de la tabla pueden contener en esa columna o bien el valor nulo (ningún valor), o bien un valor que existe en la otra tabla, un error sería asignar a un habitante una población que no está en la tabla de poblaciones. Eso es lo que se denomina integridad referencial y consiste en que los datos que referencian otros (claves foráneas) deben ser correctos. La integridad referencial hace que el sistema gestor de la base de datos se asegure de que no haya en las claves foráneas valores que no estén en la tabla principal. La integridad referencial se activa en cuanto creamos una clave foránea y a partir de ese momento se comprueba cada vez que se modifiquen datos que puedan alterarla. ¿Cuándo se pueden producir errores en los datos?  Cuando insertamos una nueva fila en la tabla secundaria y el valor de la clave foránea no existe en la tabla principal. insertamos un nuevo habitante y en la columna población escribimos un código de población que no está en la tabla de poblaciones (una población que no existe).Cuando modificamos el valor de la clave principal de un registro que tiene 'hijos', modificamos el código de Valencia, sustituimos el valor que tenía (1) por un nuevo valor (10), si Valencia tenía habitantes asignados, qué pasa con esos habitantes, no pueden seguir teniendo el código de población 1 porque la población 1 ya no existe, en este caso hay dos alternativas, no dejar cambiar el código de Valencia o bien cambiar el código de población de todos los habitantes de Valencia y asignarles el código 10.Cuando modificamos el valor de la clave foránea, el nuevo valor debe existir en la tabla principal. Por ejemplo cambiamos la población de un habitante, tenía asignada la población 1 (porque estaba empadronado en valencia) y ahora se le asigna la población 2 porque cambia de lugar de residencia. La población 2 debe existir en la tabla de poblaciones.Cuando queremos borrar una fila de la tabla principal y ese registro tiene 'hijos', por ejemplo queremos borrar la población 1 (Valencia) si existen habitantes asignados a la población 1, estos no se pueden quedar con el valor 1 en la columna población porque tendrían asignada una población que no existe. En este caso tenemos dos alternativas, no dejar borrar la población 1 de la tabla de poblaciones, o bien borrarla y poner a valor nulo el campo población de todos sus 'hijos'.Asociada a la integridad referencial están los conceptos de actualizar los registros en cascada y eliminar registros en cascada. |
Actualización y borrado en cascada |
El actualizar y/o eliminar registros en cascada, son opciones que se definen cuando definimos la clave foránea y que le indican al sistema gestor qué hacer en los casos comentados en el punto anterior.  Actualizar registros en cascada: Esta opción le indica al sistema gestor de la base de datos que cuando se cambie un valor del campo clave de la tabla principal, automáticamente cambiará el valor de la clave foránea de los registros relacionados en la tabla secundaria. Por ejemplo, si cambiamos en la tabla de poblaciones (la tabla principal) el valor 1 por el valor 10 en el campo código (la clave principal), automáticamente se actualizan todos los habitantes (en la tabla secundaria) que tienen el valor 1 en el campo población (en la clave ajena) dejando 10 en vez de 1. Si no se tiene definida esta opción, no se puede cambiar los valores de la clave principal de la tabla principal. En este caso, si intentamos cambiar el valor 1 del código de la tabla de poblaciones , no se produce el cambio y el sistema nos devuelve un error o un mensaje que los registros no se han podido modificar por infracciones de clave. Eliminar registros en cascada: Esta opción le indica al sistema gestor de la base de datos que cuando se elimina un registro de la tabla principal automáticamente se borran también los registros relacionados en la tabla secundaria. Por ejemplo: Si borramos la población Onteniente en la tabla de poblaciones, automáticamente todos los habitantes de Onteniente se borrarán de la tabla de habitantes. Si no se tiene definida esta opción, no se pueden borrar registros de la tabla principal si estos tienen registros relacionados en la tabla secundaria. En este caso, si intentamos borrar la población Onteniente, no se produce el borrado y el sistema nos devuelve un error o un mensaje que los registros no se han podido eliminar por infracciones de clave. |
SITUACIÓN DE APRENDIZAJE
Katty debe realizar una base de Datos para las votaciones a Presidencia del 2010. Ya tiene claro cuales son los objetos que va a representar, pero no sabe como se relacionan.
Imagen extraída de http://www.lacapitalnet.com.ar/hoy/ElMundo/Img/200807141558-24C.jpg
PREGUNTA GENERADORA
¿Cuáles tipos de relaciones son posibles?
¿Cómo se construyen las relaciones?
ACTIVIDADES CURRICULARES:
· ACTIVIDAD 1:
Tarea 1:
Encuentre todos los objetos que participan en el problema (mínimo 8)
Tarea 2:
Por cada una seleccione la clave principal.
Tarea 3:
Construya las relaciones y entregue el ejercicio en grupos de a dos en hoja cuadriculada de examen.
HERRAMIENTAS DE ANDAMIAJE
EVALUACIÓN:
· Autoevaluación: El estudiante realiza una lista de los conocimientos adquiridos durante el proceso y cuales son los puntos en los que tiene déficit.
· Heteroevaluación: El docente realiza una inspección de los avances que van teniendo los estudiantes para crear estrategias para mejorar.
RECURSOS:
Físicos: Aula, Computadores, Internet, Tablero, Cuaderno.
Material Teórico: Informática, Videos
Humanos: Docente y Estudiantes
BIBLIOGRAFÍA Y CIBERGRAFÍA
Entradas
0 comentarios:
Publicar un comentario