Diseño de Bases de Datos Diseño de Bases de Datos

Diseño de Bases de Datos
Profesor: 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
1
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
„
„
T1
11 Febrero
7 Septiembre
2
Temario Teoría (I)
‡
Tema 1. Metodologías de Diseño.
„
‡
Tema 2. Modelo Entidad / Relación.
„
‡
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.
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
3
Temario Teoría (II)
‡
Tema 4. Diseño lógico.
„
‡
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.
„
T1
Etapas de diseño lógico.
Transformación del esquema conceptual al lógico estándar.
Diseño lógico específico.
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.
4
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
5
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
6
Diseño de Bases de Datos
Tema 1.
METODOLOGÍA DE DISEÑO
T1
7
Introducción
‡
Desde 60 Æ desarrollo de tecnología de BD,
marco teórico:
„
‡
en paraleloÆ desarrollo de metodologías+ técnicas
de diseño:
„
„
‡
Fue tarea de expertos, más un arte que una ciencia.
Actualmente considerada una disciplina estable, con sus
propios métodos y técnicas.
Consenso:
„
„
„
T1
teoría relacional de datos, procesamiento y optimización
de consultas, control de concurrencia, gestión de
transacciones y recuperación, ...
descomposición del proceso de diseño en fases,
principales objetivos de cada fase
técnicas para conseguir esos objetivos.
8
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
9
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:
„
„
„
T1
cualquier recurso a disposición de la metodología
modelo de datos, lenguaje de datos, documentación y
reglas.
+ diagramas, grafos, teorías, etc
10
Metodología
‡
Lenguaje de datos:
„
‡
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:
„
‡
resultado de definir una determinada sintaxis sobre un
modelo de datos (p.e. SQL).
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
11
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
12
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
13
Modelo / esquema de datos
T1
14
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
15
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
clasificación
particularización
T1
Ejemplares:
profesor 1,..., profesor n
16
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
‡
„
Agregación de propiedades Æ Clase
‡
„
AREA 1, AREA 2, ... Æ DEPARTAMENTO
Código, nombre, créditos, ... Æ ASIGNATURA
Agregación de propiedades Æ Propiedad
compuesta
‡
Día, Mes, Año Æ Fecha
T1
17
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).
SuperClase:
PERSONA
especialización
generalización
„
„
„
T1
SubClases: PROFESOR,
ESTUDIANTE,...
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
18
las de la correspondiente superclase.
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
19
Combinación de tipos de abstracciones
‡
La clase PERSONA se puede obtener por
„
„
„
T1
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
20
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
21
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
‡
‡
„
Diseño
‡
T1
Estructuras y restricciones
Lenguaje de datos
En el modelo de datos se basa la metodología de diseño
22
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
23
El proceso de Diseño de Bases de Datos
‡
T1
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
24
Fases principales en el Diseño de BD
[Elmasri/Navathe 02]
1.
2.
3.
4.
5.
6.
Obtención y análisis de requisitos (S.I.)
Diseño conceptual
Elección de un SGBD
Diseño lógico
Diseño físico
Implementación y ajuste del sistema de
BD (S.I.)
T1
25
CONTENIDO Y
ESTRUCTURA DE DATOS
Fase 1: Obtención y
análisis de requisitos
Fase 2: Diseño conceptual
REQUISITOS
DE DATOS
REQUISITOS
DE PROCESAMIENTO
DISEÑO DEL
ESQUEMA CONCEPTUAL
DISEÑO DE TRANSACCIONES
Y APLICACIONES
Fase 3: Elección SGBD
Fase 4: Diseño lógico
DISEÑO DEL ESQUEMA
LÓGICO Y DE LAS VISTAS
Fase 5: Diseño físico
DISEÑO DEL
ESQUEMA INTERNO
Fase 6: Implementación y
ajuste del sistema de BD
APLICACIONES DE LA
BASE DE DATOS
Sentencias DDL
Sentencias SDL
frecuencias,
restricciones de
rendimiento
IMPLEMENTACIÓN DE
TRANSACCIONES Y
APLICACIONES
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 (processdriven). (process modeling).
Ingenieros SW y Diseñadores de BD reconocen que
ambas actividades deben efectuarse en
coordinación.
T1
27
Actividades paralelas
‡
Análisis Funcional:
„
„
„
‡
T1
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.
28
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
29
Actividades paralelas
‡
Ambas aproximaciones al diseño de SI deben de considerarse
como complementarias y deben desarrollarse en
paralelo.
„
„
‡
‡
T1
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.
30
Diseño de BD
Tres grandes fases
(comprenden a varias etapas):
Modelado conceptual, diseño
lógico y diseño físico.
Dependencia de:
Modelado Conceptual
Diseño Lógico
Diseño Físico
Clase de
SGBD
NO
SI
SI
SGBD
específico
NO
NO
SI
T1
31
Modelado Conceptual
‡
Propósito:
„
„
„
‡
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:
„
T1
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
lenguaje usado para la descripción del
esquema conceptual.
32
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
33
Enfoque Centralizado
T1
34
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
35
Integración de vistas
T1
36
‡
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
37
Diseño Lógico
‡
‡
independiente del sistema: dependiente del
modelo de datos usado, no tanto del SGBD
específico.
Esquema Lógico:
„
„
‡
Modelo Lógico:
„
„
T1
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.
lenguaje usado para especificar el esquema lógico.
Relacional, Red, Jerárquico, Orientado a Objeto.
38
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
39
Características (deseables) de una metodología de diseño.
‡
A) Claridad y comprensibilidad
„
‡
B) Soportar la evolución de los sistemas.
„
„
T1
Distintas 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.
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.
40
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
41
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) Rigurosidad
Se 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
42
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
43
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.
T1
44