From Ibbddunq

Contents 1 Nota inicial 2 Contexto 3 Ejemplo del circo 4 Introducción 4.1 puntapié inicial 4.2 tabla 4.3 primer comparación entre los dos modelos 4.4 modelemos un par más de entidades MER 5 Modelado 5.1 clave primaria 5.2 modelado de relaciones MER y concepto de FK 5.2.1 viveEn - 1-N 5.2.2 perteneceA - 1-1 5.2.3 puedeParticipar - N-M 5.2.4 esElMaestro - 1-N de una tabla consigo misma 5.3 acá viene bien un repasito 5.4 Qué hago con atributos compuestos y/o multivaluados 5.5 Qué hago con entidades débiles 5.6 Qué hago con atributos de relaciones 6 Operaciones 6.1 Insert 6.2 Motivación para las restricciones 6.3 Restricciones de integridad 6.4 Inserts anómalos 6.5 Delete, felices y anómalos 6.6 Update, felices y anómalos

Nota inicial

Mara, posta, creo que el nombre "relación" confunde, tenés que aclarar todo el tiempo cuándo estás hablando de una relación MER y cuándo de una relación MR.

¿No podemos decir "tabla" y ya? OK, es menos matematicoso, pero ¿jode?

Contexto

Es la tercer clase. En la primera se ve la introducción, en la segunda MER. Si quedó algo por ver de MER, se roba un cachito de la práctica del lunes siguiente.

Como ejemplo para apoyarnos al dar MER vemos el ejemplo del circo, y nos paramos en este ejemplo también para ir contando modelo relacional. Sería bueno arrancar la clase con el dibujo del MER en el pizarrón, al menos la parte que vamos a traducir.

En una clase debería entrar la descripción del modelo relacional, si quedó algo por decir se le puede robar un ratito a la siguiente clase, que es la primera de dos de álgebra relacional.

Ejemplo del circo

Tenemos estas tablas

 artista <fnac, nombreReal, nombreArt, cachet,    % fnac: fecha de nacimiento
          viveEn_patente,                         % relación viveEn 1-N con trailer
          art_numero, art_nombreArt,  
          art_fechaInscripcion, art_valorCuota,   % atributo compuesto inscripción ART
          maestro_fnac, maestro_nombreArt         % relación esElMaestro 0..3 (maestro) - 1 (alumno)
                                                  % (o sea, cada maestro hasta 3 alumnos, cada
                                                  %  alumno un maestro) artista con artista
         >
 clave fnac + nombreArt

 acto <nombre, gradoPeligrosidad>
 clave nombre

 puedeParticipar <artista_fnac, artista_nombreArt, acto_nombre>
 es una relación N-M entre artista y acto
 clave: los tres 

 trailer <patente, marca, modelo, maxOcupantes>
 clave: patente

 delineadorDeOjos <delin_nro, color, precio, fechaCompra, 
                   art_fnac, art_nombreArt                % relación perteneceA 1-1 con artista
                  >
 clave: delin_nro
 

Introducción

puntapié inicial

vamos a ver un nuevo modelo de datos, que es distinto al anterior. Como dijimos al principio (de verdad lo dije la 1er clase) es un modelo lógico, que va a servirnos para poder implementarlo en un DBMS.

tabla

En este modelo hay un solo concepto central, el de relación o tabla. Para complicarnos la vida, en este modelo hay un concepto llamado "relación", en el MER también, y no son lo mismo.

En el MER partimos de los conceptos separados de entidad y relación, acá tenemos uno solo, relación o tabla. Una BD es un conjunto de relaciones, en detalle

• un esquema de BD va a ser un conjunto de esquemas de relación.
• una instancia de BD va a ser un conjunto de instancias de relación.

P.ej. en el MER tengo la entidad Artista, acá vamos a tener la tabla artista.

Una relación es

• a nivel esquema, un conjunto de atributos, cada uno con su dominio. Definimos el esquema de la relación artista, con solamente fecha de nacimiento, nombre real, nombre artístico, cachet, aclaramos que después le vamos agregando el resto.
• a nivel instancia, una instancia de relación va a tener toda la información que uno quiere representar en la relación; en el ejemplo, una instancia de artista va a contener toda la información acerca de los artistas en una instancia de BD.
  

En una misma instancia va a haber info de distintos artistas ... Anotamos un par de filas de artista.

Una misma instancia de relación va a tener lo que vamos a llamar muchas filas o tuplas, cada fila/tupla va a tener un valor para cada atributo.

Lo vemos sobre el ejemplo. Marcamos en el dibujo de la tabla qué parte es el esquema y qué parte es la instancia. Introducimos la notación

 artista <fnac, nombreReal, nombreArt, cachet>

para el esquema.

primer comparación entre los dos modelos

lo que modelábamos por separado como entidades o relaciones en el MER, acá lo vamos a modelar siempre como relaciones, de estas relaciones (que son otra cosa que lo que se llama "relación" en el MER).

Lo que es una entidad en el MER se traduce como una, o varias, relaciones del MR.

Lo que es una relación en el MER se traduce como una o varias relaciones, y/o atributos adicionales en alguna de las entidades relacionadas.

Ahora vamos a ver en detalle algunas características del MR, viendo cómo las usamos para armar, a partir de un MER, un MR que sirva para representar la misma info.

modelemos un par más de entidades MER

acto, trailer, delineadorDeOjos. Ponerle un par de filas a las instancias. Agregar un par de artistas más, llegar a 4 ó 5.

Modelado

clave primaria

para cada esquema de relación tengo que definir su clave primaria, que es un conjunto de atributos. El concepto es el mismo que en el MER: que el conjunto de atributos identifique, de forma tal que no pueda haber dos filas en la misma instancia de tabla con el mismo valor en todos los atributos de la clave.

Para cada una de estas, llegar a determinar la clave, indicando los supuestos semánticos que nos llevan a elegirla, y apoyándose en ejemplos.

• artista: empezar con nombre artístico, agregar después fecha de nacimiento
• acto
• trailer
• delineador de ojos

modelado de relaciones MER y concepto de FK

Para incluir una relación MER en un esquema de BD que estamos armando con el modelo relacional, pueden pasar en principio dos cosas (las excepciones van a venir en un rato)

1. agregamos la información que nos da la relación en atributos que agregamos a tablas que ya tenemos.
2. tenemos que agregar una tabla nueva para modelar específicamente la relación.

Mientras podemos elegir, hacemos lo primero; no creamos tablas sin necesidad.

viveEn - 1-N

Empecemos con viveEn. ¿Hace falta agregar una tabla nueva? Vamos con algo bien concreto: el artista pepitito vive en el trailer AJX-438, ¿dónde puedo poner esa info en las tablas?

Llegar a que se agrega un atributo más en artista, y que no serviría en trailer

"Vean el MER, ¿con qué pueden relacionar que el atributo va del lado del artista?" Llegar a que en lo que hay que fijarse es la cardinalidad, en una relación 1-N va del lado del "1". Repasar qué quiere decir artista 1 - trailer N en términos del MER

• una instancia de artista no puede aparecer en muchas instancias de la relación, o sea, un mismo artista no puede estar relacionado con varios trailers.
• cómo es con el trailer.

esto da rationale para darse cuenta de qué lado quedó el atributo.

Definir fk: atributo/s de una tabla cuyo/s valor/es en cada fila es una referencia a una fila de otra tabla, entonces pongo los valores de la pk de la fila que quiero relacionar. Esta defi: leerla, e ir viendo cómo se entiende en el ejemplo.

Indicar que un esquema de BD incluye la defi de las fk, escribir la que agregamos.

perteneceA - 1-1

Vamos con perteneceA ... listo. Conclusiones

• se puede poner de cualquiera de los dos lados, ambos son "1"
• si la clave de la tabla externa (foreign=externa) tiene varios atributos, la fk va a tener varios atributos. X eso dejarla del lado del delineador, así se ve.

puedeParticipar - N-M

acá no tengo "1" de ningún lado, ¿qué hacemos? probar con atributos agregados en c/u ... no funca ... ¿entonces?

llegar a que necesitamos una tabla ad-hoc

esElMaestro - 1-N de una tabla consigo misma

importancia de los nombres de los roles acá, ¿qué nombres le pongo a los atributos que agrego?

acá viene bien un repasito

... ya tenemos los conceptos principales que nos permiten entender un MR y traducir un MER ... recorrer el ejemplo, mencionar un par de cosas, aclarar que faltan algunas cositas que vemos ahora. Tal vez sea un buen momento para el recreo.

Qué hago con atributos compuestos y/o multivaluados

Qué hago con entidades débiles

Qué hago con atributos de relaciones

Operaciones

El MR no solamente me da conceptos para modelar la organización de la info, sino también me da formas de modelar qué operaciones voy a hacer sobre una BD. Esto para poder estudiar en detalle cómo se va a portar mi BD en un DBMS, el MR es un modelo que se puede llevar a la máquina.

Operaciones hay ... muchas, las ppales son

• actualización de una instancia
• consultas complejas sobre la info en una instancia

Vamos con la primera, ¿qué puedo hacer con una instancia? ... que tiren ... llegar a que la unidad es la fila, entonces puedo: agregar, borrar, o modificar filas.

Insert

ejemplos.

Motivación para las restricciones

¿vale hacer cualquier insert? A veeeer ... hay algunas que no porque la instancia de BD "queda fea".

El modelo relacional define qué condiciones debe cumplir una instancia de BD para ser adecuada, que se llaman restricciones de integridad.

A cualquier cosa que provoque que una instancia íntegra deje de serlo lo llamamos anomalía de integridad, que siempre se van a dar por operaciones. Podemos decir que hay, dada una instancia de BD

• operaciones felices
• operaciones anómalas

Vamos a definir formalmente las restricciones, y después vemos algunas operaciones anómalas.

Restricciones de integridad

Son 4

1. dominio (no vale valor que no esté en dominio del atributo correspondiente)
2. clave (dos filas en la misma relación no pueden tener = valor para todos los atributos de la PK)
3. integridad de entidad (los atributos en pk no pueden tener valor null - ¿de quién estoy hablando?)
4. integridad referencial (fk deben ser pk en relación referenciada)

Inserts anómalos

Al efectuar esta operacion podriamos violar alguna de las restricciones:

  Artista<*Nombre*:String, fNac:date, nacionalidad:string, cachet:int,mail,viveEn>

• Restriccion de Dominio: Que no tienen un valor de atributo adecuado:

 Artista <-- (José Gómez,21/01/82, argentino, $350, lalala, trailer1)

• Restriccion de Clave

 Artista<-- (José Gómez,11/12/80, panameño, $400,jg@artistas.circo.ar,trailer1)

• Restriccion de integridad de Entidad

 Artista<-- (Null,11/12/80, panameño, $400,jg@artistas.circo.ar,trailer1)

• Restriccion de Integridad Referencial

 Artista<-- (José Gómez,21/01/82, argentino, $350,lalala,trailerZ)
 (trailerZ no es una clave válida en la tabla Trailer)

Delete, felices y anómalos

Al efectuar esta operacion podemos violar la restricción de Integridad Referencial

• Esquema

Artista <-ViveEn-> Trailer

• Instancia

 Artista
 (José Gómez,21/01/82, argentino, $350, lalala, trailer1)
 Trailer
 (trailer1, DQM320, 100000km) <-- se elimina esta tupla

OJO con la integridad referencial, una operación en una tabla puede generar una anomalía en otra tabla.

Update, felices y anómalos

• Restriccion de Dominio: Que no tienen un valor de atributo adecuado:
  • Reemplazar:

 Artista <-- (José Gómez,21/01/82, argentino, $350, jg@artistas.circo.ar, trailer1)

• • Por:

 Artista <-- (José Gómez,21/01/82, argentino, $350, ???, trailer1)

• Restriccion de Clave
  • Reemplazar:

 Artista <-- (María Gómez,11/12/80, panameño, $400,mg@artistas.circo.ar,trailer2)

• • Por:

 Artista <-- (José Gómez,11/12/80, panameño, $400,mg@artistas.circo.ar,trailer2)

• Restriccion de integridad de Entidad
  • Reemplazar:

 Artista <-- (María Gómez,11/12/80, panameño, $400,mg@artistas.circo.ar,trailer2)

• • Por:

 Artista <-- (NULL,11/12/80, panameño, $400,mg@artistas.circo.ar,trailer2)

• Restriccion de Integridad Referencial
  • Reemplazar:

 Artista<-- (José Gómez,21/01/82, argentino, $350,lalala,trailer1)

• • Por:

 Artista<-- (José Gómez,21/01/82, argentino, $350,lalala,trailerZ)  
 (trailerZ no es una clave válida en la tabla Trailer)