Es un proceso sistemtico a travs del cul se disea la BD completa Hay varias metodologas implcitas a Herramientas de diseo (como Designer

2000 de Oracle entre muchas otras) Las BD con ms de 30 tipos de entidad y otras tantas relaciones necesitan disearse cuidadosamente mediante una metodologa. Las BD pueden contener gigabytes de datos y cientos de usuarios. Incluso las hay que funcionan 24 horas al da y 7 das a la semana. En ellas domina el procesamiento de transacciones.

 Forman parte de la mayora de sistemas de informacin Muchas empresas tienen ABD (administrador de BD): supervisa y controla el ciclo de vida de las BD La gestin de las BD es decisiva para la empresa:

Datos: recurso cuya gestin y control es vital para garantizar un trabajo eficaz Se informatizan cada vez ms funciones: esto aumenta el volumen de datos a mantener actualizados El uso de BD se consolida en las empresas La complejidad de datos y aplicaciones crece Muchas empresas reducen personal ofreciendo acceso directo a sus BD (Amazon, Ebay, ...)

Los SBD permiten:

Que varias aplicaciones (programas) utilicen la misma BD Gran rendimiento en proceso de transacciones Accesos ocasionales (directivos, etc.)

Hasta mitad de los 80 se tenda a BD centrales y grandes controladas por un SGBD. La tendencia se ha invertido debido a:

BD personales en PCs gracias a productos similares a SGBD como ACCESS o EXCEL Se puede copiar parte de una BD grande a un PC, trabajar con ella y actualizar despus la BD inicial Se pueden fusionar varias BD en otra mayor SGBD distribuidos y cliente-servidor:
Permiten repartir una BD en varios ordenadores y mejorar el control y el procesamiento local. Acceso remoto como cliente o mediante web.

Se utilizan mucho los diccionarios de datos. Son mini SGBD de metadatos. Almacenan y controlan:

Descripcin de los esquemas de BD Por cada tabla: tipo de fichero, ndices, n de tuplas, tamao de las filas, ... Usuarios de las BD, derechos de acceso ... Descripciones de transacciones y aplicaciones y su relacin con los usuarios Relacin entre transacciones y las tablas, etc. a las que se accede. Para reconocer transacciones afectadas por cambios en definicin de tablas Estadsticas, como frecuencias de consultas y transacciones, o accesos a porciones de BD

[Elmasri/Navathe 02]
1. 2.

Obtencin y anlisis de requisitos (S.I.) Diseo conceptual

3.
4. 5. 6.

Eleccin de un SGBD

Diseo lgico Diseo fsico Implementacin y ajuste del sistema de BD (S.I.)

CONTENIDO Y ESTRUCTURA DE DATOS

APLICACIONES DE LA BASE DE DATOS

Fase 1: Obtencin y
anlisis de requisitos

REQUISITOS DE DATOS DISEO DEL ESQUEMA CONCEPTUAL

REQUISITOS DE PROCESAMIENTO

Fase 2: Diseo
conceptual

DISEO DE TRANSACCIONES Y APLICACIONES

Fase 3: Eleccin
SGBD
frecuencias, restricciones de rendimiento

Fase 4: Diseo lgico

DISEO DEL ESQUEMA LGICO Y DE LAS VISTAS

Fase 5: Diseo fsico

Fase 6: Implementacin y
ajuste del sistema de BD

DISEO DEL ESQUEMA INTERNO

Sentencias DDL Sentencias SDL

IMPLEMENTACIN DE TRANSACCIONES Y APLICACIONES

 Objetivo: conocer y analizar las expectativas de los usuarios Pasos: 1. Identificar: las reas de aplicacin, grupos de usuarios de la BD y personas cuyo trabajo se ver afectado por la BD. Se eligen personas clave y comits para los siguientes pasos. 2. Estudiar documentacin existente: relacionada con las aplicaciones: manuales de poltica de empresa, formularios, informes y diagramas de organizacin. 3. Estudiar el entorno de operacin y cmo se usar la informacin. Incluye descubrir qu tipos de transaccin se necesitan y su frecuencia de uso. Tambin el flujo de informacin en el sistema, la distribucin geogrfica de los usuarios, el origen de las transacciones, el destino de los informes. Se especifican datos y resultados de cada transaccin. 4. Cuestionarios a los usuarios: opcionales. Se pregunta por sus prioridades y la importancia que dan a cada aplicacin. Tambin puede entrevistarse a personas clave para estimar el valor de la informacin y para establecer prioridades. Requisitos iniciales: comprensin de un sistema que an no existe. Pueden ser informales, incompletos, inconsistentes o parcialmente incorrectos. Hay que trabajar hasta conseguir una especificacin

 Participacin de los usuarios en el desarrollo: aumenta su satisfaccin con el producto final Actualmente se usan reuniones y grupos de trabajo que incluyen a todos los implicados. Tambin se tiende a que los diseadores se integren en el lugar de trabajo donde se utilizar la aplicacin. Tcnicas de especificacin de requisitos: anlisis orientado a objetos, diagramas de flujo de datos, ... Usan diagramas para organizar y presentar los requisitos de proceso de informacin. Se pueden complementar con textos, tablas, etc. Tcnicas de especificacin formal: como la notacin y metodologa Z. Apenas se usan en la actualidad, aunque podran estandarizarse. Herramientas automatizadas Upper CASE: ayudan a comprobar la consistencia y completitud de las especificaciones. Fase de obtencin y anlisis de requisitos: puede consumir mucho tiempo. Corregir un error de esta fase es mucho ms caro que corregir uno de implementacin. Si el error no se corrige, el resultado no satisfar a los usuarios, pudiendo incluso no utilizarse.

 Resultados: esquema de BD y diseo de transacciones Esquema conceptual: usa un modelo de datos de alto nivel (como E/R), independiente del SGBD:
Muestra la estructura de la BD, el significado de los datos, las relaciones y restricciones La estructura no debera cambiar. Se completar con decisiones de diseo ms cercanas al SGBD (diseo lgico y fsico) Interesa que el modelo de datos sea: General y expresivo: distinguiendo tipos de datos, relaciones y restricciones De fcil comprensin incluso para usuarios. Mejor grfico, para facilitar su interpretacin. Minimalista (pocos conceptos) y formal (sin ambigedad)

Diseo de transacciones: especificar funcionalidad.

Importante disear pronto las ya conocidas (para que el esquema recoja los datos que precisan). Importante conocer la frecuencia de ejecucin esperada. Regla 80-20: el 80% de la carga se debe al 20% de transacciones (las ms frecuentes) Tcnica: identificar entrada/salida y funcionalidad. Diagramas UML: de transicin de estados, actividades, secuencia y de colaboracin. Tipos de transacciones: de recuperacin (obtienen datos), de actualizacin (modifican la BD) y mixtas.

 Centralizado:

Antes de disear se juntan los requisitos de las aplicaciones y grupos de usuarios en un nico documento. Juntar requisitos puede ser una tarea larga. El ABD decide cmo hacerlo. El problema se ha venido resolviendo mediante consultores/diseadores expertos.

Integracin de vistas:

Se disea un esquema (vista) por aplicacin o grupo de usuarios. Despus se juntan los esquemas para obtener uno global. Este enfoque va ganando aceptacin. Con BD grandes se necesita una metodologa y una herramienta. En la herramienta hay que introducir las correspondencias entre los datos y relaciones. Adems hay que resolver conflictos entre vistas y verificar la consistencia entre esquemas.

 Suelen seguir un enfoque incremental: identificar un esquema bsico e irlo modificando, refinndolo o desarrollndolo. Algunas estrategias son: Descendente: parte de un esquema bsico y lo va refinando sucesivamente. Ejemplo: al aadir atributos a un tipo de entidad se ve que conviene dividirlo en varios tipos de entidad de menor nivel o refinarlo en varias subclases Ascendente: parte de un esquema bsico y se van combinando cosas. Ejemplo: empezar con atributos e irlos agrupando en tipos de entidad o relaciones. Identificar atributos comunes en varios tipos de entidad y agruparlos en una superclase De adentro hacia fuera: caso especial del ascendente. Empieza por los conceptos ms evidentes. Luego se agregan progresivamente los ms relacionados con los ya considerados. Mixta: empieza de manera descendente y se hacen varias particiones del esquema que se disean ascendentemente. Por ltimo se combinan los esquemas obtenidos.

 En integracin de vistas se disea un esquema o vista por aplicacin o grupo de usuarios. Las vistas son ms pequeas y fciles de disear. Al integrarlas en un esquema global se necesita una metodologa que incluye los siguientes pasos: Identificar correspondencias y conflictos: antes de integrarlas, se detectan constructores que aparecen en varias vistas y representan el mismo concepto del mundo real. Hay varios tipos de conflicto: De nombres: varios nombres para el mismo concepto o el mismo para varios conceptos. De tipos: por ejemplo departamento en una vista es un tipo de entidad y en otro un atributo. De dominio: por ejemplo telfono es numrico en un sitio y texto en otro. O se usa $ en un sitio y en otro. Entre restricciones: se indica como clave de un tipo de entidad atributos distintos. O se indica que una asignatura tiene un profesor en un sitio (N:1) y en otro que puede tener varios (M:N). Ajustar vistas: se modifican las vistas para resolver algunos de los conflictos detectados. Fusionar vistas: los conceptos que se corresponden se representan una sola vez en el esquema global. Reestructurar: paso opcional, donde se intentara eliminar redundancias o complejidad innecesaria.

 Escalera binaria: se empieza por dos vistas similares. La vista resultante se integra con la ms similar de las restantes y as sucesivamente. Adecuada para la integracin manual. N-aria: se integran todas las vistas a la vez. Precisa herramientas informticas. Todava no hay herramientas comerciales para ello. Binaria equilibrada: se emparejan todas las vistas y se integran. Los esquemas resultantes se vuelven a emparejar e integrar y as sucesivamente. Mixta: se hacen grupos de vistas similares. Cada grupo se integra por separado. Los esquemas resultantes se vuelven a agrupa por similitud e integrar y as sucesivamente

 Costes econmicos: Compra del SGBD: opciones (lenguajes, herramientas para GUI, respaldo/recuperacin, ...). Tomar versin y plataforma que interesa. Mantenimiento: para la actualizacin de versiones. Renovacin del hardware: puede hacer falta ms memoria, disco, controladores ms rpidos, etc. Conversin de la BD (o creacin): coste difcil de estimar (se subestima). Se pone a funcionar junto al sistema viejo (cuando lo hay) hasta probarlo bien. Nuevo personal: cuando se compra por primera vez un SGBD. Se crea el puesto de ABD, ... Formacin: para el ABD, programadores, etc. Operacin: este coste es independiente del SGBD Factores organizativos: Nueva filosofa: por ejemplo cuando se elige OO frente a relacional. Conocimiento del SGBD: optar por uno desconocido implicar gasto en formacin Asistencia tcnica: al principio se precisa mucha ayuda. Interesa disponer de un buen servicio. Factores tcnicos: modelo de datos (relacional, oo, ...), qu estructuras e ndices tiene, qu interfaces, lenguajes de consulta, herramientas de desarrollo, comunicacin con otros SGBD, sistemas operativos en los que funciona. Tambin qu aplicaciones existen para respaldo, recuperacin, mejora del rendimiento, seguridad y cmo pueden establecerse restricciones de integridad.

 Se transforma el esquema conceptual (por ejemplo E/R) al modelo de datos del SGBD (por ejemplo relacional) obteniendo un esquema tambin llamado conceptual y esquemas externos (vistas). La transformacin se suele plantear en dos etapas: 1. Independiente del SGBD: por ejemplo E/R se transforma en tablas, sin considerar caractersticas disponibles en el SGBD concreto 2. Adaptacin al SGBD: se incluyen restricciones, ndices, etc. disponibles en ese SGBD El resultado es un conjunto de instrucciones en LDD (create table ...). Algunas pueden incluir detalles de diseo fsico (siguiente fase). Las herramientas CASE suelen disponer de opciones para obtener automticamente las instrucciones en LDD

 Objetivo: Estructurar los datos adecuadamente en el almacenamiento (tipos de fichero, ndices, ...) Garantizar un buen rendimiento con las aplicaciones de la BD El SGBD ofrecer ciertos tipos de fichero y caminos de acceso: ndices de varios tipos Tcnicas de direccionamiento calculado Agrupacin de registros relacionados en un bloque Punteros entre registros Criterios para tomar decisiones de diseo fsico: se suelen concretar los lmites superior y medio de cada uno 1. Tiempo de respuesta: el necesario para ejecutar una transaccin. Influyen el tiempo de acceso a la BD, la carga del sistema, la planificacin de tareas en el sistema operativo y retrasos de comunicacin 2. Aprovechamiento de espacio: el que ocupan los ficheros y sus estructuras 3. Productividad de las transacciones: nmero medio de transacciones que se pueden procesar por minuto

 Se estima por cada fichero (tabla): El tamao de los registros (filas) y el nmero de registros (el rendimiento depende de cmo sean) Sus patrones de actualizacin y obtencin de datos (para todas las transacciones en su conjunto) Su crecimiento tanto en el tamao del registro como en el nmero de registros El resultado del diseo fsico es la determinacin inicial del tipo de fichero para cada tabla de la BD y los ndices (u otros caminos de acceso) El ajuste de BD (tunning) contina a lo largo de la existencia de la BD siempre que se descubra algn problema de rendimiento o cambien los requisitos

 La implementacin de la BD suele realizarla el ABD (en combinacin con los diseadores de BD). El ABD ejecuta las instrucciones en LDD y LDA creando tablas vacas. Despus se cargan los datos. Si exista un sistema anterior se necesitarn rutinas de conversin. Acabada la implementacin comienza la fase de operacin. La mayora de SGBD tienen utilidades de supervisin que recogen estadsticas de rendimiento, como nmero de ejecuciones de cada transaccin, actividad de E/S con cada fichero, frecuencia de utilizacin de cada ndice. Si cambian los requisitos o surgen problemas de rendimiento habr que ajustar el diseo de la BD. El ajuste puede suponer aadir o eliminar tablas, cambiar el tipo de fichero a alguna tabla, aadir o eliminar ndices, reescribir transacciones o consultas, etc.

 Conviene usarlas cuando: La complejidad de los datos (relaciones, restricciones) produce muchas alternativas de diseo. La BD consta de cientos de tipos de entidad y relacin. Entonces la metainformacin constituye otra BD. Crece la conviccin de que: Son valiosas, sobre todo cuando el problema abordado tiene cierto tamao. El diseo de esquemas y aplicaciones deben ir de la mano Hay muchas herramientas CASE (Ing. SW asistida por ordenador). Suelen incluir algunos de estos recursos: Diseo grfico de diagramas: como E/R o UML. Representan diseos conceptuales y se almacenan, se pueden modificar, ... Diseo lgico automtico: generando instrucciones LDD para diversos SGBD, que podrn ser modificadas. Normalizacin automtica: las dependencias funcionales (en las que se basa el proceso ms bsico de normalizacin) se introducen en los diseos conceptual y lgico. No suelen generar soluciones alternativas. Diseo fsico: proponen algunos ndices, pero todava es una actividad donde las decisiones las toman personas.

 Caractersticas deseables en una herramienta: Interfaz fcil de usar Que analice automticamente tareas como evaluar diseos alternativos (pros y contras) o identificar restricciones contradictorias (poco desarrollado) Que compare diseos alternativos basndose en reglas heursticas (caractersticas que dan buenos resultados) Buena presentacin de los diagramas: estticamente aceptables, fciles de leer si ocupan varias pginas. No es fcil conseguirlo al generarlos de forma automtica. Verificar que el diseo satisface los requisitos. Para ello se necesita representar los requisitos internamente. Algunas herramientas: ER Studio y DB Artisan (Embarcadero Technologies) Developper 2000 y Designer 2000 (Oracle) System Architect 2001 (Popkin software) Platinum Enterprise Modeling Suite: Erwin, BPWin, Paradigm Plus (Platinum Technology) Powertier (Persistence Inc.) Rational Rose (Rational) RW Metro (Rogue Ware) XCase (Resolution Ltd.) Enterprise Application Suite (Sybase) Visio (MicroSoft)

1. Cules son las seis fases en el diseo de bases de datos? Explique brevemente cada una de ellas. Es siguiendo estas fases cmo vamos a disear nuestra base de datos de manera ptima y as vamos a poder integrar los diferentes grupos de trabajo siguiendo el ciclo de vida de un Sistema de informacin. 2. Qu tipo de funcionalidad sera deseable que tuvieran las herramientas automticas para soportar un diseo ptimo de bases de datos grande? Utilizando las herramientas CASE vamos a acelerar el proceso de diseo de BD, ganando tiempo para lo que verdaderamente importa, que es la funcionalidad de nuestro SI.