Definitivo er

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