El modelo ER como extension de UML Diciembre 2008
JosĂŠ A. GarcĂa jagarcia@siteframe.tk
¿Por qué necesitamos una BBDD? Una BBDD Mantiene el estado del sistema asegurando la coherencia y la unicidad de los datos. Una BBDD provee un mecanismo rápido y eficaz para extraer información conectada Una BBDD asegura la seguridad en el acceso y la modificación de los datos Una BBDD es capáz de reaccionar ante la modificación de los datos para mantener actualizados indices y vistas y generar información de valor.
Que debe hacer la BBDD • Persistir la información del estado de un sistema mediante estructuras relacionadas de datos almacenados de forma plana, atomica, univoca y no recurrente.
Que debe hacer la BBDD • Para hacer esto en 1970 Edgar Frank Codd sugiere su famosa implementación del modelo relacional en su trabajo "Un modelo relacional de datos para grandes bancos de datos compartidos" para la compañia en la cual trabajaba IBM. Para su descontento, IBM no se apresuró a explotar sus sugerencias hasta que no empezaron a ser puestas en práctica por rivales comerciales. Por ejemplo, Larry Ellison diseñó la base de datos Oracle basándose en las ideas de Codd. • Codd definió las tres primeras Formas Normales que se aplican para la normalización de sistemas de bases de datos. Además, la Forma Normal de Boyce-Codd lleva el nombre en su honor.
Modelo ER • Modelo Entidad-Relación (E/R) – En 1.976 Peter Chen, sienta las bases del modelo ER, mediante el cual se pretende 'visualizar' los objetos que pertenecen a la Base de Datos como entidades (se corresponde al concepto de objeto de la Programación Orientada a Objetos) las cuales tienen unos atributos y se vinculan mediante relaciones. • Pese a sus similitudes y aunque el POO hunde sus raíces en los años sesenta (en los que aparecieron los primeros lenguajes de este tipo, llamados “Simula I” y “Simula 67”, desarrollados en el Centro Noruego de Computación, en Oslo), no es hasta la segunda mitad de los años 80 cuando la orientación de objetos se generaliza, convirtiéndose en el estándar predominante en los años 90, de la mano de lenguajes como C++ y Java – Uml no aparece hasta bien entrado los 90!
Dos mundos distintos • Hoy en día, la práctica totalidad de los lenguajes de programación que surgen son orientados a objetos y esta tecnología se ha convertido en el estándar actual de programación que, a su vez, está generando nuevos desarrollos muy prometedores para el futuro (como, por ejemplo, la programación orientada a aspectos).
Dos mundos distintos • La programación orientada a objetos intenta modelar estos objetos reales con estructuras de programa, llamadas “objetos de software” o, simplemente, “objetos”. Cada uno de estos objetos de software, está compuesto por una serie de características (llamadas “atributos”) y una serie de acciones (llamadas “métodos”).
• Si nuestros coches incluyen piezas tenemos una agregación de objetos
Dos mundos distintos • El modelo relacional es muy diferente del modelo orientado a objetos. Por una parte, el modelo relacional sólo se ocupa de la parte estática de la aplicación (de los “datos”) y no de la parte dinámica (“los procesos”). • Hay otra gran diferencia entre ambos, la forma en la que el modelo relacional trata los datos es muy diferente a cómo lo hace el modelo orientado a objetos. Mientras en este último, los datos son modelados en forma de objetos, en el modelo relacional son modelados como registros planos.
Realidad actual • una aplicación moderna está formada por un programa y una base de datos que se comunican entre sí. El programa suele estar diseñado según el modelo orientado a objetos y, por lo tanto, trabaja con datos en formato de objetos. Por el contrario, la base de datos está diseñada según el modelo relacional y, por lo tanto, trabaja con datos en formato de registros. Esto introduce una dificultad importante, porque los dos formatos de datos (objetos y registros) son incompatibles entre sí.
Solución uno • Migrar a una base de datos orientada o objetos. Solo tendría sentido si la propia programación surgiese de la base de datos
Solución dos • La solución es la misma que se daría en la vida real. Se debe encontrar un traductor que sepa traducir de cada idioma al otro. De esta forma, las dos personas se entenderán sin necesidad de que uno hable el idioma del otro. En el mundo de la programación este traductor no es más que un componente de software (concretamente, una capa de programación), al que se le dan los nombres de “capa de persistencia”, “capa de datos”, “correspondencia O/R” (“OR mapping”) o “motor de persistencia”. • Nosotros veremos Hibernate ORM.
Solución dos • Esta solución goza de las mejores ventajas de los dos modelos: – Por una parte, podemos programar con orientación a objetos, aprovechando las ventajas de flexibilidad, mantenimiento y reusabilidad. – Por otra parte, podemos usar una base de datos relacional, aprovechándonos de su madurez y su estandarización así como de las herramientas relacionales que hay para ella.
• Se calcula que un motor de persistencia puede reducir el código de una aplicación en un 40%, haciéndola menos costosa de desarrollar. Además, el código que se obtiene programando de esta manera es más limpio y sencillo y, por lo tanto, más fácil de mantener y más robusto.
Solapamiento Objeto-relacional
Mundo Real Modelos UML
Modelo OO Modelo Entidad - Relaci贸n Software
Modelo Relacional
Base de Datos (DBMS)
Ejemplo – Los profesores tienen un código interno, nombre, dirección, teléfono, categoría, departamento al que pertenece, asignaturas que imparten, en cada una de ellas que tienen un cierto número de créditos asignados. – Las asignatura tienen un código de asignatura, nombre, número de créditos de teoría y de práctica, departamento al cual está adscrita. – Un departamento tiene un código, nombre, director y teléfono.
Ejemplo
El diagrama de clases UML se centra en el comportamiento dinรกmico del sistema.
Ejemplo
No nos preocupamos de la estructura que tendrรกn los datos en memoria ni de cรณmo se realizarรก la persistencia.
Ejemplo
El modelo ER se centra en los datos y no en el comportamiento tomando del diagrama de clases solo los objetos que necesitan persistencia y sus relaciones estructurales.
Ejemplo
El modelo es una proyecci贸n instant谩nea del estado del sistema .
Arquitectura ANSI Sparc – Hay tres características importantes inherentes a los sistemas de bases de datos: la separación entre los programas de aplicación y los datos, el manejo de múltiples vistas por parte de los usuarios y el uso de un catálogo para almacenar el esquema de la base de datos. En 1975, el comité ANSI-SPARC (American National Standard Institute - Standards Planning and Requirements Committee) propuso una arquitectura de tres niveles para los sistemas de bases de datos, que resulta muy útil a la hora de conseguir estas tres características.
De OO a tablas Así pues, si usamos una BD Relacional debemos obtener un Modelo Lógico Relacional (MLR) ¿Cómo derivar un MLR a partir del Modelo de Análisis/Diseño expresado en Diagramas de Clases? Transformar Diagramas de Clases en Diagramas E-R y posteriormente derivar el MLR. – “Ver” los Diagramas de Clases como Diagramas E-R, considerando sólo las clases persistentes y sus atributos persistentes. Derivar el MLR a partir de esta “visualización”. Las pautas de derivación son similares a las usadas a partir de un Diagrama E-R –
¿Qué notación y herramienta utilizar? Profile para modelado de datos junto a herramienta CASE – Directamente modelar/implementar la BD a través de un editor de diagramas de tablas provisto por el gestor de BD –
Modelo ER: un solo modelo? En tan larga vida el ER ha ido modificandose y añadiendo nuevas características a lo largo del tiempo. Podemos encontrar ligeras variantes según que libro consultemos. [EN 2002] Elmasri, R.; Navathe, S.B. Fundamentos de Sistemas de Bases de Datos. 3ª ed. Addison-Wesley, (Cap. 3 y 4) [MPM 1999] De Miguel, A.; Piattini, M.; Marcos, E. Diseño de bases de datos relacionales. Ra-Ma. (Cap. 2) [CBS 1998] Connolly, T.; Begg C.; Strachan, A. Database Systems: A Practical Approach to Design, Implementation and Management. 2nd ed. Addison-Wesley. (Cap. 5) [SKS 1998] Silberschatz, A;Korth, H; Sudarshan, S. Fundamentos de Bases de Datos. 3ª edición. Madrid: McGraw-Hill. (Cap. 2) Las ultimas versiones buscan la convergencia con el modelo OO.
El ER define el nivel conceptual de la BBDD • Descripción concisa de los requisitos de información de los usuarios – Descripciones detalladas de • TIPOS DE DATOS • RELACIONES ENTRE DATOS • RESTRICCIONES que los DATOS deben cumplir
• Sin detalles de implementación – Más fácil de entender – Comunicación con el usuario no técnico
Modelo ER : conceptos básicos • • • •
Entidad ( entity ) equivaldria a los objetos Atributo ( attribute ) Dominio ( conjunto de valores ) Relaciones
Modelo ER : conceptos básicos • ENTIDAD Cosa u objeto del mundo real con existencia propia y distinguible del resto Objeto con existencia... – física o real (una persona, un libro, un empleado) – abstracta o conceptual (una asignatura, un viaje)
• “Persona, lugar, cosa, concepto o suceso, real o abstracto, de interés para la empresa” (ANSI, 1977)
Modelo ER : conceptos básicos • ATRIBUTO • Propiedad o característica de una entidad • Una entidad particular es descrita por los valores de sus atributos:
p1
titulo = El alquimista impaciente genero = Thriller nacionalidad = España añoestreno = 2002 ...
Modelo ER : conceptos básicos • TIPO DE ENTIDAD • Define un conjunto de entidades que poseen los mismos atributos PELICULA: titulo, genero, nacionalidad, añoestreno,numcopias ACTOR: dni, nss, nombre, fechanacim, direccion, telefono, altura, nacionalidad, edad Notación
CLIENTE
LOCAL VIDEOCLUB
ACTOR
Modelo ER : conceptos básicos • TIPOS DE ATRIBUTOS • • • •
Simples o Compuestos Almacenados o Derivados Monovalorados o Multivalorados Opcionales
Modelo ER : conceptos básicos • ATRIBUTO CLAVE • Una clave puede estar formada por varios atributos clave compuesta – Combinación de valores distinta para cada instancia (nombre, fechanacim) en el tipo de entidad EMPLEADO – Una clave compuesta debe ser mínima
• Un tipo de entidad puede tener más de una clave claves candidatas Claves o Identificadores Candidatos de EMPLEADO:
– dni – nss – (nombre, fechanacim)
Modelo ER : conceptos básicos • ATRIBUTO CLAVE • Atributo identificador principal (IP) – Clave Principal – Elegido (por el diseñador) de entre los identificadores candidatos (IC), para ser el medio principal de identificación de las instancias del tipo de entidad – dni en EMPLEADO
• Atributos identificadores alternativos (IA) – Claves Alternativas – El resto de IC’s – nss y (nombre, fechanacim) en EMPLEADO
Notaci贸n para atributos clave [EN2002] calle
[MPM1999]
provincia
ciudad
codpostal direcci贸n
fechanacim
telefono
(0,3) (0,1)
n-f
IP dni
nacionalidad edad
n-f
D nss
telefono altura
altura
EMPLEADO
nss
(0,3)
nombre EMPLEADO
(1,2) nombre
calle ciudad provincia codpostal fechanacim direcci贸n
(1,2) nacionalidad
dni
edad
En el MER es obligatorio que todo tipo de 30 entidad tenga un identificador
DOMINIO (values set) • Conjunto de valores • Cada atributo simple está asociado a un dominio, que especifica sus valores válidos Atributo
Dominio
nombre NOMBRES
Descripción Dominio cadenas de hasta 30 caracteres alfabéticos
telefono TELEFONOS cadenas de hasta 9 caracteres numéricos altura
MEDIDAS
números reales entre 0 y 2’5 (metros)
...
...
... nombre
No suele representarse, telefono EMPLEADO aunque una forma de altura hacerlo sería: [MPM1999]
NOMBRES TELEFONOS 31 MEDIDAS
RELACIÓN (relationship) • También “interrelación” • Asociación, vínculo o correspondencia entre instancias de entidades relacionadas de alguna manera en el “mundo real” –el director “Alejandro Amenábar” ha rodado la película “Mar adentro” –el empleado 87654321 trabaja en el local de videoclub “principal” –la película “El imperio contraataca” es una continuación de la película “La guerra de las galaxias” 32
TIPO DE RELACIÓN (relationship set)
• Estructura genérica o abstracción del conjunto de relaciones existentes entre dos o más tipos de entidad un DIRECTOR ha rodado PELICULA’s
• Notación DIRECTOR
HA_RODADO
PELICULA
33
Grado de un tipo de relación • Número de tipos de entidad que participan en el tipo de relación – Binaria: grado 2 (el más frecuente) – Ternaria: grado 3 – Reflexiva (o recursiva): grado 1 ACTOR
ACTUA_EN
CLIENTE
CONTINUACION DE
PELICULA
PELICULA
ALQUILA
PELICULA
LOCAL_VIDEOCLUB 34
Nombres de Rol (papel) • Todo tipo de entidad que participa en un tipo de relación juega un papel específico en la relación DIRECTOR
realizador
HA_RODADO
film
PELICULA
• Los nombres de rol se deben usar, sobre todo, en los tipos de relación reflexivos, para evitar ambigüedad original VERSION_DE
versión
PELICULA 35
Razón de Cardinalidad Notación EN2002 • Número máximo de instancias de tipo de relación en las que puede participar una misma instancia de tipo de entidad –la cardinalidad de HA_RODADO es “1 a N” – HA_RODADO es de tipo “1 a N”
DIRECTOR
• Notación
1 HA_RODADO
–etiqueta en la línea que N une entidad y relación PELICULA –Ojo: da la sensación de que se representa “al revés” si se piensa en el diagrama de clases UML 36
Razón de Cardinalidad Notación EN2002
• Razones de cardinalidad más comunes: – 1:1 (“uno a uno”) – 1:N (“uno a muchos”) – M:N (“muchos a muchos”) trabajador 1 TRABAJA_EN
1 lugar trabajo
EMPLEADO
encargado
1
SUPERVISA sucursal N LOCAL_VIDEOCLUB
ACTOR personaje
M
ACTUA_EN N
film
PELICULA 37
Razón de Cardinalidad Notación [MPM1999] • Número máximo de instancias de un tipo de entidad que pueden estar relacionadas con una instancia del otro tipo de entidad • Notación –Etiqueta (1:1, 1:N, M:N…) junto al tipo de relación, o –Flecha en sentido “... a N” trabajador
ACTOR
EMPLEADO encargado 1:1
TRABAJA_EN
1:N
SUPERVISA
M:N
ACTUA_EN
sucursal 38 lugar trabajo
LOCAL_VIDEOCLUB
PELICULA
Razón de Participación Notación [EN2002] • Especifica si toda la extensión de un tipo de entidad participa en un tipo de relación, o sólo parte de la extensión • Indica si hay dependencia en existencia de un tipo de entidad respecto de un tipo de relación (al menos debe existir una entidad para que tenga sentido la relación) • Clases de participación: – Participación total (dependencia en existencia) – Participación parcial 39
Razón de Participación (ii)
[EN2002]
• Notación – Líneas dobles o simples ACTOR
DIRECTOR 1
personaje
M
ACTUA_EN
HA_ RODADO N
film
PELICULA
N
PELICULA
40
Tipo de Entidad Débil Notación [EN2002] • No tiene atributos clave propios • Una instancia se identifica por su relación con una instancia de otro tipo de entidad –Tipo de relación identificador •Relaciona un tipo de entidad débil y un tipo de entidad regular (fuerte, dominante, padre, propietaria)
–Clave parcial (o discriminante) •Atributos de la entidad débil, que identifican de forma única cada instancia, siempre que esté relacionada con una instancia del tipo de entidad regular
–Clave = (clave_entidad_regular, clave_parcial)
• Notación COPIA
41
Tipo de entidad d茅bil (ii)[EN2002] nss
Tipo de Entidad Regular
PACIENTE 1 ACUDE
PELICULA
titulo
1 Tipo de Relaci贸n Identificador
TIENE
N
N numcopia
diahora
VISITA_MEDICA
COPIA
N Clave parcial o Discriminante
ASISTIDA POR 1 MEDICO especialidad
ncolegiado
Dependencia en existencia
nombre 42
Tipo de entidad débil (iii) [EN2002] • No toda participación total (o dependencia en existencia) implica un tipo de entidad débil EMPLEADO
dni
1 POSEE N numlicencia PERMISO CONDUCCION
tipo
PERMISO_CONDUCCIÓN no es débil: depende en existencia de EMPLEADO, pero tiene clave primaria propia 43
Tipo de entidad débil (v)
[MPM1999]
• Dependencia en existencia –Si desaparece una instancia del tipo de entidad regular deben desaparecer las instancias de la entidad débil que dependen de ella –Etiqueta “E” en el tipo de relación débil
• Dependencia en identificación –Además de la dependencia en existencia... –Una instancia del tipo de entidad débil no se puede identificar por sí misma –Su clave es (clave_entidad_regular, clave_parcial) –Etiqueta “ID” en el tipo de relación débil 44
Tipo de entidad débil (vi) dni
[MPM1999]
EMPLEADO
PELICULA
Tipo de Relación Débil
ID
E 1:N
POSEE
titulo
TIENE 1:N
numlicencia
tipo
numcopia PERMISO CONDUCCION
PERMISO_CONDUCCION es débil, pues depende en existencia de EMPLEADO, pero no depende en identificación
COPIA idcopia
COPIA es débil, pues depende en existencia de PELICULA, y también depende en identificación 45
Tipos de relaci贸n con grado superior a dos
[EN2002] CLIENTE
(0,n) (0,1) ALQUILA fecha
CINTA VIDEO
(0,m) LOCAL VIDEOCLUB
46
Situaci贸n t铆pica: coexistencia de relaciones ternarias y binarias.
[EN2002] idprov
(1,n) PROVEEDOR
(1,m) PROVEE
(1,n) TIENDA
(1,m)
(1,n)
(0,m) PRODUCTO
SUMINISTRA
(1,p)
PUEDE SUMINISTRAR
fecha cantidad
(0,n) VENDE
(1,m)
nombre 47
codpr
2.3. Extensiones del modelo E/G: Especialización Proceso de definición de un conjunto de subtipos de un tipo de entidad (» supertipo) Subtipos suelen estar definidos según característica distintiva de las entidades del supertipo Discriminante de la especialización EMPLEADO
[MPM1999]
actividad
SECRETARIO
GERENTE
COMERCIAL
48
2.3. Extensiones del modelo E/G: Especialización (ii) Varias especializaciones de un tipo de entidad, con base en diferentes discriminantes
[MPM1999]
VEHÍCULO motorS/N
VEHÍCULO_A_MOTOR
tipo
VEHÍCULO_SIN_MOTOR
CAMIÓN TURISMO
PELÍCULA género
DRAMA TERROR
COMEDIA
MOTOCICLETA
[EN2002]
color
BLANCO_Y_NEGRO 49
COLOR
Ejemplo. Empresa TĂpica
50
Ejemplo. Empresa TĂpica (ii)
51
Ejemplo. Empresa TĂpica (iii)
52
Ejemplo. Empresa TĂpica (iv)
53
Ejemplo. Empresa TĂpica (v)
54
Ejemplo. Empresa TĂpica (vi)
55
Ejercicio
56
Ejercicio
57