02 - modelos de datos er-uml-relacional

Curso 2010-2011 Marta Zorrilla - UC 1

Modelos de datos

Marta E. Zorrilla PantaleónUniversidad de Cantabria


Modelo de datos. Definición

� Conjunto de herramientas conceptuales para describir la representación de la información en términos de datos. Los modelos de datos comprenden aspectos relacionados con: estructuras y tipos de datos, operaciones y restricciones. Dittrich (1994).

� Conjunto de conceptos, reglas y convenciones que permiten describir y manipular los datos de la parcela de un cierto mundo real que deseamos almacenar en la base de datos. De Miguel et al. (1999).

� Colección de herramientas conceptuales que se emplean para especificar datos, las relaciones entre ellos, su semántica asociada y las restricciones de integridad.


Fases del diseño

� Fase inicial: análisis de requisitos. Descripción de la información a gestionar y sus procesos. Entrevistas con usuarios y expertos.

� Análisis de requisitos. Especificación funcional

� Diseño conceptual: traducción del análisis de requisitos al esquema conceptual. Representación generalmente gráfica de las entidades y sus relaciones.

� Modelo ER, modelo UML, ORM� DFD, diagrama de casos, diagramas de colaboración, de

secuencia, etc.

� Implantación en el gestor:� Diseño lógico: traducción del modelo conceptual al LDD

del gestor correspondiente. Modelo relacional, OO, OR� Diseño físico: determina la organización de archivos y las

estructuras de almacenamiento interno.


Modelo, Esquema y Ejemplar

Mundo

real Modelo de

datos

Esquema

de datos

Herramientas

CASE

ER, ORMUML

RelacionalObjeto relacionalOrientado a objetosJerárquico / red

Ejemplar del esquema: instancia del esquema, esto es, datos que en un momento determinado están en el esquema


Modelos conceptuales

� Características:� Independientes del SGBD� Mayor nivel de abstracción� Mayor capacidad semántica� Más enfocados al diseño de alto nivel� Interfaz usuario/informático


Ejemplo ER

addr

STARNamephones

STUDIO

owns

Nameaddress

starsMOVIE

yearTitle

filmTypelength

0..N

1..N 1..N

1..1

streetcity


Ejemplo UML

Movie

title

year

length

filmType

{color, blackAndWhite}

Star

name

Addr {street, city}

Phones(set)

Studio

name

address

1..N 1..N

1..10..N

float lengthInHours()

void starNames (out

Set<String>);

void otherMovies ( in

Star, out Set<Movie>)

void enrolled_in (in

Star s, Movie m)

void drop_enrolled_in

(in Star s, Movie m)


Ejemplo ORM


Herramientas CASE (Computer

Aided/Assisted Software/System Engineering)

� Conjunto de programas que asisten a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software.

� Ayudan al diseño� verificación de errores

� Reducen el tiempo de desarrollo� generación de código y reutilización de objetos, generadores de casos de pruebas

� Mejoran la calidad � Facilitan el mantenimiento de los programas� Generan y estandarizan la documentación� Aumentan la portabilidad de las aplicaciones


Clasificación de herramientas CASE

� Se pueden clasificar atendiendo a:

� Las fases del ciclo de vida del desarrollo de sistemas que cubren

� Su funcionalidad


Según ciclo de software

� Herramientas integradas, I-CASE (IntegratedCASE): abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Son llamadas también CASE workbench. Muy caras.

� Herramientas de alto nivel, U-CASE (Upper CASE o front-end), orientadas a la automatización y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: análisis y diseño.

� Herramientas de bajo nivel, L-CASE (Lower CASE -o back-end), dirigidas a las últimas fases del desarrollo: diseño detallado y generación de código.

� Juegos de herramientas o Tools-Case, son el tipo más simple de herramientas CASE. Automatizan una fase dentro del ciclo de vida.


Según su funcionalidad

� Herramientas de análisis y diseño� Permiten al desarrollador crear un modelo del sistema

que se va a construir y también la evaluación de la validez y consistencia de este modelo.

� Herramientas de programación (compiladores, editores y depuradores )

� Herramientas de gestión de prototipos � Herramientas de mantenimiento (ingeniería inversa,

reingeniería)� Herramientas de gestión de proyectos (planificación,

seguimiento, medición de costes). � Herramientas de soporte (gestión de la configuración,

control de cambios, documentación, etc.). � Herramientas de integración y prueba

� Sirven de ayuda a la adquisición, medición, simulación y prueba de los sistemas lógicos desarrollados.


Componentes

� Repositorio o diccionario de datos� Almacén de los elementos definidos

� Módulo diagramático� Editores que recogen las distintas técnicas

� Generador de código. Ingeniería inversa.� Generador de documentación� Interfaz de usuario

INTERFAZ DE USUARIOINFORMES

CÓDIGO

Repositorio

Modelos


Productos más utilizados

� ERWin� PowerDesigner (Sybase)� EasyCASE� Oracle designer (Discoverer)� Visio (Microsoft)


Elección de la herramienta de diseño de bases de datos

� Multiplataforma � Trabajo en grupo� Aspectos de seguridad� Software Open Source / licencia (precio)� Esquema de BD para diferentes gestores.

Comprobación de restricciones � Sincronización con el gestor� Ingeniería inversa� Generación de documentación� Interfaz gráfica cómoda e intuitiva� Capacidad de representación respecto a la

notación teórica


Deficiencias en herramientas CASE

� Generalmente no recogen toda la riqueza semántica del modelo de datos.

� Falta de un modelo de restricciones que genere las reglas de negocio en automático.

� No ayuda a especificar el modelo físico adecuado, lo indica el diseñador, pero no le da pautas o medidas de rendimiento.

� No ofrecen la posibilidad de diseñar en entornos distribuidos, OO, activas, … no hay modelo que permita representarlo.

� Los atributos derivados pueden estar en el conceptual por razones semánticas y en el físico por razones de eficiencia, el problema es que la regla por la que se genera no se puede modelizar.


Modelo ER

Marta ZorrillaUniversidad de Cantabria


Tabla de contenidos

� Evolución histórica� Modelo básico versus

modelo extendido� Elementos estáticos

� Entidades� Relaciones� Dominios y valores� Atributos

� Restricciones� Identificadores� Cardinalidades de atributos� Cardinalidades de relaciones

� Relaciones n-arias� Extensiones del modelo

� Generalización y especialización� Restricciones entre relaciones� Agregación

� Notación E/R vs. UML� Ejemplos


Evolución histórica

� Propuesto por Chen en dos artículos ya históricos, en 1976 y 1977.

� Según Chen, “El Modelo E/R puede ser usado como una base para una vista unificada de los datos”, adoptando “el enfoque más natural del mundo real que consiste en entidades y relaciones”.

� Posteriormente otros autores lo han ampliado con importantes aportaciones, formándose en realidad una familia de Modelos de Datos.

� Se abordará el modelo E/R básico y el modelo E/R extendido.

� El Modelo E/R ha tenido una gran difusión en la comunidad informática dedicada a las BD, prueba de ello es que ha sido el modelo más extendido en las herramientas CASE de ayuda al diseño de BD.

� DATE critica al modelo ER diciendo que no es más que una fina capa por encima del modelo relacional


Elementos estáticos

� Entidad (entity)� Objeto que existe y se distingue de los demás. � Pueden ser concretos

� P. ej.: un libro, una persona,..� O abstractas

� P.ej.: préstamo, pedido,…

� Atributo (attribute)� Propiedades que caracterizan a las entidades. � Clave primaria: atributos que identifican a la entidad

� P.ej.: ISBN (PK), título, idioma,… para entidad libro

� Dominio (domain)� Conjunto de valores permitidos para un atributo

� P. ej: indicando el tipo de datos (por intensión)� P. ej: sexo-> M o F (por extensión)


Entidades

� Existen dos categorías de tipos de entidades:� Regulares o fuertes, que son aquellas cuyos

ejemplares tienen existencia por sí mismos� Caso préstamos de la biblioteca: LIBRO y AUTOR

� Débiles, en las cuales la existencia de un ejemplar depende de que exista un cierto ejemplar de otro tipo de entidad

� Caso del EJEMPLAR que depende de LIBRO

LIBRO AUTOR

EJEMPLAR


Elementos estáticos (y 2)

� Relación (relationship)� Conexión semántica entre dos o más entidades

� Cardinalidad: nº máximo de unidades de un conjunto que se conecta o relaciona con una entidad de otro y viceversa

DPTO

EMPLEADO

trabaja 1:m

LIBRO

AUTOR

escribe n:m

COMPAÑIA

PRESIDENTE

preside 1:1

(0:m)

(1:1) (1:m)

(1:n)

(1:1)

(0:1)


Relaciones reflexivas

PERSONA

maternidad

hijomadre

� En estos casos se requiere especificar el rol, papel que desempeña en la relación

MECANISMO

constituye

Forma parte de

Compuesto por

1:N

N:M


Relaciones

LIBRO

EJEMPLARES

tieneID

EMPLEADO

HIJOS

tieneE

Dependencia de

identificación

Dependencia de existencia

numcopia

NRP

estado DNI

0:N

1:1

0:N

1:1

ISBN


Atributos y claves

PERSONA IDPersonaNombre

EdadDNI

Identificador

Clave candidata

ASIGNATURA

ALUMNO

matriculaCurso acad.

HOMBRE

MUJER

matrimonioFecha

Atributo derivadoFecha nacimiento

Admite nulosProfesión

Teléfonos Multivaluado

Dirección

Calle CP Localidad

Atributo compuesto

1:1 n:m


Gestión de préstamos (ejemplo)

� Requisitos:� La biblioteca está interesada en automatizar la

gestión de préstamos� El modo de funcionar es sencillo, básicamente

requiere registrar el socio que se lleva el libro, y de qué ejemplar se trata, así como las fechas de entrega, devolución prevista y de devolución.

� La biblioteca está organizada en diversas sedes y el socio puede coger libros de cualquiera de ellas.

� Del socio se tienen los datos personales básicos.� Y de los libros, todos los campos descriptivos que los

caracterizan (título, idioma, autores, editorial, fecha,…).

� Además de cada ejemplar se querrá conocer el estado en el que se encuentra (prestable, en reparación, fuera de circulación)


Préstamos de la biblioteca

nombreSOCIOCodSocio

dni

Codlibtitulo

FechaAlta

(0,n)

(0,n)

EJEMPLAR

numEjemplar

FechaPrevistaDevFechaDev

nombreSEDE Biblio.CodSed

localidad(1:1)

(0:n)

enID

(0:n)(1:1)

Estado

prestar EDITORIAL

publicadoIDEdit

escrito

(0:n)

(1:n)

(0:n)

(1:1)

ISBN

IDAutor

fecha

IDIOMA

(1:1)

IDIdioma

LIBRO

en

(0:n)

nombre

nombreApellido_1

AUTORES

nombre

ubicado


Préstamos de la biblioteca

nombreSOCIOCodSocio

dni

Codlibtitulo

NumPrestFechaAlta

(1:1)

(1:1)

EJEMPLAR

numEjemplar

FechaPrevistaDevFechaDev

nombreSEDE Biblio.CodSed

localidad(1:1)

(0:n)

enID

(0:n)(1:1)

Estado

a

EDITORIAL

publicadoIDEdit

escrito

(0:n)

(1:n)

(0:n)

(1:1)

ISBN

IDAutor

fecha

IDIOMA

(1:1)

IDIdioma

LIBRO

en

(0:n)

nombre

nombreApellido_1

AUTORES

nombre

ubicadoPRESTAMO

de un

(0:n)

(0:n)


Gestión docente (ejemplo)

� Requisitos:� Cada profesor pertenece a un sólo departamento y

debe pertenecer a uno.� El profesor puede impartir varios grupos de la misma

o distinta asignatura, y un grupo debe ser enseñado por un profesor.

� Los alumnos se matriculan de varias asignaturas (al menos una) cada curso académico pero han de hacerlo en un grupo. A su vez un grupo tendrá varios alumnos matriculados. Cada grupo tendrá asignado un aula para cada día y hora de la semana.

� La matrícula dará opción a dos convocatorias de examen con su respectiva calificación.

� Todo departamento debe tener un director, que es profesor.

� Los atributos de cada entidad son los que cabría esperar.


Gestión docente

nombrePROFESORNroPersonal

Apellido_1

DPTO

pertenece

CodDptonombre

dirige

ALUMNOS CodAlunombre

ASIGNATURA

CodGrupo

GRUPO Max-alum

imparte

dni

constaCalificación

Convocatoria (1..2)

MATRICULA

realiza

tieneID

(1:1)

(1:n)

(0:n)

(0:n)(1:1)

(1:1)

(0:n)

(0:1)

(1:1)

(0:n)

(1:1)

CursoAcad

NombreCréditosCarácterCurso

CodMatr

CodAsigocupa

día

horaAULA

(0:n) (1:n)Nro

(1:1- dia - hora)


Relaciones n-arias

PROVEEDOR

PIEZAcompraTRABAJO(1:n)(1:n)

(0:1)

• Una pieza Y en un trabajo Z – una pareja (pieza, trabajo) – lasuministran 0 o 1 proveedores.• Un proveedor X en un trabajo Z – una pareja (proveedor,trabajo) – suministra 1, 2, .., n piezas.• Un proveedor X suministra una pieza Y – una pareja (proveedor,pieza) – en 1, 2, .., n proyectos


Relaciones n-arias (sin redundancia)

PROVEEDOR

PIEZAcompraTRABAJO

Puedesuministrar

(0:n)

(1:n)

(1:n)(1:n)

(1:n)

Puede intervenir

(0:n)

(0:n)

necesita (1:n)(0:n)

cantidadPrecio ud.

Cantidad total

precio


Generalización y especialización

PERSONA

CLIENTE EMPLEADO

nombreNroPersona

Apellido_1

Calificación crediticia

salario

puesto

La Generalización se considera como un caso especial de relación entre uno o varios tipos de entidad (subtipos) y un tipo más general (supertipo), cuyas características son comunes a todos los subtipos.

El mecanismo de abstracción contrario se llama especialización.



La división en subtipos (especialización) puede venir determinada por una condición predefinida (por ejemplo, en función de los valores de un atributo llamado discriminante).

La Generalización/Especialización tiene dos restricciones semánticas asociadas:

• Totalidad (todo ejemplar del supertipo tiene que pertenecer a algún subtipo). El caso contrario se llama Parcialidad.

• Solapamiento (un mismo ejemplar del supertipo puede pertenecer a más de un subtipo). El caso contrario se llama Exclusividad.



PERSONA

HOMBRE MUJER

Total exclusiva

PERSONA

EMPLEADO ESTUDIANTE

Total con solapamiento

PERSONA

DIRECTOR ADMINISTRATIVO

Parcial exclusiva

EMPLEADO

DOCENTE INVESTIGADOR

Parcial con solapamiento

(t,e)

(p,e)

(t,s)

(p,s)


Restricción de exclusividad

La persona o percibe una beca o está contratado

PERSONA

BECApercibe

CONTRATOEstá en


Restricción de exclusión

La persona imparte o recibe el curso, no puede estar en ambas relaciones a la vez

PERSONA

imparte

CURSO

recibe


Restricción de inclusividad

Las personas que dominan idiomas son un subconjunto de las que realizan viajes internacionales. Si una persona participa en domina, tiene necesariamente que participar en hacen viajes

PERSONA

dominan IDIOMA

hacen VIAJES INTERN.


Restricción de inclusión

Los cirujanos son un subconjunto de los médicos del hospital

MEDICO

atiende

HOSPITAL

opera


Agregación

� Es un tipo especial de relación en la cual las cardinalidades mínima y máxima del tipo de entidad agregada siempre son (1,1)

� Existen dos clases de agregaciones:� Compuesto/Componente:

� permite representar que un “todo” se obtiene por la unión de diversas partes que pueden ser tipos de entidades distintas y que juegan diferentes roles en la agregación.

� Miembro/Colección:� permite representar un “todo” como una colección de

miembros, todos de un mismo tipo de entidad y todos jugando el mismo rol.

� Esta agregación puede incluir una restricción de orden de los miembros dentro de la colección (indicando el atributo de ordenación).


Ejemplos agregación

COCHE

CHASIS MOTOR RUEDA

FLOTA BARCO

(1:1)(1:1) (4:4)

(1:n)

Ordenado por num_barco

AgregaciónCompuesto/Componente

Agregación Miembro/Coleccióncon cardinalidades y restricción de orden


Agregación – otros usos

Como herramienta para expresar relaciones entre relaciones o entre relaciones y conjuntos de entidades

nombreENFERMO Codpru

tipo

PRUEBArealizado

atendido

MEDICO

nombredni

especialidadnrp

fecha

hora1:n


Evitar las redundancias

� Un elemento de un esquema es redundante si puede ser eliminado sin pérdida de semántica.

� Existen dos formas principales de redundancia:� En los atributos (derivados o calculados):

� Aunque son redundantes, no dan lugar a inconsistencias siempre que en el esquema se indique su condición de derivados y la fórmula mediante la que han de ser calculados.

� En las relaciones (también llamadas interrelaciones derivadas):

� Una relación es redundante si su eliminación no implica pérdida de semántica porque existe la posibilidad de realizar la misma asociación de ejemplares por medio de otras relaciones.

� Para ello es condición necesaria pero no suficiente que forme parte de un ciclo => Hay que estudiar detenidamente los ciclos en el diagrama E/R.


Evitar las redundancias (y 2)


¿Hay problema de redundancia?

PROFESOR

CURSO

Participa

TEMA Consta

investiga

Imparte

1:n 1:n

1:n 1:n1:n

1:n

1:n

1:n

1:n


Gestión de compras (ejemplo)

� Requisitos:� Una empresa está interesada en automatizar su

proceso de compras� El modo de funcionar es sencillo, básicamente

requiere registrar la hoja del pedido que realiza a un determinado proveedor en una determinada fecha

� En la hoja del pedido queda constancia del número de unidades que compra de cada artículo y el precio de compra, y en caso de que el proveedor o bien por volumen o por promoción, le realiza un descuento, también lo anota

� Los productos que compran tienen distinto IVA� Generalmente el paga a sus proveedores al mes de

recibir la mercancía y por transferencia, aunque lo puede hacer a plazos

� Los atributos de cada entidad son los que cabría esperar


Gestión de compras

nombrePROVEEDORCodProv

tfno

ARTICULO Codartnombre

PEDIDO NumPedFechaPed

suministra

precioUd

unidades

numLinea

precioCompra

consta

(1:1)

(1:n)

(0:n)

iva

ivadescuento

PAGONumPagoFechaPago

Con/del(0:n) (1:1)

(0:n)

Tipo pagoFechaEntrega

Conceptoc/ccantidad

c/c

EstadoImporte pedido

Dirección

Calle CP Localidad


Generalización del tipo de pago

PAGO

(p,e)

tarjeta cheque

Fecha caducidadnúmero

(1:1)

NumPagoFechaPago

Tipo pago

Concepto

c/c

cantidad

Tipo tarjeta{crédito,débito}banconúmeroCheque

transferencia

DISCRIMINANTE


Modelo relacional



Tabla de contenidos

� Elementos básicos� Dominios y atributos� Definición de relación� Clases de relaciones

� Restricciones de integridad� Inherentes� Definidas por el usuario

� Valores nulos� Esquemas relacionales� SGBD relacionales


Introducción

� En 1970, Codd publicó en ACM el trabajo “Un modelo de datos relacional para grandes bancos de datos compartidos”donde propuso un nuevo Modelo de Datos.

� Se caracteriza por:� ser sencillo y uniforme (colección de tablas y

lenguajes declarativos)� sólida fundamentación teórica: el modelo está

definido con rigor matemático� se independiza del almacenamiento físico y de

las aplicaciones.


Elementos básicos

� RELACIÓN� Es la estructura básica del modelo relacional. Se

representa mediante una tabla.

� DOMINIO� Es el conjunto válido de valores que toma un

atributo. Existen con independencia de cualquier otro elemento.

� ATRIBUTO� Representa las propiedades de la relación. Se

representa mediante una columna.

� TUPLA� Es una ocurrencia de la relación. Se representa

mediante una fila.


Ejemplo de relación

Carmen

Ana

Pedro

Marie

nombre

Calvo Sotelo

Castellana

Torres Quevedo

Eliseos

calle

Santander

Madrid

Logroño

París

ciudad

cliente

atributos

tuplas

El Universo de Discurso de una BD relacional está compuesto por un conjunto de dominios {Di} y de relaciones {Ri} definidas sobre los dominios.


Dominios

Un dominio es un conjunto nominado, finito y homogéneo de valores atómicos

� Un dominio =>� se identifica por un nombre,� tiene un número finito de valores,� todos los valores son del mismo tipo, y� los valores son atómicos respecto del MR

� Cada dominio puede definirse de dos maneras:� Extensión (dando sus posibles valores):

� días de la semana = {lunes, martes, miércoles, … sábado, domingo}

� Intensión (mediante un tipo de datos):� peso = decimal

� A veces se asocia al dominio su unidad de medida (kilos, metros,etc.) y/o ciertas restricciones (como un rango de valores).


Atributos

Un atributo (A) es la interpretación de un determinado dominio en una relación, es decir el “papel” que juega en la misma.

� Notación:

D = Dom (A) => D es el dominio de A

� Un atributo y un dominio pueden llamarse igual, pero …� Un atributo está siempre asociado a una relación, mientras que

un dominio tiene existencia propia con independencia de las relaciones.

� Un atributo representa una propiedad de una relación.� Un atributo toma valores de un dominio.� Varios atributos distintos (de la misma o de diferentes relaciones)

pueden tomar sus valores del mismo dominio.


Relación

Una relación (matemáticamente) es un subconjunto del producto cartesiano de la lista de dominios {Di}

� Esta definición no tiene en cuenta a los atributos, por eso en Bases de Datos se utiliza otra definición “un esquema de relación se compone de un nombre de relación R, un conjunto de n atributos {Ai} y de un conjunto de n dominios (no necesariamente distintos) {Di} donde cada atributo serádefinido sobre un dominio”.

� Una relación consta de los siguientes elementos:� Nombre de la relación� Cabecera: conjunto de n pares atributo-dominio� Cuerpo: Conjunto de m tuplas� Esquema: constituido por el nombre de la relación y la

cabecera� Estado: constituido por el esquema y cuerpo.


Relación (y 2)

� Hay que diferenciar:� Esquema : conjunto de atributos {Ai} junto con sus dominios� Instancia : conjunto de tuplas r={t1,…,tn} tal que ti=(x1,..,xn) con xj Є Dj

Esquema:Persona [nombre: Nombres, calle: Calles, ciudad: Ciudades]

Instancia:(Carmen, Calvo Sotelo, Santander),(Ana, Castellana, Madrid), (Pedro, Torres Quevedo, Logroño), (Marie, Eliseos, Paris)

Se denomina cardinalidad o aridad de una relación al número de tuplas que hay en un esquema. Y grado al nº de atributos.


Ejemplo


Base de datos relacional

Una base de datos relacional es un conjunto finito de relaciones {Ri}

Con nombre

Persistentes

Sin nombre

Temporales

Base (definidas por el usuario y del sistema)Vistas Vistas materializables

Temporales Resultado de una consulta (intermedio o final)

Definidas por el usuarioVistas temporalesVistas materializables temp.

Clases de relaciones


Terminología

!CUIDADO!, una relación no es una tabla. Ni una tabla es un fichero. Existen diferencias entre los conceptos.


Restricciones inherentes

� Las restricciones inherentes vienen impuestas por el propio Modelo de Datos.

� En el caso del MR, una relación tiene unas propiedades intrínsecas que no tiene una tabla, y que se derivan de la misma definición matemática de relación, ya que, al ser un conjunto:� No puede haber dos tuplas iguales => obligatoriedad de la PK� El orden de las tuplas no es significativo.� El orden de los atributos no es significativo.� Cada atributo sólo puede tomar un único valor del dominio

subyacente � Se dice que la relación está normalizada (en 1FN).

� Otra restricción es la regla de integridad de entidad:

“Ningún atributo que forme parte de la clave primaria de una relación puede tomar un valor nulo”


Tabla vs. relación

� Una relación es un concepto abstracto de origen matemático.

� Una tabla es una forma de representar (implementar) una relación (una estructura de datos).

� Una tabla no tiene las restricciones inherentes de una relación como conjunto:� Puede haber dos filas iguales.� Las filas están ordenadas en el orden de grabación física

por defecto o según el valor de la clave primaria.� Los atributos tienen un orden según se han definido en la

tabla.� En cada celda de una tabla puede haber uno o varios

valores. Si bien en el segundo caso se puede obtener una tabla equivalente que cumple la regla de normalización.


Clave (key)

Clave Candidata (Candidate Key): conjunto de atributos que identifican unívoca y mínimamente cada tupla de la relación.

� De la definición de relación se deriva que siempre existe, al menos, una clave candidata.

� La propiedad de minimalidad implica que no se incluye ningún atributo innecesario: CK cumple la propiedad de minimalidad si no existe un atributo X tal que {CK-X} sea clave candidata.

� Una relación puede tener más de una clave candidata. En este caso se debe distinguir entre:� Clave Primaria (Primary Key): NRP para empleado

� Es la clave candidata que el usuario escoge para identificar las tuplasde la relación.

� Cuando sólo existe una clave candidata, ésta es la clave primaria.

� Claves Alternativas (Alternative Key): DNI, PASAPORTE para empleado

� Las claves candidatas que no han sido escogidas como clave primaria.


Clave (key) (y 2)

Clave Ajena (Foreign Key): Se denomina clave ajena de una relación R2 a un conjunto no vacío de atributos cuyos valores han de coincidir con los valores de una clave candidata de una relación R1.

� R1 y R2 pueden ser la misma relación.� La clave ajena y la correspondiente clave candidata han de estar

definidas sobre el mismo dominio.

EMPLEADO (NRP, dni, nombre, apellido, fecha_nac, trabaja_en,..)

DEPARTAMENTO (CodDpto, nombre, responsable,..)

PK

PK

CK FK

FK


Restricciones semánticas

� Son definidas por el usuario.� Son facilidades que el modelo ofrece a los diseñadores

para que puedan reflejar en el esquema, lo más fielmente posible, la semántica del mundo real.

� Los tipos de restricciones semánticas permitidos en el MR (incorporados a SQL 92) son:

� Clave Primaria (PRIMARY KEY)� Unicidad (UNIQUE)� Obligatoriedad (NOT NULL)� Integridad Referencial (FOREIGN KEY)� Verificación (CHECK)� Aserción (CREATE ASSERTION)� Disparador (TRIGGER), incluido en SQL:1999


Restricciones semánticas (y 2)

� Clave Primaria (PRIMARY KEY):� Permite declarar un atributo o un conjunto de atributos como

clave primaria de una relación => sus valores no se podrán repetir ni se admitirán los nulos.

� Ni el SQL92 ni los SGBD’s relacionales obligan a la declaración de una clave primaria para cada tabla (el modelo teórico sí la impone), aunque permiten la definición de la misma.

� Se debe distinguir entre la restricción inherente de obligatoriedad de la clave primaria y la restricción semántica que le permite al usuario indicar qué atributos forman parte de la clave primaria.

� Unicidad (UNIQUE):� Los valores de un conjunto de atributos (uno o más) no

pueden repetirse en una relación. Permite la definición de claves alternativas.

� Obligatoriedad (NOT NULL):� El conjunto de atributos no admite valores nulos.


Restricciones semánticas: Foreign key

� Integridad Referencial (FOREING KEY):� Si una relación R2 (relación que referencia) tiene un

descriptor (subconjunto de atributos) CA que referencia a una clave candidata CC de la relación R1 (relación referenciada), todo valor de dicho descriptor CA debe coincidir con un valor de CC o ser nulo.

� La condición puede expresarse como R2.CA = R1.CC� El descriptor CA es, por tanto, una clave ajena de la relación

R2.� Las relaciones R1 y R2 no son necesariamente distintas.� La clave ajena puede ser también parte (o la totalidad) de la

clave primaria de R2.� CA puede admitir nulos o tener restricción de obligatoriedad

(NOT NULL).

� Todo atributo de una clave primaria compuesta de una relación R2 que no está definido sobre un dominio compuesto, debe ser clave ajena de R2 referenciando a una relación R1, cuya clave primaria sea simple.


Ejemplo

ENTIDAD NOMBRE

POBLACION DIRECCION

0893 Santander

0059 Popular

3428 Bilbao Vizcaya

5632 Banesto

BANCOS

OFICINAS

0893 001 Madrid Castellana, 73

3428 022 Las Palmas Triana, 21

0893 022 Gáldar R. Moreno, 3

5632 213 Oviedo Uría, 43

0893 300 Barcelona Diagonal, 435

ENTIDAD CODIGO_OFICINA


Restricciones semánticas: Foreign key (y 2)

� Integridad Referencial (FOREING KEY):� Además de definir las claves ajenas, hay que

determinar las consecuencias que se producen al borrar o actualizar la relación referenciada. Según el estándar SQL92:

� NO ACTION: rechazar la operación de borrado o modificación.

� CASCADE: propagar la modificación (o borrado) de las tuplas de la tabla que referencia.

� SET NULL: poner valor nulo en la clave ajena de la tabla que referencia.

� SET DEFAULT: poner un valor por defecto en la clave ajena de la tabla que referencia.

� Los modos borrar y modificar son independientes, es decir, cada uno tomará una de las cuatro opciones por separado.


Ejemplo

EMPLEADO (NRP, dni, nombre, apellido, fecha_nac, trabaja_en,..)

DEPARTAMENTO (CodDpto, nombre, responsable,..)

PROYECTO (CodProy, título, fecha_ini, fecha_fin)

TAREAS (CodProy, CodTarea, título, responsable, fecha_ini, fecha_fin)

PARTICIPA (CodProy, CodTarea, NRP, porcentaje)

Modificación: CascadeBorrado: SET NULL

Modificación: CascadeBorrado: NO ACTION


Restricciones semánticas: Verificación

� CHECK: Comprueba, en toda operación de actualización, si el predicado es cierto o falso y, en este último caso, rechaza la operación.

� La restricción de verificación se define sobre un único elemento

CHECK (porcentaje > 0 and porcentaje <100)

� O a nivel de relación

CHECK (fecha_fin >= fecha_ini)

� Siempre dentro de un CREATE TABLE. Puede o no tener nombre.


Restricciones semánticas: Asertos

� ASSERTION: Actúa de forma idéntica a la anterior, pero se diferencia de ella en que puede afectar a varios elementos (por ejemplo, a dos relaciones distintas).

� Su definición no va unida a la de un determinado elemento del esquema y siempre ha de tener un nombre.

CREATE ASSERTION ctrl_proyecto CHECK(not exists (SELECT CE.trabaja_en as dpto_currito, CT.codproy, CT.codtarea

FROM empleado CE, participa CT where CE.nrp = CT.nrp and

CE.trabaja_en not in(

SELECT RE.trabaja_en from empleado RE, tarea PT

where RE.nrp = PT.responsable and PT.codproy=CT.codproy and

PT.codtarea=CT.codtarea))

Empleados que participan en una tarea sean del mismo Dpto que su responsable


Restricciones semánticas: Disparadores

� Restricción en la que el usuario pueda especificar la respuesta (acción) ante una determinada condición.

CREATE TRIGGER ctrl_participa ON PARTICIPA FOR INSERT, UPDATE ASDECLARE @total float

SELECT @total= count(*) FROM insertedWHERE 100 < (select sum(porcentaje) from participa

where participa.nrp=inserted.nrp )

IF (@total>0)BEGINRAISERROR (' Sobrecarga…', 16, 1)ROLLBACK TRANSACTIONRETURN

END

evitar la sobrecarga de los trabajadores


Valores nulos

Valor nulo: utilizado para representar información desconocida, inaplicable, inexistente, no válida, no proporcionada, indefinida, etc.

� Necesidad de los valores nulos en BD:� Crear tuplas (filas) con ciertos atributos cuyo valor es

desconocido en ese momento, p.e., la fecha de devolución de un préstamo.

� Añadir un nuevo atributo a una relación existente; atributo que, en el momento de añadirse, no tendría ningún valor para las tuplas de la relación.

� Atributos inaplicables a ciertas tuplas, por ejemplo, la editorial para un artículo (ya que un artículo no tiene editorial) o la profesión de un menor.

� Requiere tener cuidado en las consultas (is null)


Valores nulos (y 2)

� El tratamiento de valores nulos exige redefinir las operaciones de comparación, aritméticas, de agregación, etc. de forma específica para el caso en que un operando tome valor nulo.

� Obliga a introducir nuevos operadores especiales: IS NULL , MAYBE

� En las operaciones de comparación se hace necesario definir una lógica trivaluada incorporando el valor quizás (Q).

� Se considera nulo el resultado de una suma, resta, multiplicación o división si alguno de los operandos toma valor nulo.

� En las agregaciones, no se consideran esas tuplas, a excepción del count(*)


Esquemas relacionales

� Ahora podemos dar una definición más completa de esquema de una relación:

R < A:D, S >siendo

� R el nombre de la relación,� A la lista de atributos,� D los dominios sobre los que están definidos los atributos, y� S las restricciones de integridad intraelementos (afectan a

atributos y/o tuplas de una única relación).

� El esquema de una base de datos relacional será:

Ε < {Ri }, {Ii } >siendo

� Ε el nombre del esquema relacional,� {Ri} el conjunto de esquemas de relación, y� {Ii} el conjunto de restricciones de integridad

interelementos (afectan a más de una relación y/o dominio).


Esquemas relacionales (y 2)

� En términos de implementación en SQL, un esquema E constará de:

E <R, D, T, V>

siendo� R el conjunto de esquemas de relación (CREATE TABLE),� D el conjunto de definiciones de dominios (CREATE DOMAIN),� T el conjunto de restricciones de integridad entre relaciones y

sobre dominios (CREATE ASSERTION, CREATE TRIGGER, ...), y� V el conjunto de vistas (CREATE VIEW).


Gestores relacionales (MR vs ANSI)


Las 12 reglas de Codd (ComputerWorld 1985)

� Cuando el MR triunfó comercialmente, muchos fabricantes que tenían productos “antiguos” no relacionales optaron por retocarlos o “camuflarlos” añadiéndoles la etiqueta relacional.

� Esto supuso una confusión que Codd intentó arreglar publicando sus 12+1 reglas, que indican las características que debe tener un SGBD para ser auténticamente relacional.

� Regla 0:� Un SGBD relacional debe emplear para gestionar la BD

exclusivamente sus facilidades relacionales.

� De esta regla genérica se derivan las 12 reglas de CODD.


Reglas de Codd (y 2)

� 1. Representación de la información: Toda la información en la Base de datos es representada de forma explícita y única a nivel lógico, por medio de valores en columnas de filas de tablas.

� 2. Acceso garantizado: Todo dato (valor atómico) debe ser accesible mediante una combinación de tabla, un valor de su clave y el nombre de una columna.

� 3. Tratamiento sistemático de valores nulos: El SGBD debe soportar la representación y manipulación de información desconocida y/o no aplicable, independientemente del tipo de dato.

� 4. Catálogo en línea (diccionario de datos) basado en el modelo relacional. La descripción de la base de datos se debe representar en el nivel lógico de la misma manera que los datos ordinarios, de forma que los usuarios autorizados puedan consultarla con el mismo lenguaje con el que consultan los datos.



� 5. Sublenguaje de datos completo: El SGBD debe soportar al menos un lenguaje relacional:� a) con sintaxis lineal.� b) que pueda ser usado interactivamente o en programas (embebido).� c) con soporte para operaciones de:

� definición de datos (p.e. declaración de vistas).� manipulación de datos (p.e. recuperación y modificación de tuplas).� restricciones de seguridad e integridad.� gestión de transacciones.

� 6. Actualización de vistas: todas las vistas teóricamente actualizables deben poder serlo en la práctica.

� 7. Inserción, modificación y borrado de tuplas de alto nivel: todas las operaciones de manipulación de datos deben operar sobre conjuntos de filas.



� 8. Independencia física de los datos: cambios en los métodos de acceso físico o la forma de almacenamiento no deben afectar al acceso lógico a los datos.

� 9. Independencia lógica de los datos: los programas de aplicación no deben ser afectados por cambios en las tablas que preservan la integridad.

� 10. Independencia de la integridad: Las restricciones de integridad deben estar separadas de los programas, almacenadas en el catálogo de la BD para ser editadas mediante un sublenguaje de datos.

� 11. Independencia de la distribución: Las aplicaciones no deben verse afectadas al distribuir (dividir entre varias máquinas), o al cambiar la distribución ya existente de la Base de Datos.

� 12. Regla de no subversión: Si el sistema posee un interfaz de bajo nivel (p.e. mediante llamadas en C), éste no puede utilizarse para saltarse las reglas de integridad y las restricciones expresadas por medio de un lenguaje de más alto nivel.


Ejercicio

Carretera (IdCarretera, nombre)

Area (IdArea, nombre)

Tramo (IdCarretera, NroTramo, Area)

Pasa (IdCarretera, NroTramo, CodMunicipio,PtokmEntra,PtoKmSale)

Municipio (CodMunicipio, nombre, localidad)

1. ¿Qué recoge esta base de datos relacional?2. Identifique las claves principales, claves candidatas y claves ajenas3. En las restricciones de referenciabilidad indique las consecuencias del

borrado y la actualización 4. ¿Añadirías alguna restricción de integridad?


Del modelo ER al modelo

relacional



Gestión docente

nombrePROFESORNroPersonal

Apellido_1

DPTO

pertenece

CodDptonombre

dirige

ALUMNOS CodAlunombre

ASIGNATURA

CodAsig

GRUPO

CodGrupo

Max-alum

imparte

dnirealiza

tieneID

(1:1)

(1:n)

(1:1)

(1:1)

(0:n)

(0:1)

(1:1)

(0:n)

(1:1)

NombreCréditosCarácterCurso

capacidadAULASCodAula

clase

(1:n)

(0:n)

díahora

constaCalificación

Convocatoria (1..2)

MATRICULA

(0:n)

(0:n)

CursoAcadCodMatr

(1:1)


Entidades

� ENTIDADES � TABLAS� Se conservan los atributos y la clave principal. � Claves candidatas, establecer restricción de unicidad.� Atributos compuestos � un campo por atributo� Atributos derivados � columnas calculadas� Atributos multivaluados � nueva tabla� Restricciones sobre atributos � lenguaje lógico

� Ej:Asignatura (CodAsig, nombre, créditos, carácter, curso)

Alumno (CodAlu, nombre, dni)

Aula (CodAula, capacidad)

Profesor (NroPersonal, nombre, apellido_1)

Dpto (CodDpto, nombre)

Matricula (CodMatr, cursoAcad)


Entidades débiles

� ENTIDADES DÉBILES � TABLAS� Conserva todos sus atributos y se añade la clave

principal de la entidad fuerte de la que depende. � Si la relación es de identificación, la clave principal la

forma algún atributo de la entidad débil y la clave principal de la entidad fuerte.

� Si la relación es de existencia, tendrá su propia clave, pero se establecerá borrado y actualización en cascada con respecto la entidad fuerte (también se podría restringir).

� Ej:Grupo (CodAsig, CodGrupo, max_alum)


Relaciones

� RELACIONES � TABLAS� La tabla a la que da lugar tendrá como atributos las claves principales de

las entidades que se conectan y los atributos de la relación.� La elección de la clave principal depende de la cardinalidad de la relación

M:N La PK estará formada, al menos, por las PK de las entidades que relaciona. Dimensión temporal.

CONSTA (CodMatr, CodAsig, CodGrupo, Convocatoria, calificación)

1:N La PK estará formada por la PK de la entidad que participa con cardinalidad N

PERTENECE (CodProf, CodDpto)

1:1 La PK estará formada por una de las PK de las entidades que relaciona. La otra actuará como clave candidata.

DIRIGE (CodProf, CodDpto)


Esquema obtenido

Asignatura (CodAsig, nombre, créditos, carácter, curso)



Profesor (NroPersonal, nombre, apellido_1)


Matricula (CodMatr, cursoacad)

Grupo (CodAsig, CodGrp, max_alum)


PERTENECE (NroPersonal, CodDpto)

DIRIGE (NroPersonal, CodDpto)

IMPARTE (CodAsig, CodGrupo, NroPersonal)

CLASE (CodAsig, CodGrupo, CodAula, hora, dia)

REALIZA (NumMatr,CodAlum)

N:N todo clave si más de un grupo en aula


Esquema obtenido: reducción de tablas

Asignatura (CodAsig, nombre, creditos, carácter, curso)



Profesor (NroPersonal, nombre, apellido1)


Matricula (CodMatr, cursoacad)

Grupo (CodAsig, CodGrp, max_alum)

CONSTA (CodMatr, CodAsig, CodGrp, Convocatoria, calificación)

PERTENECE (NroPersonal, CodDpto)

DIRIGE (NroPersonal, CodDpto)

IMPARTE (CodAsig, CodGrupo, NroPersonal)


REALIZA(CodMatr,CodAlu)

Dpto (CodDpto, nombre, CodProfDirige)

Profesor (NroPersonal, nombre, apellido1, CodDpto)

Grupo (CodAsig,CodGrp,max_alum,NroPersonal)

Matricula (CodMatr, cursoacad,CodAlu)


Esquema definitivo

Dpto (CodDpto, nombre, CodProfDirige)

Profesor (NroPersonal, nombre, apellido1, CodDpto)


Matricula (CodMatr, cursoacad, CodAlu)


Grupo (CodAsig, CodGrupo, max_alum, NroPersonal)

Asignatura (CodAsig, nombre, créditos, carácter, curso)



CREATE ASSERTION dirige_dpto AS CHECK not exists

(SELECT * FROM Dpto WHERE CodProfDirige NOT IN

(SELECT NroPersonal FROM Profesor where

Profesor.CodDpto=Dpto.CodDpto ));

CREATE ASSERTION convocatoriasCHECK not exists ( select count(*) from CONSTA

group by Codmatr,CodAsig,CodGrphaving count(*)>2)

U:C D:No action CodDpto not null

U:C D:not action CodProfDirige not null

U:C D:No action CodAlu not null

U:C D:C

U:CD:Not action

U:C D:C

U:CD:Set null

U:CD:Not action

U:C D:Not actionNroPersonal not null

CREATE ASSERTION maxAlumAulaCHECK not exists ( select count(*) from CLASE c,AULA a,GRUPO g

wherec.codAula=a.CodAula and c.CodAsig=g.CodAsig andc.CodGrupo=g.CodGrupo and max_alum>capacidad)


Relaciones unarias

a)

persona (Codper, nombre,…, codper_madre)

b)

persona (Codper, nombre,… )

madre (Codper, codper_madre)

PERSONA

maternidad

hijomadre

Borrado: nullModificación: cascada

Borrado yModificación: cascada o

not action

1:1

0:N

Nulos no permitidos


Generalización

� Crear una tabla por cada entidad que participa

� Crear una tabla para cada caso particular, eliminando la entidad de nivel superior. No frecuente.

� Crear un sola relación

ELEMENTO (codElem, Coef, cc)

LOCAL(CodElem, tipo_comercio, horario)

OFICINA(codElem, actividad)

VIVIENDA (codElem, numHab)

LOCAL(CodElem, tipo_comercio, horario , Coef, cc)

OFICINA(codElem, actividad , Coef, cc)

VIVIENDA (codElem, numHab , Coef, cc)

Nº hab.

Coef. Part.ELEMENTO codElem

c/c

(t,e)

viviendalocal oficina

horariotipo comercio

actividad

(1:1)

Nº hab.

Coef. Part.ELEMENTO codElem

c/c

(t,e)(t,e)

viviendalocal oficina

horariotipo comercio

actividad

(1:1)

ELEMENTO (CodElem, tipo, horario , tipo_comercio, actividad, numhab,Coef, cc)

tipo


Restricciones semánticas

� Totalidad/parcialidad:� Se controla la totalidad prohibiendo la inserción

en el supertipo directamente, se hará cuando se inserte en los subtipos (disparadores)

� La parcialidad no requiere disparadores

� Exclusividad/solapamiento� Se requiere un aserto (o trigger) que compruebe

que si un ejemplar está en un subtipo no puede estar en otro


Agregación

REALIZADO(dni,codpru, fecha)ATENDIDO(dni,codpru, fecha,nrp)

nombreENFERMO Codpru

tipo

PRUEBArealizado

atendido

MEDICO

nombredni

especialidadnrp

fecha

1:1

1:n


Agregación

COCHE

CHASIS MOTOR RUEDA

(1:1)(1:1) (4:4)

� COCHE(Idcoche, fechafabr,…, idchasis,idmotor)� coche_ruedas(idcoche,idrueda)� CHASIS(idchasis, nroserie, lon, anchura,…)� MOTOR (idmotor, nroserie, rpm,…)� RUEDA (idrueda, modelo,…)

obligatorios


Relaciones n-arias

� No es directo, una relación puede tener varias interpretaciones y todas ellas válidas.

� Depende de la cardinalidad: � N:M:S, la PK el conjunto de las PK de cada relación� N:M:1, la PK será el conjunto de las PK con

cardinalidad distinta de 1� N:1:1, probablemente se dividirá en dos relaciones

1:n


Distintas interpretaciones

N:M:S SUMINISTRO (CodProv, CodPieza, CodTrab)

N:M:1 SUMINISTRO (CodProv, CodPieza, CodTrab)

N:1:1 SUM1 (CodPieza, CodProv)SUM2 (CodPieza, CodTrab)

PROVEEDOR

PIEZAsuministroTRABAJON

M

S


A tener en cuenta

� Existen restricciones del modelo ER que deben transformarse al modelo relacional mediante check, asertos o disparadores� Cardinalidades mínimas en relaciones N:M y 1:N

(cuando no se controla con NOT NULL)� Cardinalidades máximas � Restringir el valor de un determinado campo� Condición que han de cumplir los campos de una

determinada tabla � Exclusividad e inclusividad entre relaciones� Exclusividad en generalizaciones� Insertado y borrado en generalizaciones� Atributos derivados (cuando no es campo

calculado)


Ej: Transformación de restricciones

02 - modelos de datos er-uml-relacional

Documents