ACTIVIDAD 1 

08/05/2018

1. Ingresar al siguiente link https://www.ite.educacion.es/formacion/materiales/93/cd/m2_3/concepto_de_relacin.html y copiar y pegar la siguiete información:

• Concepto de la Relación (En las bases de datos)
• Tipos de Relaciones (En las bases de datos)

2. Indentifcar que tipos de relaciones se dan entre las diferentes tablas de la BD_IEARM y explicarlas, ademas dibujarlas en Microsoft Powerpoint y subir o cargar el archivo resultante al gmail, dropbox y webnode de cada uno. 

3. Diagrama entidad realcion: Ingresar a los sigueintes links y documentar que es el modelo y diagrama entidad relación

 https://www.genbetadev.com/bases-de-datos/fundamento-de-las-bases-de-datos-modelo-entidad-relacion 

https://www.lucidchart.com/pages/es/qu%C3%A9-es-un-diagrama-entidad-relaci%C3%B3n

4. En Microsoft Excel Dibujar o Diseñar el Modelo Entidad Realacion para pa BD_IEARM y subir o cargar el archivo resultante al gmail, dropbox y webnode de cada uno.

 https://trecnologiaeinformatica-iearm.webnode.es/novenos/tecnologia-e-informatica/actividades/actividad-1/

SOLUCION

1)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. 

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.

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.

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.

4)  https://www.genbetadev.com/bases-de-datos/fundamento-de-las-bases-de-datos-modelo-entidad-relacion

Las bases de datos son un gran pilar de la programación actual, ya que nos permiten almacenar y usar de forma rápida y eficiente cantidades ingentes de datos con cierta facilidad. En la actualidad se usa de forma mayoritaria las bases de datos relacionales (dominadas por distintos gestores a través del lenguaje SQL, en gran medida).

Pero ahora vamos a dar un pequeño repaso a lo más esencial del modelo entidad-relación, que es y ha sido durante años la mejor forma de representar la estructura de estas bases de datos relacionales (o de representar sus esquemas).

¿Qué es el modelo entidad-relación?

Como ya he comentado este modelo es solo y exclusivamente un método del que disponemos para diseñar estos esquemas que posteriormente debemos de implementar en un gestor de BBDD (bases de datos). Este modelo se representa a través de diagramas y está formado por varios elementos.

Este modelo habitualmente, además de disponer de un diagrama que ayuda a entender los datos y como se relacionan entre ellos, debe de ser completado con un pequeño resumen con la lista de los atributos y las relaciones de cada elemento.

Elementos del modelo entidad-relación

Entidad

Las entidades representan cosas u objetos (ya sean reales o abstractos), que se diferencian claramente entre sí.

Para poder seguir un ejemplo durante el artículo añadiré ejemplos sobre un taller mecánico, donde se podría crear las siguientes entidades:

• Coches (objeto físico): contiene la información de cada taller.
• Empleado (objeto físico): información de los trabajadores.
• Cargo del empleado (cosa abstracta): información de la función del empleado.

Estas entidades se representan en un diagrama con un rectángulos, como los siguientes.

Atributos

Los atributos definen o identifican las características de entidad (es el contenido de esta entidad). Cada entidad contiene distintos atributos, que dan información sobre esta entidad. Estos atributos pueden ser de distintos tipos (numéricos, texto, fecha...).

Siguiendo el ejemplo de antes podemos analizar los atributos de nuestra entidad "Coches", que nos darán información sobre los coches de nuestro supuesto taller.

Unos posibles atributos serían los siguientes: número de chasis, matrícula, DNI del propietario, marca, modelo y muchos otros que complementen la información de cada coche.

Los atributos se representan como círculos que descienden de una entidad, y no es necesario representarlos todos, sino los más significativos, como a continuación.

En un modelo relacional (ya implementado en una base de datos) una ejemplo de tabla dentro de una BBDD podría ser el siguiente.

5tfem5f10ax007210                                               4817 BFK                                                                         45338600L

6hsen2j98as001982                                              8810 CLM                                                                       02405068K

5rgsb7a19js001982                                                0019 GGL                                                                        40588860J

Este ejemplo es con tres atributos, pero un coche podría tener cientos (si fuese necesario) y seguirían la misma estructura de columnas, tras implementarlo en una BBDD.

Relación

Es un vínculo que nos permite definir una dependencia entre varias entidades, es decir, nos permite exigir que varias entidades compartan ciertos atributos de forma indispensable.

Por ejemplo, los empleados del taller (de la entidad "Empleados") tienen un cargo (según la entidad "Cargo del empleado"). Es decir, un atributo de la entidad "Empleados" especificará que cargo tiene en el taller, y tiene que ser idéntico al que ya existe en la entidad "Cargo del empleado".

Las relaciones se muestran en los diagramas como rombos, que se unen a las entidades mediante líneas.

Yo, bajo mi punto de vista, entiendo mejor esto en una tabla (de una implementación en una BBDD), por lo que voy a poner el ejemplo de como se representaría (resaltada la relación, que posteriormente veremos como se haría).

Empleados

Nombre                                                                         DNI                                                                                          Cargo
Carlos Sánchez                                                             45338600L                                                                               001
Pepe Sánchez                                                               02405068K                                                                              002
Juan Sánchez                                                                40588860J                                                                               002 

Cargo del empleado

ID                                                                             del cargo Descripción
001                                                                              Jefe de taller
002                                                                              Mecánico 

Relaciones de cardinalidad

Podemos encontrar distintos tipos de relaciones según como participen en ellas las entidades. Es decir, en el caso anterior cada empleado puede tener un cargo, pero un mismo cargo lo pueden compartir varios empleados.

Esto complementa a las representaciones de las relaciones, mediante un intervalo en cada extremo de la relación que especifica cuantos objetos o cosas (de cada entidad) pueden intervenir en esa relación.

Uno a uno: Una entidad se relaciona únicamente con otra y viceversa. Por ejemplo, si tuviésemos una entidad con distintos chasis y otra con matrículas deberíamos de determinar que cada chasis solo puede tener una matrícula (y cada matrícula un chasis, ni más en ningún caso).

Uno a varios o varios a uno: determina que un registro de una entidad puede estar relacionado con varios de otra entidad, pero en esta entidad existir solo una vez. Como ha sido en el caso anterior del trabajador del taller. 

Varios a varios: determina que una entidad puede relacionarse con otra con ninguno o varios registros y viceversa. Por ejemplo, en el taller un coche puede ser reparado por varios mecánicos distintos y esos mecánicos pueden reparar varios coches distintos. 

Los indicadores numéricos indican el primero el número mínimo de registros en una relación y posteriormente el máximo (si no hay límite se representa con una "n").

Claves

Es el atributo de una entidad, al que le aplicamos una restricción que lo distingue de los demás registros (no permitiendo que el atributo específico se repita en la entidad) o le aplica un vínculo (exactamente como comentábamos en las relaciones). Estos son los distintos tipos:

Superclave: aplica una clave o restricción a varios atributos de la entidad, para así asegurarse que en su conjunto no se repitan varias veces y así no poder entrar en dudas al querer identificar un registro.

Clave primaria: identifica inequívocamente un solo atributo no permitiendo que se repita en la misma entidad. Como sería la matrícula o el número de chasis de un coche (no puede existir dos veces el mismo).

Clave externa o clave foránea: este campo tiene que estar estrictamente relacionado con la clave primaria de otra entidad, para así exigir que exista previamente ese clave. Anteriormente hemos hablado de ello cuando comentábamos que un empleado indispensablemente tiene que tener un cargo (que lo hemos representado numéricamente), por lo cual si intentásemos darle un cargo inexistente el gestor de bases de datos nos devolvería un error.

Resumen

Esto ha sido solo un repaso por encima de lo que es el modelo entidad-relación, sin entrar en grandes detalles.

También, bajo mi punto de vista, creo que es una buena forma de diseñar correctamente las bases de datos, aunque algunas veces resulta más rápido implementarlo directamente en nuestro gestor de BBDD sin la necesidad de crear un gran diagrama, sino usando notas más simples.

https://www.lucidchart.com/pages/es/qu%C3%A9-es-un-diagrama-entidad-relaci%C3%B3n

Qué es un diagrama entidad-relación

Aprende lo básico de los diagramas ER y los modelos ER, además de sus orígenes, usos, ejemplos, componentes, limitaciones y pautas sobre cómo dibujarlos usando nuestra herramienta de diagramas ER.