T1 1

Diseño de Bases de DatosProfesor: Jesualdo Tomás Fernández Breis

Despacho E-24 (3º planta)

Email: jfernand@dif.um.es

Web: http://dis.um.es/~jfernand

Asignatura: http://dis.um.es/~jfernand/0405/dbd/

Tutorías: Martes, Jueves 10-13

T1 2

Diseño de Bases de Datos Horario teoría (D2; Aulario Norte)

Miércoles 9-11

Horario prácticas (Laboratorio 1/5) Martes 16.30-18.30 Martes 18.30-20.30

3 clases por recuperar

Examen 11 Febrero 7 Septiembre

T1 3

Temario Teoría (I) Tema 1. Metodologías de Diseño.

Introducción al Diseño de Bases de Datos. Fases de una metodología de diseño. Metodologías ascendentes y descendentes. Características de una metodología de diseño.

Tema 2. Modelo Entidad / Relación. Estática del MER: Entidades, Interrelaciones, Atributos,

Dominios, Claves. Semántica de las Interrelaciones. Generalización y especialización. Herencia. Agregación.

Tema 3. Diseño conceptual.

Etapas de diseño conceptual (Modelo conceptual). Análisis de requisitos. Conceptualización. Construcción del esquema conceptual: Enfoques y Estrategias. Integración de vistas. Características del esquema conceptual

T1 4

Temario Teoría (II) Tema 4. Diseño lógico.

Etapas de diseño lógico. Transformación del esquema conceptual al lógico estándar. Diseño lógico específico.

Tema 5. Teoría de la normalización. Introducción. El proceso de normalización. Objetivos de la normalización.

Dependencias funcionales. Descomposición. Forma normal de Boyce y Codd (FNBC). Dependencias funcionales parciales y transitivas. Segunda y Tercera Forma normal (2FN, 3FN).Dependencias multivaluadas. Cuarta forma normal (4FN). Dependencias de combinación. Quinta forma normal (5FN).

Tema 6. Diseño Físico. Visión general: introducción, objetivos y factores que influyen en el

diseño físico.El proceso de diseño físico. Selección de la organización de ficheros y estructuras de acceso.Ajuste del diseño del esquema, de índices y de consultas.

T1 5

Prácticas (provisional) Se propondrá varias descripciones de sistemas de

información, sobre las que los alumnos deberán aplicar el método de diseño de bases de datos. Para la realización de las prácticas, se utilizarán los laboratorios que el Departamento disponga, herramientas CASE y SGBD.

Los ejercicios propuestos podrán incluir los siguientes aspectos: Diseño del Esquema Conceptual de base de datos (BD) y de las

transacciones que se ejecutarán sobre él. Correspondencia entre el Esquema Conceptual y el Esquema Lógico según el Modelo de Datos asumido por el Sistema Gestor de Base de Datos (SGBD) usado en la implementación.Implementación del Esquema Lógico de la BD. Implementación de los diferentes Esquemas Externos.Diseño específico de las transacciones para el Modelo de Datos y el SGBD usados.Diseño e implementación del Esquema Físico de la BD.Implementación de las transacciones diseñadas previamente.

T1 6

Criterios de Evaluación

La evaluación de la parte teórica se realizará a través de una prueba escrita al final del curso académico.

Para la calificación de la parte práctica se tendrá en cuenta los informes entregados por los alumnos, así como las entrevistas de prácticas realizadas, si éstas han tenido lugar. Para aprobar la parte práctica de la asignatura en una determinada convocatoria, es necesario haber superado todas las prácticas planteadas a lo largo del curso.

Para aprobar la asignatura en una determinada convocatoria es necesario superar ambas partes, teórica y práctica, por separado.

Nota: 50% teoría; 50% prácticas

T1 7

Diseño de Bases de Datos

Tema 1. METODOLOGÍA DE DISEÑO

T1 8

Introducción Desde 60 desarrollo de tecnología de BD, marco

teórico: teoría relacional de datos, procesamiento y optimización

de consultas, control de concurrencia, gestión de transacciones y recuperación, ...

en paralelo desarrollo de metodologías+ técnicas de diseño: Fue tarea de expertos, más un artearte que una ciencia. Actualmente considerada una disciplina estable, con sus

propios métodos y técnicas.

Consenso: descomposición del proceso de diseño en fases, principales objetivos de cada fase técnicas para conseguir esos objetivos.

T1 9

Introducción Ingeniería del SW:

importantes esfuerzos para encontrar las metodologías más adecuadas

gran impacto en el desarrollo de un producto SW: costes, plazos, calidad, mantenimiento.

MÉTRICA, SSADM, MERISE,...Integran datos y funciones (mayor énfasis)

Diseño de una BD No existe metodología consagrada (diversos

enfoques) limitado a veces a teoría de normalización debe abarcar otras etapas (desde concepción a

instrumentación)

T1 10

Metodología De Miguel, Piattini (1993):

"Conjunto de modelos, lenguajes y otras herramientas que nos facilitan la representación de los datos en cada fase del proceso de diseño de una BD, junto con las reglas que permiten el paso de una fase a la siguiente".

Herramientas: cualquier recurso a disposición de la metodología modelo de datos, lenguaje de datos, documentación y

reglas. + diagramas, grafos, teorías, etc

T1 11

Metodología Lenguaje de datos:

resultado de definir una determinada sintaxis sobre un modelo de datos (p.e. SQL).

Documentación: Descripción normalizada de los resultados de cada etapa. diagramas: Representación gráfica de construcciones del

MD; documentos fáciles de leer y entender (p.e.: grafos relacionales)

Reglas: actúan sobre los elementos de entrada de cada fase de

diseño para conseguir las salidas de cada una de ellas. Otras herramientas: CASE.

Oracle Designer, ERwin, ER Studio, System Architect,... Metodologías de diseño implícitas en estas herramientas

T1 12

Modelo de datos Abstracción que define cómo se estructuran

los datos y las operaciones permitidas (*)

No interpreta el significado de los datos ni cómo serán usados

Modelo < Reglas, Operaciones> formalismos

Reglas: Estructura y restricciones

T1 13

Modelo / esquema de datos Esquema de datos (de base de datos) =

descripción específica de un UoD (o submundo real) determinado, en términos de un modelo de datos

Ejemplar del esquema = conjunto de datos que un determinado momento de encuentran almacenados en el esquema. (Realización, estado, ocurrencia, instancia)

Ingeniería del Sw, “modelo de datos”, término sobrecargado = instrumento de descripción (BD, modelo de datos)

formalismos resultado de la misma (BD, esquema de datos)

T1 14

Modelo / esquema de datos

T1 15

Modelos de Datos, tipos de abstracción

UoD proceso de abstracción esquema de datos

Abstracciones vínculos entre elementos del modelo

4 los tipos de abstracción básicos (pueden combinarse) que utilizan los MD: Clasificación (categoría – ejemplar) Agregación (categoría – categoría) Generalización (categoría – categoría) Asociación (categoría – categoría)

T1 16

MD, tipos de abstracción: Clasificación Abstraer las características comunes a un

conjunto de ejemplares para crear una categoría (clase, tipo) a la cual pertenecen dichos ejemplares.

Teoría de conjuntos, clase: intensión (parte definitoria) extensión (colección de ejemplares en un momento dado)

Se corresponde con el concepto de pertenencia a un conjunto.

Proceso inverso: particularización.Clase:PROFESOR

Ejemplares: profesor 1,..., profesor n

clasificación

particularización

T1 17

MD, tipos de abstracción: Agregación Agregación (Desagregación):

Construir un nuevo elemento del modelo como compuesto de otros elementos (componentes, “son parte de”).

Agregación de clases Clase compuesta AREA 1, AREA 2, ... DEPARTAMENTO

Agregación de propiedades Clase Código, nombre, créditos, ... ASIGNATURA

Agregación de propiedades Propiedad compuesta

Día, Mes, Año Fecha

T1 18

MD, tipos de abstracción: Generalización Generalización / (Especialización):

Abstraer las características comunes a varias clases (subclases) para construir una clase más general (superclase). Parecido a clasificación:

(ejemplares clase / clases clase).

El conjunto de ejemplares de la subclase “es un” subconjunto de los ejemplares de la superclase.

Todo ejemplar de la subclase, es también un ejemplar de la superclase.

Además de poseer características específicas, hereda todas las de la correspondiente superclase.

SuperClase:PERSONA

SubClases: PROFESOR, ESTUDIANTE,...

especialización

generalización

T1 19

MD, tipos de abstracción: Asociación

Asociación / Disociación:vincula dos o más clases, creándose un elemento de tipo distinto.

PROFESOR imparte ASIGNATURA

Puede parecerse a la agregación, pero posee rasgos distintivos

T1 20

Combinación de tipos de abstracciones

La clase PERSONA se puede obtener por

clasificación de sus ejemplares (persona x, persona y, ...)

agregación de sus propiedades (DNI, Nombre, Dirección).

generalización de las clases PROFESOR y ESTUDIANTE

T1 21

Volviendo a definir modelo de datos… Conjunto de conceptos, reglas y convenciones bien

definidos que nos permiten aplicar una serie de abstracciones a fin de describir y manipular los datos de un cierto mundo real que deseamos almacenar en la base de datos

MD=Reglas+ Operaciones

Reglas: componente estático (definición, LDD)

Operaciones: componente dinámico (manipulación, LMD)

LD= LDD+LMD

T1 22

Los MMDD en el proceso de diseño de una BBDD

Proceso de diseño: Conjunto de etapas necesarias para pasar de un UoD a la base de datos que lo representa.

Objetivos de un modelo de datos

Formalización Estructuras y restricciones Lenguaje de datos

Diseño En el modelo de datos se basa la metodología de diseño

T1 23

El proceso de Diseño de Bases de Datos

[Elmasri/Navathe 02]

Es el proceso de diseñar la estructura lógica y física de una o más bases de datos para satisfacer las necesidades de información de los usuarios en una organización,para un conjunto definido de aplicaciones.

T1 24

El proceso de Diseño de Bases de Datos Los objetivos del diseño de BD:

1. satisfacer requisitos de contenido de información de usuarios y aplicaciones

2. proporcionar una estructuración de los datos natural y fácil de entender

3. soportar los requisitos de procesamiento y objetivos de rendimiento como tiempo de respuesta, tiempo de procesamiento, espacio de almacenamiento...

4. conseguir un esquema flexible de BD, es decir tal que sea posible modificarlo (como consecuencia de cambios en los requisitos del sistema) fácilmente una vez implementada la BD

T1 25

Fases principales en el Diseño de BD[Elmasri/Navathe 02]

1. Obtención y análisis de requisitos (S.I.)2. Diseño conceptual3. Elección de un SGBD4. Diseño lógico5. Diseño físico6. Implementación y ajuste del sistema de

BD (S.I.)

Fase 1: Obtención y análisis de requisitos

Fase 2: Diseño conceptual

Fase 3: Elección SGBD

Fase 4: Diseño lógico

Fase 5: Diseño físico

Fase 6: Implementación y ajuste del sistema de BD

CONTENIDO Y ESTRUCTURA DE DATOS

APLICACIONES DE LA BASE DE DATOS

REQUISITOS DE DATOS

DISEÑO DEL ESQUEMA LÓGICO Y DE LAS VISTAS

DISEÑO DE TRANSACCIONES Y APLICACIONES

DISEÑO DELESQUEMA CONCEPTUAL

REQUISITOS DE PROCESAMIENTO

DISEÑO DEL ESQUEMA INTERNO

Sentencias DDLSentencias SDL

IMPLEMENTACIÓN DE TRANSACCIONES Y

APLICACIONES

frecuencias, restricciones de

rendimiento

T1 27

Actividades paralelas Muchas interacciones entre ambos lados no

mostradas. Habituales ciclos de retroalimentación entre fases. DBD: aproximación al desarrollo de SI orientada

/controlada por los datos (data-driven): primero se diseñará la BD y posteriormente se

diseñarán las aplicaciones. (data modeling) aproximación alternativa al diseño de SI centra su

principal atención a los procesos (process-driven). (process modeling).

Ingenieros SW y Diseñadores de BD reconocen que ambas actividades deben efectuarse en coordinación.

T1 28

Actividades paralelas Análisis Funcional:

especificación de los requerimientos de las aplicaciones

esquema funcional: descripción de alto nivel de actividades y flujos de información intercambiados por esas actividades.

bases de datos: simples depósitos de información,

análisis funcional integra al modelado conceptual.

T1 29

Actividades paralelas Diseño:

Especificación de las aplicaciones: descripción a alto nivel de abstracción del

comportamiento de los programas de aplicación (en particular describen como las aplicaciones acceden a la BD).

Especificaciones detalladas de programas de aplicación y eventualmente el código de los programas.

Estas fases integran los diseños lógico y físico (para estas etapas de diseño habrá que tener en cuenta los requisitos de las funciones (procesos).

T1 30

Actividades paralelas Ambas aproximaciones al diseño de SI deben de considerarse

como complementarias y deben desarrollarse en paralelo.

Los esquemas funcional (resultado del Análisis Funcional) y conceptual (resultado del Modelado Conceptual) deben de ser mutuamente consistentes (sin conflictos) y completos:

todos los datos requeridos por las funciones están representados en el esquema conceptual

y las funciones incluyen todas las operaciones requeridas por la base de datos.

El diseño físico de la base de datos depende de las aplicaciones que van a utilizar los ficheros de la base de datos (forma y frecuencia de acceso a los datos, restricciones de rendimiento, etc.).

En el diseño de los programas de aplicación se hace referencia a los elementos que tiene el esquema lógico de la base de datos.

T1 31

Diseño de BD

Dependencia de: Clase de SGBD

SGBD específico

Modelado Conceptual NO NO Diseño Lógico SI NO Diseño Físico SI SI

Tres grandes fases (comprenden a varias etapas): Modelado conceptual, diseño lógico y diseño físico.

T1 32

Modelado Conceptual Propósito:

describir el contenido de información de la BD (tipos de datos, relaciones y restricciones), no las estructuras de almacenamiento que se

puedan requerir para su gestión Esquema conceptual:

descripción de alto nivel de la estructura de la BD;

independiente del SGBD particular usado para la implementación de la BD.

Modelo Conceptual: lenguaje usado para la descripción del

esquema conceptual.

T1 33

MC, Enfoque Centralizado Diseño top-down, descendente:

esquema conceptual refleja directamente la visión de la empresa que se intenta modelar.

Diferentes listas de requerimientos de usuarios se combinan en una lista de requerimientos global antes de la construcción del esquema conceptual global.

El esquema conceptual se elabora mediante la introducción de sucesivos refinamientos

posteriormente se definen las vistas de usuario (subesquemas) como subconjuntos de este esquema conceptual.

T1 34

Enfoque Centralizado

T1 35

MC, Integración de vistas Diseño bottom-up, ascendente:

el esquema conceptual se obtiene como resultado de la integración de las vistas (esquemas conceptuales) de los distintos usuarios.

Se empieza construyendo las distintas vistas de usuario

teniendo en cuenta las restricciones entre éstas, se elabora el esquema conceptual mediante un proceso de integración.

T1 36

Integración de vistas

T1 37

La aplicación de un diseño centralizado o de integración de vistas dependerá de la complejidad y tamaño de la BD. Normalmente, el enfoque centralizado podrá

utilizarse para BD pequeñas y poco complejas.

T1 38

Diseño Lógico independiente del sistema: dependiente del

modelo de datos usado, no tanto del SGBD específico.

Esquema Lógico: descripción de la estructura de la BD en términos del

modelo de datos de implementación. Esquema conceptual y esquemas externos (vistas)

en la arquitectura a tres niveles. Modelo Lógico:

lenguaje usado para especificar el esquema lógico. Relacional, Red, Jerárquico, Orientado a Objeto.

T1 39

Diseño Físico Objetivo: conseguir una instrumentación

eficiente del esquema lógico. Las fases de diseño físico y lógico están relacionadas

(retroalimentación, adaptar diseño lógico a requisitos de físico).

Dependerá del SGBD específico utilizado en implementación.

Esquema físico: Descripción de la implementación de la BD:

estructuras de almacenamiento y métodos de acceso.

Esquema interno en arquitectura a tres niveles. Tanto el esquema lógico como el físico se expresarán

usando el DDL y SDL del SGBD destino. Posteriormente se podrá pasar a la construcción de la BD,

pruebas, carga y explotación,...

T1 40

Características (deseables) de una metodología de diseño.

A) Claridad y comprensibilidadDistintas clases de personas (usuarios, técnicos de sistemas, analistas, etc.) participan en el proceso de diseño;

una sencillez tal que permita que sea explicada a distintos tipos de usuarios.

B) Soportar la evolución de los sistemas. produciendo en sus distintas etapas esquemas

evolutivos, cambio UoD adaptación de esquemas la metodología debe proporcionar la base para una buena

documentación del sistema.

T1 41

Características (deseables) de una metodología de diseño.

C) Facilitar la portabilidad. IEEE: “la facilidad con la que un producto de

programación puede ser transferido de un sistema informático a otro o de un entorno a otro".

esquemas portables, etapas de diseño independientes Fase de Diseño Lógico eStándar (DLS), entre el

modelado conceptual y el diseño lógico específico / físico en el SGBDR concreto que se va a utilizar.

D) Versatilidad respecto a tipos de aplicaciones No orientada a un tipo de aplicaciones concreto, sino que

puede utilizarse en aplicaciones diversas

T1 42

Características (deseables) de una metodología de diseño.

E) Flexibilidad:Independencia de la dimensión de los proyectos tanto en proyectos grandes como pequeños. si bien las líneas metodológicas serán las mismas

otras técnicas (como, por ejemplo, la de integración de vistas)

simplificación de algunas de las etapas

F) RigurosidadSe pretende imprimir un carácter riguroso a los principios

metodológicos propuestos. Siempre que sea posible (como en el caso de la

normalización) nos apoyaremos en sólidos fundamentos teóricos.

un excesivo formalismo puede provocar el rechazo de determinado tipo de usuarios.

T1 43

Características (deseables) de una metodología de diseño.

G) Adoptar estándares Aplicación de todos aquellos que para la ingeniería

del software en general y para las bases de datos en particular, recomiendan distintas organizaciones internacionales (como ISO, ACM, etc).

H) Automatización Aplicando herramientas tipo CASE que soporten todas las

fases propuestas para el diseño de la BD. En nuestro caso, al utilizar modelos, lenguajes y

herramientas muy extendidos (como el ME/R, diagramas de dependencias funcionales, SQL, etc.), la metodología se puede instrumentar con facilidad en los productos CASE existentes.

T1 44

Bibliografía De Miguel, A.; Piattini, M. Concepción y diseño de bases de

datos: Del Modelo E/R al modelo relacional. Madrid, Ra-Ma,

1993.

De Miguel, A.; Piattini, M.; Marcos, E. Diseño de bases de datos

relacionales. Madrid, Ra-Ma, 1999.

Batini, C; Ceri, S; Navathe, S.B. Diseño conceptual de bases de

datos: Un enfoque de entidades-interrelaciones. Wilmington,

Addison Wesley / Díaz de Santos,1994.

Elmasri, R.; Navathe, S.B. Sistemas de bases de datos:

conceptos fundamentales. 2ª ed. Wilmington, Addison Wesley,

1997.

Elmasri, R.; Navathe, S.B. Fundamentos de sistemas de bases

de datos. 3ª ed. Madrid, Pearson Educación, 2002.