Tema 2: Diseño de bases de datos

57
Tema 2: Diseño de bases de datos Bases de datos Máster en Tecnologías de Información Geográfica

description

Tema 2: Diseño de bases de datos. Bases de datos Máster en Tecnologías de Información Geográfica. 1. Introducción. Diseño: Proce so de creación de un esquema de la base de datos . Fase s: Conceptual. Lógico. Físico. Ejemplo: Diseño de una base de datos para la secretaría de una facultad. - PowerPoint PPT Presentation

Transcript of Tema 2: Diseño de bases de datos

Page 1: Tema 2: Diseño de bases de datos

Tema 2: Diseño de bases de datos

Bases de datos

Máster en Tecnologías de Información Geográfica

Page 2: Tema 2: Diseño de bases de datos

2

1. Introducción

Diseño: Proceso de

creación de un esquema de la base de datos.

Fases: Conceptual. Lógico. Físico.

Especificaciones(en lenguaje

natural)

Esquemaconceptual(Modelo

entidad-relación)

Esquema lógico(Diseño de

tablasrelacionales)

Esquema físico(Organizaciónde archivos e

índices)

Diseño conceptual

Diseño lógico

Diseño físico

Page 3: Tema 2: Diseño de bases de datos

3

Ejemplo: Diseño de una base de datos para la secretaría de una facultad

Se desea gestionar (almacenar, consultar, actualizar, …) la información correspondiente a la secretaría de una facultad.

Ésta es la información de la que partimos:1. Por cada alumno se requiere la información: DNI,

Apellidos y nombre, domicilio, teléfono y acceso (que indica el tipo de acceso a la universidad). También se precisa conocer en cada momento las asignaturas en las que el alumno está matriculado, así como la nota en cada asignatura. Un alumno sólo puede matricularse en una asignatura una vez, y debe matricularse al menos en una.

2. Por cada asignatura se requiere: código, título y núm de créditos. Puede haber varias asignaturas con el mismo número de créditos, pero todas tienen distinto código y distinto título.

Page 4: Tema 2: Diseño de bases de datos

4

Ejemplo: Diseño de una base de datos para la secretaría de una facultad

3. Cada asignatura puede estar impartida por uno o más profesores. Del profesor se deben conocer los mismo datos que en el caso de los alumnos, salvo el de acceso: DNI, Apellidos y nombre, domicilio y teléfono. El número máximo de asignaturas que puede impartir un profesor es 6, aunque puede que no imparta ninguna.

4. Algunos profesores tienen un supervisor (sólo uno), que es otro profesor.

5. Dados un profesor concreto y una asignatura de las que imparte, se debe conocer el aula en la que el profesor da esa asignatura (es siempre la misma). El aula se identifica mediante el nombre de edificio y el número de aula. Se supone que dentro del mismo edificio cada aula tiene un número diferente.

Page 5: Tema 2: Diseño de bases de datos

5

2. Diseño conceptual

Conceptos: Entidad.

DNI = 01234567Z, Nombre y apellidos = Manuel Vázquez Prieto,Teléfono = 91-12345678 Domicilio = Calle del Jazmín 7, 4 Izq.

Atributo. Monovalorados/multivalorados Simples/Compuestos

Relación.(José García, Bases de datos)

Page 6: Tema 2: Diseño de bases de datos

6

2. Diseño conceptual

Conceptos: Tipos de entidad.

Alumno

Tipos de relación.Matrícula

Page 7: Tema 2: Diseño de bases de datos

7

2. Diseño conceptual

Conceptos: Clave. Identificador/es unívoco de una

entidad.DNI en Alumnos

Tipos de clave: Superclave. Clave primaria. Clave candidata.

Page 8: Tema 2: Diseño de bases de datos

8

Diagrama Entidad-Relación

Modelo de datos de alto nivel. Consta de elementos básicos (entidades) y de

relaciones entre ellos (relaciones). Las entidades se describen por un conjunto de

atributos.

Page 9: Tema 2: Diseño de bases de datos

9

Diagrama Entidad-Relación

Diagrama E-R Rectángulos => entidades

Elipses => atributos

Rombos => relaciones

Además es posible representar ciertas restricciones: Clave Cardinalidad Participación

Asignaturas

Teléfono

Alumnos

MatrículaAlumnos Asignaturas

Page 10: Tema 2: Diseño de bases de datos

10

Atributos simples y compuestos:

Se dice que un atributo es compuesto cuando puede descomponerse en otros componentes o atributos más pequeños, y simple en otro caso.

Ej.: En el caso del nombre de una persona puede que nos interese descomponerlo a su vez en nombre, primer apellido y segundo apellido por separado.

Se representan como elipses (atributos simples) unidos a otra elipse (atributo compuesto) que se une a la entidad.

Simple A

Compuesto

Simple B

Page 11: Tema 2: Diseño de bases de datos

11

Atributos monovalorados y multivalorados

Se llaman atributos multivalorados a aquellos que pueden contener más de un valor simultáneamente, y monovalorados a los que sólo pueden contener uno.

Ej.: Una persona puede tener varios números de teléfono (casa, trabajo, móvil) y puede que nos interese tenerlos todos.

En este caso haremos de teléfono un atributo multivalorado.

Los atributos multivalorados se representan con dos elipses concéntricas

MuMultivalor

Page 12: Tema 2: Diseño de bases de datos

12

Ejemplo atributos

Page 13: Tema 2: Diseño de bases de datos

13

Atributos de una relación

Una relación puede incluir un nombre y unos atributos que la caractericen

Usuario Librotiene_prestado

Fecha_devoluciónDNI ISBN

Page 14: Tema 2: Diseño de bases de datos

14

Pero es recomendable que estos últimos sóloaparezcan en ella si no pueden ser añadidos a alguna de las entidades que participan de la relación.

Atributos de una relación

Cliente Cuentaes_titular

Fecha_aperturaDNI NºCUENTA

Page 15: Tema 2: Diseño de bases de datos

15

Valores nulos

El valor nulo tiene dos modos de uso semánticamente distintos:

No existencia del dato: el atributo no tiene sentido en la entidad particular.

Ej. atributo PISO en una entidad CLIENTES donde el elemento insertado corresponde a un cliente con domicilio en una casa unifamiliar.

Desconocimiento: el atributo se “deja en blanco” por no disponer de la información.

Ej. atributo ALTURA en una entidad JUGADORES.

Ambigüedad: a veces no es posible distinguir si el valor de un atributo “no existe” o si “se desconoce”.

Ej. atributo TELF_MOVIL en una entidad ALUMNOS

Page 16: Tema 2: Diseño de bases de datos

16

Grado de una relación

Grado de una relación es el número de entidades que asocia:

Relación binaria: asocia dos entidades

Relación ternaria: asocia tres entidades

Relación recursiva: asocia una entidad consigo misma

Page 17: Tema 2: Diseño de bases de datos

17

Roles

La función que desempeña una entidad en una relación se denomina rol de esa entidad.

En general, los roles están implícitos y no se suelen especificar.

Resultan útiles cuando el significado de una relación necesita aclaración

P.ej: en relaciones recursivas

Profesor

supervisa

Supervisor Supervisado

Page 18: Tema 2: Diseño de bases de datos

18

Diseño conceptual

Un buen diseño debe ser Conciso Fácil de comprender Fácil de mantener Eficiente

El diseño del modelo E-R a partir del análisis inicial NO es directo.

A un mismo análisis le corresponden muchos diseños “candidatos”.

Dos peligros importantes a evitar Redundancia

Información repetida Incompletitud

Aspectos mal modelados

Page 19: Tema 2: Diseño de bases de datos

19

Pasos básicos a seguir

Pasos en el diseño de un diagrama E-R:1. Elección de los tipos de entidad y sus

atributos.

2. Elección de los tipos de relación y sus atributos.

3. Restricciones.

Page 20: Tema 2: Diseño de bases de datos

20

Elección de los tipos de entidad y sus atributos

Del punto 1 de la especificación del problema de la secretaría se deduce que va a haber un tipo de entidad ALUMNOS, pero no cuáles son sus atributos:

¿Debe incluir las asignaturas (punto 2) en las que está matriculado?

La respuesta es NO y hacerlo así sería un error grave. Aparte de la idea ‘filosófica’ (cada asignatura es

un objeto con significado propio, es decir, una entidad), al mezclar en una sola entidad alumnos y asignaturas cometemos varios errores.

Page 21: Tema 2: Diseño de bases de datos

21

Elección de los tipos de entidad y sus atributos

Un alumno no tiene una asignatura asociada sino un conjunto de asignaturas asociadas.

En cambio, sí tiene un DNI asociado, una dirección asociada, etc.

Por tanto las entidades serían de la forma {DNI=12345678V, Nomb.Ape=Luis Martínez,

Telf.=01234567, Cod=MD, Título=Matemática Discreta, Créditos=9}

{DNI=12345678V, Nomb.Ape=Luis Martínez, Telf.=01234567, Cod=IS, Título=Ingeniería del Software, Créditos=12}

{DNI=12345678V, Nomb.Ape=Luis Martínez, Telf.=01234567, Cod=LPI, Título=Laboratorio de programación I, Créditos=X}

ERROR: Redundancia (información de alumnos repetida)

Page 22: Tema 2: Diseño de bases de datos

22

Elección de los tipos de entidad y sus atributos

Esto se puede solucionar si admitimos que los atributos contengan conjuntos de valores (multivalor)

{ DNI=12345678V, Nomb.Ape=Luis Martínez, Telf.=01234567, … , Asignaturas={ {Cod=MD, Título=…}, {COD=IS,Título=…}, {Cod=LPI,Título=…} } }

Errores: Difícil de manejar Poco escalable cuando el conjunto

de valores es muy elevado

“Tablas” de Varias Dimensiones NO es Relacional

Page 23: Tema 2: Diseño de bases de datos

23

Elección de los tipos de entidad y sus atributos

Además, las asignaturas son siempre las mismas, con lo que por cada alumno que se matricula en la misma asignatura hay que repetir la información de ésta.

{ DNI=12345678V, Nomb.Ape=Luis Martínez, Telf.=01234567,Asignaturas={ {Cod=MD, Título=…}, {COD=IS,Título=…}, {Cod=LPI,Título=…} } }

{ DNI=0000001, Nomb.Ape=Eva Manzano, Telf.=01234567,…, Asignaturas={ {Cod=MD, Título=…}, {COD=IS,Título=…}, {Cod=BDSI,Título=…} } }

Error: Redundancia (otra vez, información de asignaturas

repetida)

Page 24: Tema 2: Diseño de bases de datos

24

Elección de los tipos de entidad y sus atributos

Además, en cualquiera de estas soluciones no se pueden guardar los datos de una asignatura hasta que no se matricule un alumno en ella.

Puede ser que en secretaría quieran meter los datos de las asignaturas antes de empezar el proceso de matrícula de alumnos

No pueden Podría pensarse: las incluimos con los

datos de los alumnos vacíos (nulos). Olvídalo…es una chapucilla

Page 25: Tema 2: Diseño de bases de datos

25

Elección de los tipos de entidad y sus atributos

Del punto 3 de la especificación, por cada profesor hay que apuntar las asignaturas que imparte.

La información de las asignaturas debe estar por tanto relacionada con la de los profesores, pero ya está incluida con los alumnos

Error: se vuelve a repetir la información de las asignaturas más Redundancia

Page 26: Tema 2: Diseño de bases de datos

26

Elección de los tipos de entidad y sus atributos

Por tanto hay que distinguir entre el tipo de entidad ALUMNOS y el tipo de entidad ASIGNATURAS.

Ambas se relacionarán mediante un tipo de relación MATRICULA.

Parece claro que los restantes tipos de entidad serán: PROFESORES y AULAS.

Los atributos de cada tipo de entidad serán:

Alumnos: DNI, Apellidos y Nombre, Domicilio, teléfono y acceso

Asignaturas: Código, título, y núm. Créditos Profesores: DNI, Apellidos y nombre, Domicilio y teléfono Aulas: Edificio y núm. edificio

Page 27: Tema 2: Diseño de bases de datos

27

Elección de los tipos de entidad y sus atributos

Aún nos falta un atributo: la Nota

¿Dónde la ponemos? ¿En alumnos?

NO, porque un alumno tiene muchas notas ¿En asignaturas?

NO porque una asignatura tiene muchos alumnos

Posible solución: Nota será un atributo del tipo de relación

Matrícula. (vimos que esto se debe evitar por sencillez...pero es posible)

Page 28: Tema 2: Diseño de bases de datos

28

Elección de los tipos de relación

El primer tipo de relación es MATRÍCULA que relaciona cada alumno con las asignaturas en las que está matriculado.

Además, está relación tiene un atributo, Nota, que se asocia cada posible relación.

Además, hay otro tipo de relación: SUPERVISA que va de profesores a

profesores y que incluye los roles supervisor y supervisado.

Page 29: Tema 2: Diseño de bases de datos

29

Elección de los tipos de relación

La última relación es IMPARTE que relaciona cada profesor con la asignatura que imparte y el aula en la que da esa asignatura.

Aquí también surgen varias posibilidades: a) Hacer 2 relaciones binarias:

PROFESOR -ASIGNATURA y ASIGNATURA -AULA.

b) Hacer 1 relación ternaria: PROFESOR- AULA- ASIGNATURA

c) Hacer 3 relaciones binarias: PROFESOR –ASIGNATURA PROFESOR –AULA ASIGNATURA -AULA

Page 30: Tema 2: Diseño de bases de datos

30

Alumno Asignatura

AulaProfesor

Matrícula

Imparte

Supervisa

Ejemplo: Diseño de una base de datos para la secretaría de una facultad

DNI

COD

Nota

DomicilioEdificio

Ap NomDirecc Telf. Título N_Cred

Número

DNI

Ap Nom Telf.

supervisor supervisado

Acceso

Page 31: Tema 2: Diseño de bases de datos

31

Restricciones

Con los elementos anteriores tenemos una primera aproximación a los diagramas ER, en la que tenemos definidos los elementos principales de los diagramas.

Sin embargo, en el modelo ER también se pueden definir numerosas restricciones sobre los tipos de entidades y tipos de relaciones

Page 32: Tema 2: Diseño de bases de datos

32

Restricciones

Las restricciones son propiedades que se asocian a un tipo de entidad o de relación.

Las instancias válidas del tipo de entidad o relación son aquellas en las que se verifique el conjunto de restricciones asociadas.

Observaciones: Las restricciones son parte del diseño de la BD igual

que los tipos de entidades o de relaciones. Los SGBD se encargan de comprobar que la instancia

verifica las restricciones más usuales. Ej.:En el caso anterior, una vez incluida la restricción, el

SGBD no nos permitiría insertar la segunda tupla.

 

Page 33: Tema 2: Diseño de bases de datos

33

Restricciones de clave

Ej.: En la relación SUPERVISA un profesor puede tener a lo sumo un supervisor, pero el diagrama anterior permite:

…es decir, que un profesor tenga p.e. dos supervisores Pero NO debería ser una instancia válida de la relación

porque según enunciado: “un supervisor (sólo uno)” Solución: imponer restricción de clave.

 

SUPERVISOR SUPERVISADO

({DNI=666666,…}, {DNI=444444,…})

({DNI=000001,…}, {DNI=444444,…})

Inst

ancia

Tuplas

Page 34: Tema 2: Diseño de bases de datos

34

Restricciones de clave

Las entidades deben poder distinguirse unas de otras a través de los valores de sus atributos.

Interesa encontrar un conjunto de atributos lo más pequeño posible que nos permita distinguir unas entidades de otras.

Estos conjuntos serán las claves.

Aparecen como atributos subrayados en el diagrama E-R.

Page 35: Tema 2: Diseño de bases de datos

35

Restricciones de cardinalidad

Fijado un alumno puede haberse matriculado en cualquier número de asignaturas

no hay restricción sobre el tipo de entidad asignatura en la relación matrícula.

Restricción de cardinal para asignatura: ≤ N.

Fijada una asignatura, puede haberse matriculado sobre ella un número cualquiera de alumnos

no hay restricciones sobre el tipo de entidad alumnos en la relación matrícula.

Restricción de cardinal para alumnos: ≤ N.

 

Page 36: Tema 2: Diseño de bases de datos

36

Restricciones de cardinalidad

El supervisor de un profesor, si lo tiene, es único.

El tipo de entidad profesor, en el papel supervisado tiene cardinal ≤1.

Restricción de cardinal para profesor (supervisado): ≤ 1

El tipo de entidades profesor, en el papel supervisor no tiene ninguna restricción de cardinal

un profesor puede supervisar a un número indeterminado de profesores.

Restricción de cardinal para profesor (supervisor): ≤ N

 

Page 37: Tema 2: Diseño de bases de datos

37

Restricciones de cardinalidad

Cada persona tiene un único país de nacimiento: es decir, fijada una persona, existe un país.

Restricción =1 para el tipo de entidad país en el tipo de relación nacida.

Personas PaísNacida1N

Dado un país hay una cantidad no determinada en general de personas nacidas allí,

Restricción = N para el tipo de entidad personas en el tipo de relación nacida.

Page 38: Tema 2: Diseño de bases de datos

38

Representación de cardinalidad en diagramas E-R

Hay VARIAS formas de expresar las restricciones de cardinalidad sobre tipos de relaciones en los diagramas E-R:

 

Entity_1 Entity_2R11

Entity_1 Entity_2R1N

Entity_1 Entity_2RN1

Entity_1 Entity_2RNN

one-to-one

one-to-many

many-to-one

many-to-many

Page 39: Tema 2: Diseño de bases de datos

39

Restricción de participación

Se dice: “Participación de una entidad en una relación”

Participación: Se dice que Ej tiene participación total en r si cada

entidad ej Ej se encuentra en alguna tupla de r.

En otro caso se dice que la participación es parcial.

 

Alumnos Matrícula Asignaturas

Page 40: Tema 2: Diseño de bases de datos

40

2. Diseño lógico

Herramienta: Modelo relacional.

Resultado: Esquema lógico.

Page 41: Tema 2: Diseño de bases de datos

41

Modelo relacional

El concepto principal es la tabla o relación Cada tabla o relación es un conjunto de tuplas donde

cada una de ellas corresponde a una fila de la tabla Cada tupla corresponde a la descripción, en el

diagrama ER, de una entidad particular o a la descripción de una relación particular entre varias entidades particulares.

No hay que confundir las tablas con las relaciones del modelo Entidad Relación.

Las tablas (o relaciones) valen para tipos de relaciones igual que para tipos de entidades.

Page 42: Tema 2: Diseño de bases de datos

42

Terminología del modelo relacional

Relación Igual que en el esquema ER. Las entidades particulares se representan como tuplas

o filas de la tabla. Atributo

Igual que en el esquema ER. Se representan como las columnas de la tabla. Los valores de los atributos de las tuplas deben ser

atómicos. No puede haber atributos compuestos

O se representan sus componentes individuales como atributos

O se junta toda la información en un único atributo Ej: secretaría => domicilio como atributo simple con toda la

información No puede haber atributos multivalorados

Veremos como convertirlos en atributos monovalorados

Page 43: Tema 2: Diseño de bases de datos

43

Terminología del modelo relacional

Esquema de una tabla o relación viene dado por el nombre de la tabla y una lista de

atributos. Alumnos (DNI, Apellidos, Nombre, teléfono, acceso)

El orden de los atributos en la lista no importa. Lo fijamos porque nos viene bien para

representarlo como tabla, pero cualquier permutación es válida.

Instancia de una tabla => Conjuntos de entidades particulares.

Cada entidad particular se representa como una tupla. Cada componente de la tupla corresponde con el valor

del atributo correspondiente, según el orden enunciado en el esquema de la tabla.

Page 44: Tema 2: Diseño de bases de datos

44

Ejemplo secretaría

Ejemplo: Instancia de la tabla Alumnos: { (01234567Z, Vázquez , Manuel, 9112345678,

normal), ....}

DNI Apellido

Nombre teléfono acceso

01234567Z Vázquez Manuel 9112345678 normal

Page 45: Tema 2: Diseño de bases de datos

45

Terminología del modelo relacional

Un tabla no puede contener tuplas repetidas Existe un conjunto de atributos que determina

unívocamente a cada tupla Los conceptos de superclave, clave candidata y clave

primaria explicados en el modelo ER son válidos para el modelo relacional

Cada tabla debe tener una clave primaria Los atributos que forman la clave primaria nunca pueden

tomar valores nulos

Page 46: Tema 2: Diseño de bases de datos

46

Paso del modelo ER al modelo relacional

Se puede transformar un diagrama ER (diseño conceptual) en un modelo relacional (diseño lógico) mediante una serie de transformaciones

Entidades Relaciones

Restricciones de cardinalidad Atributos multivalorados

Page 47: Tema 2: Diseño de bases de datos

47

Entidades

Para cada entidad que no sea débil se crea una tabla con el mismo nombre y conjunto de atributos.

La clave primaria es la del diagrama ER

En este punto no se indica nada acerca de las relaciones en los que participa el tipo de entidades.

Page 48: Tema 2: Diseño de bases de datos

48

Ejemplo secretaría

En el caso de la BD de secretaría los tipos de entidades dan lugar a las tablas:

Alumnos(DNI, Apellidos, Nombre, teléfono, acceso) Suponiendo teléfono atributo monovalor

Asignaturas(Código, título, núm créditos) Profesores(DNI, ApellidosYNombre, domicilio, teléfono) Aulas(Edificio, núm. aula)

Page 49: Tema 2: Diseño de bases de datos

49

Relaciones binarias: restricciones de cardinalidad varios a varios

Varias a varias

E1 E2R

Page 50: Tema 2: Diseño de bases de datos

50

Relaciones binarias: restricciones de cardinalidad varios a varios

Sea R relación binaria entre E1 y E2. Clave primaria de E1

Conjunto de atributos c1 Clave primaria de E2

Conjunto de atributos c2

Relación construida a partir de R Atributos de T: c1 + c2 + Atributos de R

Superclave para R: c1 c2

Page 51: Tema 2: Diseño de bases de datos

51

Ejemplo secretaría

Ej: En el caso de la BD de secretaría los tipos de relación dan lugar a las tablas:

Matrícula(DNI, código, nota) Supervisa(DNISupervisor, DNISupervisado) Imparte(DNI, código, edificio, num. aula)

ALUMNOS (DNI, …..)

MATRICULA (DNI, Código, Nota*)

ASIGNATURAS (Código, …..)

Page 52: Tema 2: Diseño de bases de datos

52

Ejemplo secretaría

Ejemplo: Instancia de la tabla Matrícula: { (01234567Z, 520, 8), ....}

DNI código nota

01234567Z 520 8

Page 53: Tema 2: Diseño de bases de datos

53

Relaciones con restricciones de cardinalidad 1 a M

Una a varias

E1 E2R

Page 54: Tema 2: Diseño de bases de datos

54

Relaciones con restricciones de cardinalidad 1 a M

Relación binaria con restricciones varios a uno Incluir en el esquema de tabla de la entidad con

restricción varios Añadir como clave externa (foreign key) a la clave

primaria del otro esquema Añadir los de de la relación. Mantener los atributos de la propia entidad Mantener las claves primarias

Page 55: Tema 2: Diseño de bases de datos

55

Relaciones con restricciones de cardinalidad 1 a M

Esquema: Personas(DNI,Apell, PaisNac) Países(Nombre)

Integridad referencial: Personas.PaisNac -> Países.Nombre

Personas Países Nacida Apell.

DNI

Nombre

Page 56: Tema 2: Diseño de bases de datos

Anexo

Page 57: Tema 2: Diseño de bases de datos

57

Ejercicio de Clase. Modelo E-R