Maestría en Bioinformática Bases de Datos y Sistemas de Información Del MER al MR Ing. Alfonso Vicente, PMP alfonso.vice

1. Maestría en BioinformáticaBases de Datos y Sistemas de InformaciónDel MER al MRIng. Alfonso Vicente, PMPalfonso.vicente@logos.com.uy

2. Agenda • Introducción Conceptos MER a MR

3. Agenda • Entidades fuertes • Discusión • Entidades débiles • Relaciones binarias Conceptos MER a MR

4. Agenda • Introducción Conceptos MER a MR

5. Conceptos • Introducción • Necesitamos desarrollar una aplicación para satisfacer determinados requerimientos • Por la naturaleza del problema la aplicación se beneficiaría de utilizar un RDBMS • Sabemos cómo realizar un modelo conceptual a partir de los requerimientos, utilizando el MER • Conocemos el Modelo Relacional, un modelo lógico más cercano a la implementación de una Base de Datos

6. Conceptos • Introducción • El paso lógico siguiente sería pasar del MER al MR • Relevamiento Modelado conceptual ??? • Necesitamos un algoritmo para hacer esto • Hay software que permite pasar del MER al MR de forma semi-automática (como brModelo), pero es necesario comprender el proceso • ¿Nos podríamos saltear el diseño conceptual y realizar directamente el diseño lógico? MR MER Requerimientos

7. Agenda • Entidades fuertes • Discusión • Entidades débiles • Relaciones binarias Conceptos MER a MR

8. MER a MR • Entidades fuertes • Ejemplo: entidad CLIENTE, con atributos simples, multivalorados, estructurados y determinantes • Necesitamos traducir esta entidad fuerte al MR

9. MER a MR • Entidades fuertes • Crearemos una relación por cada entidad fuerte del MER, con el mismo nombre pero en plural • Crearemos una columna en la relación por cada atributo simple del MER, con el mismo nombre • Crearemos una columna en la relación por cada hoja en la estructura de los atributos estructurados • Se especificarán claves correspondientes a cada conjunto de atributos determinantes, y una de ellas se elegirá (arbitrariamente, por ahora) como PK (Primary Key)

10. MER a MR • Entidades fuertes • Para los atributos multivaluados: • Se creará una nueva relación con una columna correspondiente al atributo multivaluado • Se agregarán las columnas correspondientes a la clave primaria de la relación que corresponde a la entidad fuerte, que serán una clave foránea • Se especificará además el conjunto de todas las columnas de la relación como una clave

11. MER a MR • Entidades fuertes • La entidad del ejemplo, podría traducirse al MR así:

12. MER a MR • Entidades fuertes • Se podría especificar, para cada columna, el tipo de datos y si admite o no el valor NULL. • Suele representarse subrayada la PK de cada relación. • Las FKs suelen representarse como una línea entre las relaciones participantes, terminada con el “crow’sfoot” del lado de la relación que tiene la FK. • Más allá de las posibilidades de notación de los diagramas de Modelo Relacional, conviene tomar nota de las claves y claves foráneas al pie del diagrama.

13. MER a MR • Discusión • ¿Qué hubiera pasado si la entidad CLIENTE hubiera tenido otro atributo determinante, por ejemplo: credencial? • Los dos hubieran constituido claves de la relación CLIENTES, de forma que hubiéramos tenido que elegir una de las dos claves para mantener en la relación TELEFONOS_CLIENTE.

14. MER a MR • Discusión • Cuando haya más de una clave candidata, las distinguiremos en dos tipos, una será la PRIMARY KEY, y elegiremos para esto una de las claves que no admita valores nulos. • A las claves restantes, admitan o no valores nulos, las llamaremos UNIQUE KEYS. • En nuestro ejemplo, si hubiéramos tenido un atributo determinante credencial, pero admitiera valores nulos, la columna cedula seguiría siendo la PRIMARY KEY, mientras que credencial sería una UNIQUE KEY.

15. MER a MR • Discusión • En ocasiones, una entidad no tiene una clave candidata claramente identificable, o bien tiene una compuesta de muchos atributos, y ya sabemos que la PK de una relación se “propaga”, por ejemplo cuando hay atributos multivaluados. • Para estos casos puede convenir “inventar” una clave para que funcione como PK. A esto lo llamaremos surrogatekey. • Al no tener semántica, una surrogatekey podría ser generada automáticamente por cualquier método que asegure la unicidad (por ejemplo un número secuencial)

16. MER a MR • Discusión • Para ilustrar el concepto de surrogatekey, veremos una debilidad del Modelo Relacional que hemos generado, observando una instancia de la relación CLIENTES. • ¿Qué problemas tiene esa instancia? • ¿Cómo podríamos solucionar esos problemas?

17. MER a MR • Discusión • Pueden existir valores para departamento que no corresponden a un departamento (San Gregorio), valores para ciudad que no corresponden a una ciudad (de Polanco), y combinaciones incorrectas de departamento y ciudad (no existe una ciudad La Paloma en Lavalleja). • Para solucionar el problema de los datos inexistentes, observamos que el problema radica en que los nombres de departamentos y ciudades deben pertenecer a un dominio mucho más reducido que el conjunto VARCHAR(30), por ejemplo.

18. MER a MR • Discusión • Podríamos pensar en mantener el conjunto de los nombres válidos de departamento, en una relación con una única columna; y lo mismo para ciudades. En cada caso, la única columna de la relación constituirá la Primary Key de la misma.

19. MER a MR • Discusión • Teniendo definidas estas relaciones y especificando ForeignKeys como las siguientes en la relación CLIENTES, solucionamos el problema de los departamentos y ciudades inexistentes: • {departamento} es FK en CLIENTES, y referencia a nombre en DEPARTAMENTOS • {ciudad} es FK en CLIENTES, y referencia a nombre en CIUDADES

20. MER a MR • Discusión • Parecería que la elección de la clave primaria en DEPARTAMENTOS y CIUDADES era la única posible, pero en estos casos, suelen utilizarse surrogatekeys, “inventando” una columna con un código para cada uno de los valores del dominio:

21. MER a MR Discusión

22. MER a MR • Discusión • Note que el MER no teníamos una entidad DEPARTAMENTO ni una entidad CIUDAD, sino que agregamos estas relaciones al Modelo Relacional para solucionar el problema de restringir los dominios de algunas columnas. • Estas relaciones especiales con códigos y valores formando un dominio, se conocen muchas veces como “codigueras”. • ¿Qué ganamos al agregar la surrogatekeycodigo en las nuevas relaciones?

23. MER a MR • Discusión • Por lo pronto: espacio • Imagine que para almacenar el nombre de una ciudad como “San Gregorio de Polanco” se necesitan 25 bytes (uno por cada carácter más dos para delimitar el fin de la cadena). • Si tenemos 1.000 clientes de San Gregorio de Polanco tendremos 25.000 bytes en la tabla CLIENTES dedicados a mantener esta información. Si podemos tener un código entero de 4 bytes para cada ciudad, ocuparemos 4.000 bytes en la tabla CLIENTES en lugar de 25.000 para mantener la misma información.

24. MER a MR • Discusión • En general as codigueras son elementos agregados en el Modelo Relacional, porque es difícil que el MER se haya considerado una restricción no estructural del tipo “El atributo departamento de la entidad CLIENTE debe ser uno de los siguientes: Montevideo, Canelones, …”; aunque es válido que existan este tipo de restricciones. • Las codigueras son muy comunes, y se pueden considerar como un patrón de diseño • [2 min] ¿Cómo evitamos las “malas combinaciones”, como: La Paloma - Lavalleja?

25. MER a MR • Entidades débiles • Consideremos, por ejemplo, la entidad débil SALON (débil respecto a CENTRO). • La entidad fuerte CENTRO, se mapearía a una relación CENTROS, con dos columnas: nombre (que será su PK) y dirección

26. MER a MR • Entidades débiles • La entidad débil SALON, se mapearía a una relación SALONES, que tendría columnas numero (la clave parcial de la entidad débil) y capacidad. • Pero las entidades débiles no tienen por sí mismas datos suficientes como para poder ser identificadas, por lo que dependen de otra, y más específicamente dependen de la clave de esa otra entidad para poder ser identificadas. • Por este motivo, la clave de la relación CENTROS se propagará a la relación SALONES, y será una Foreign Key en SALONES

27. MER a MR • Entidades débiles • Éste es un ejemplo de cómo quedaría el MR • El atributo nombre de la entidad CENTRO se cambió a nom_centro, ya que por ser la PK de CENTROS, debía propagarse a SALONES.

28. MER a MR • Entidades débiles • El algoritmo entonces para traducir una entidad débil al Modelo Relacional, una vez que se representó la entidad de la que depende, podría ser el siguiente: • Crear una relación con el mismo nombre pero en plural • Crear una columna en la relación por cada atributo simple, con el mismo nombre • Agregar las columnas que formen la PK de la relación correspondiente a la entidad de la que depende.

29. MER a MR • Entidades débiles • Especificar como PK las columnas que sean PK de la relación correspondiente a la entidad de la que ésta depende, más las columnas que forman la clave parcial de la entidad débil. • Especificar como FK las columnas que sean PK de la relación correspondiente a la entidad de la que ésta depende. • Si la entidad débil tiene atributos multivaluados o estructurados, traducirlos de la misma manera que en el caso de las entidades fuertes.

30. MER a MR • Relaciones binarias • Consideraremos tres tipos de relaciones, según su cardinalidad (1:1, 1:N y N:M) • En el caso de la entidad débil, ya hicimos la traducción de una relación 1:N • La forma de traducir una relación 1:N sirve para una relación 1:1, aunque también hay otras opciones

31. MER a MR • Relaciones binarias • Cuando tenemos relaciones 1:N : • Agregaremos en la tabla del lado de la cardinalidad N de la relación, la PK de la otra tabla (que será FK) y las columnas que correspondan a atributos de la relación. • La PK se propaga

32. MER a MR • Relaciones binarias • El Modelo Relacional podría quedar: • ¿Podría haber libretas sin chofer asociado? ¿Cómo podemos asegurarnos?

33. MER a MR • Relaciones binarias • Cuando tenemos relaciones N:M • Crearemos una nueva tabla para representar la relación, agregando la PK de cada una de las tablas, además de las columnas que correspondan a atributos de la relación • La PK de la nueva tabla será la combinación de las PK de las tablas que participan en la relación • Se deben especificar como FK, las PK de las tablas que participan en la relación

34. MER a MR • Relaciones binarias • Si tenemos, por ejemplo, que un chofer puede conducir varios vehículos, y un vehículo puede ser conducido por varios choferes, el MER podría ser el siguiente

35. MER a MR • Relaciones binarias • Y el Modelo Relacional: • También se podría utilizar para relaciones 1:N ¿con qué PK?

36. MER a MR • Relaciones binarias • Relaciones 1:1 • Consideremos el MER que pretende modelar la siguiente realidad: • Cada chofer se identifica por su cédula, y se mantiene su nombre y apellido. Se desea registrar la libreta de cada chofer, que se identifica por un número, y tiene una fecha de emisión y una fecha de vencimiento. Es de interés llevar un registro de dónde suele tener cada chofer su libreta (billetera, guantera del vehículo, etc.).

37. MER a MR • Relaciones binarias • El MER podría ser: • En este caso observamos que la relación es total del lado de LIBRETA. Esto significa que no es posible tener una libreta que no tenga asociado un chofer.

38. MER a MR • Relaciones binarias • Supongamos que ya se tradujeron las entidades fuertes: • Podemos agregar en la tabla con participación total, las columnas que correspondan a la PK de la otra tabla y columnas para los atributos de la relación (si los hay).

39. MER a MR • Relaciones binarias • ¿Podríamos haberlo hecho al revés?

40. MER a MR • Relaciones binarias • Otra opción, sería fundir las tablas, manteniendo la PK de la tabla que no tiene participación total, y dejando la PK de la tabla que tiene participación total como UK. • Note que esta opción • implica que se deban • permitir valores nulos • Podríamos tener valores no • nulos para las fechas de • emisión y vencimiento, y no • tener un número de libreta

41. MER a MR • Relaciones binarias • Cuando no hay ninguna tabla con participación total se puede elegir arbitrariamente una de las tablas para agregar en ella la PK de la otra, y definirla como FK, además de las columnas que correponden a atributos de la relación (igual a cuando había una tabla con participación total), aunque se debe considerar en este caso que los valores pueden ser nulos. • Otra opción es crear una tabla para la relación, que mantenga las PK de las dos tablas además de las columnas que corresponden a atributos de la relación (como en N:N)

42. MER a MR • Relaciones binarias • En resumen, las posibilidades son • (*) Cuidado con los NULL si no hay totalidad • (+) Cuidado al elegir la PK • Es un buen momento para preguntarse si no podría haber un cambio de requerimientos que determine un cambio en la cardinalidad (e.g. de una libreta por chofer a más de una, de autos no-compartidos a compartidos)

43. MER a MR • Relaciones n-arias (n > 2) • Siempre se creará una nueva tabla • Su clave será la unión de las claves de las entidades participantes de la relación (la excepción es cuando hay una cardinalidad 1, en ese caso, la clave será la que corresponde a la entidad del lado de la cardinalidad 1) • Se definirán las correspondientes claves foráneas • Sus agregarán los atributos de la relación, si los hubiera

44. MER a MR • Generalización / especialización • Tenemos varias opciones para transformar una generalización

45. MER a MR • Generalización / especialización • Opción 1 • Creamos una tabla para la entidad más general, como si fuera una entidad fuerte cualquiera • Creamos una tabla para cada sub-entidad, con sus atributos, y propagamos la PK de la entidad más general • Definimos las FKs desde las PKs de éstas últimas tablas, a la PK de la tabla que corresponde a la entidad más general

46. MER a MR • Generalización / especialización • Opción 1

47. MER a MR • Generalización / especialización • Opción 2 • Crear una tabla por cada sub-entidad, con sus atributos más los atributos de la entidad más general

48. MER a MR • Generalización / especialización • Opción 2 • Crear una sola tabla con todos los atributos (los de la entidad más general y los de las subentidades) más un atributo “tipo” que permita diferenciar las sub-entidades