01.introduccion

1© A. Jaime 2005 DBD Tema 1
Tema1. Introducción.
Diseño y ajuste práctico de bases de datos
(16.1, 16.2 y 16.5) Elmasri/Navathe 2002
• Sistemas de información y sistemas de BD (SBD)
• Análisis, diseño e implementación de BD
–Fase 1: Obtención y análisis de requisitos
–Fase 2: Diseño conceptual
–Fase 3: Elección del SGBD
–Fase 4: Diseño lógico
–Fase 5: Diseño físico
–Fase 6: Implementación y ajuste
• Herramientas de diseño
Metodología de diseño
• Es un proceso sistemático a través del cuál se
diseña la BD completa
• Hay varias metodologías implícitas a herramientas
de diseño (como Designer 2000 de Oracle entre
muchas otras)
• Las BD con más de 30 tipos de entidad y otras
tantas relaciones necesitan diseñarse
cuidadosamente mediante una metodología.
• Las BD pueden contener gigabytes de datos y
cientos de usuarios. Incluso las hay que funcionan
24 horas al día y 7 días a la semana. En ellas
domina el procesamiento de transacciones.
Sistemas de BD (SBD) en la empresa
• Forman parte de la mayoría de sistemas de
información
• Muchas empresas tienen ABD (administrador de
BD): supervisa y controla el ciclo de vida de las BD
• La gestión de las BD es decisiva para la empresa:
– Datos: recurso cuya gestión y control es vital
para garantizar un trabajo eficaz
– Se informatizan cada vez más 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.)
Tendencias en el uso de BD
• Hasta mitad de los 80 se tendía 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 después 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:
• Descripción de los esquemas de BD
• Por cada tabla: tipo de fichero, índices, nº de tuplas,
tamaño de las filas, ...
• Usuarios de las BD, derechos de acceso ...
• Descripciones de transacciones y aplicaciones y su
relación con los usuarios
• Relación entre transacciones y las tablas, etc. a las
que se accede. Para reconocer transacciones
afectadas por cambios en definición de tablas
• Estadísticas, como frecuencias de consultas y
transacciones, o accesos a porciones de BD

Ciclo de vida de un sistema de información
1. Análisis de factibilidad: se analizan las áreas
posibles de aplicación, el coste de recoger y
diseminar la información, la relación coste-
beneficio, la complejidad de los datos y de los
procesos, y la prioridad de cada aplicación.
2. Obtención y análisis de requisitos: los requisitos se
obtienen interactuando con los futuros usuarios. Se
identifican sus necesidades y problemas,
dependencias entre aplicaciones, comunicaciones y
procesos que generan informes.
3. Diseño: de las BD y de los programas que la usan.
4. Implementación: se hacen los programas, se crea y
carga la BD y se prueban las transacciones.
5. Validación y prueba de aceptación: se comprueba
que se satisfacen los requisitos de los usuarios y los
criterios de rendimiento.
6. Despliegue, operación y mantenimiento:
normalmente se da formación a los usuarios. La
operación empieza cuando está disponible y validada
toda la funcionalidad del sistema. Si surgen nuevos
requisitos, se pasa por todas las fases anteriores. En
la fase de operación es importante supervisar el
rendimiento y realizar el mantenimiento del sistema.
Ciclo de vida de un SBD
• Suele formar parte de un sistema de información
• El ciclo de vida del SBD consiste en:
1. Definición del sistema: se concretan sus límites,
usuarios y aplicaciones. También las interfaces
(varios tipos de usuario), tiempos de respuesta
máximos, necesidad de almacenamiento y proceso
2. Análisis y diseño de la BD: análisis de
requisitos de datos. Diseño conceptual, lógico y
físico
3. Implementación de la BD: definición de los
esquemas de BD conceptual (sin detalle de
almacenamiento), externo (vistas) e interno (con
estructuras de almacenamiento). Se crean tablas
vacías y se implementan los programas.
4. Carga o conversión de los datos: la BD se
llena de datos, bien a partir de otros ficheros
existentes o tecleando los datos.
5. Conversión de aplicaciones: si existían
aplicaciones relacionadas, habrá que adaptarlas al
nuevo sistema.
6. Prueba y validación
7. Operación: si funcionaba otro sistema anterior, es
habitual que funcionen los dos por un tiempo.
8. Supervisión y mantenimiento: Tanto los datos
almacenados como los programas pueden necesitar.
cambios y reorganizaciones
Figuraposterior
Diseño de BD
• Incluye el diseño de las estructuras lógica y física
para atender a las necesidades de información de
determinados usuarios y para ciertas aplicaciones
• Objetivos del diseño:
– Satisfacer los requisitos de información
– Estructura de información fácil de entender
– Soportar requisitos de proceso como tiempo de
respuesta y espacio de almacenamiento
• Estos objetivos son difíciles de lograr y medir. Las
ventajas en unos suponen desventajas en otros. Por
ejemplo estructurar de forma fácil de entender suele
implicar peor rendimiento.
• El resultado del diseño es un esquema de BD rígido
que no se podrá modificar fácilmente.
• El diseño de BD y el de programas tienen una
fuerte influencia mutua. Ambos se deben efectuar
en coordinación. Las herramientas actuales de
diseño combinan cada vez más ambos aspectos.
Análisis, diseño e implementación de BD
Requisitos
de datos
Requisitos de
procesamiento
Esquema
conceptual
Esquema
lógico
Vistas
Esquema
interno
Instrucciones
LDD
Instrucciones
LDA
Fase 1: Obtención y
análisis de requisitos
Fase 2: Diseño
conceptual de la BD
Fase 3: Elección
del SGBD
Fase 4: Diseño
lógico
Fase 5: Diseño
físico
Fase 6: Implemen-
tación y ajuste
Diseño de
transacciones
Diseño de
programas
Implementación
de transacciones
Implementación
de programas
Dependen
delSGBD
Programas
de aplicación
Estructura y
contenido de la BD
La figura no muestra gran parte de las interacciones entre estructura
y programas
Tampoco muestra la mayor parte de ciclos de realimentación (líneas
discontinuas)

Fase 1: obtención y análisis de requisitos
• Objetivo: conocer y analizar las expectativas de los
usuarios
• Pasos:
1. Identificar: las áreas de aplicación, grupos de
usuarios de la BD y personas cuyo trabajo se verá
afectado por la BD. Se eligen personas clave y
comités para los siguientes pasos.
2. Estudiar documentación existente: relacionada con
las aplicaciones: manuales de política de empresa,
formularios, informes y diagramas de organización.
3. Estudiar el entorno de operación y cómo se usará
la información. Incluye descubrir qué tipos de
transacción se necesitan y su frecuencia de uso.
También el flujo de información en el sistema, la
distribución geográfica de los usuarios, el origen de
las transacciones, el destino de los informes. Se
especifican datos y resultados de cada transacción.
4. Cuestionarios a los usuarios: opcionales. Se
pregunta por sus prioridades y la importancia que dan
a cada aplicación. También puede entrevistarse a
personas clave para estimar el valor de la información
y para establecer prioridades.
• Requisitos iniciales: comprensión de un sistema que
aún no existe. Pueden ser informales, incompletos,
inconsistentes o parcialmente incorrectos. Hay que
trabajar hasta conseguir una especificación.
Fase 1: obtención y análisis de requisitos (2)
• Participación de los usuarios en el desarrollo:
aumenta su satisfacción con el producto final
• Actualmente se usan reuniones y grupos de trabajo
que incluyen a todos los implicados. También se
tiende a que los diseñadores se integren en el lugar
de trabajo donde se utilizará la aplicación.
• Técnicas de especificación de requisitos: análisis
orientado a objetos, diagramas de flujo de datos, ...
Usan diagramas para organizar y presentar los
requisitos de proceso de información. Se pueden
complementar con textos, tablas, etc.
• Técnicas de especificación formal: como la
notación y metodología Z. Apenas se usan en la
actualidad, aunque podrían estandarizarse.
• Herramientas automatizadas Upper CASE:
ayudan a comprobar la consistencia y completitud
de las especificaciones.
• Fase de obtención y análisis de requisitos: puede
consumir mucho tiempo. Corregir un error de esta
fase es mucho más caro que corregir uno de
implementación. Si el error no se corrige, el
resultado no satisfará a los usuarios, pudiendo
incluso no utilizarse.
Fase 2: Diseño conceptual
• Resultados: esquema de BD y diseño 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 debería cambiar. Se completará
con decisiones de diseño más cercanas al SGBD
(diseño lógico y físico)
– Interesa que el modelo de datos sea:
• General y expresivo: distinguiendo tipos de datos,
relaciones y restricciones
• De fácil comprensión incluso para usuarios. Mejor
gráfico, para facilitar su interpretación.
• Minimalista (pocos conceptos) y formal (sin
ambigüedad)
• Diseño de transacciones: especificar funcionalidad.
– Importante diseñar pronto las ya conocidas (para
que el esquema recoja los datos que precisan).
– Importante conocer la frecuencia de ejecución
esperada. Regla 80-20: el 80% de la carga se debe
al 20% de transacciones (las más frecuentes)
– Técnica: identificar entrada/salida y funcionalidad.
Diagramas UML: de transición de estados,
actividades, secuencia y de colaboración.
– Tipos de transacciones: de recuperación
(obtienen datos), de actualización (modifican la
BD) y mixtas.
Fase 2: Diseño conceptual: enfoques
• Centralizado:
– Antes de diseñar 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 cómo hacerlo.
– El problema se ha venido resolviendo mediante
consultores/diseñadores expertos.
• Integración de vistas:
– Se diseña un esquema (vista) por aplicación o
grupo de usuarios. Después se juntan los
esquemas para obtener uno global.
– Este enfoque va ganando aceptación. Con BD
grandes se necesita una metodología y una
herramienta (pocas herramientas lo soportan).
– En la herramienta hay que introducir las
correspondencias entre los datos y relaciones.
Además hay que resolver conflictos entre vistas
y verificar la consistencia entre esquemas.

Fase 2: Diseño conceptual: estrategias
• Suelen seguir un enfoque incremental: identificar
un esquema básico e irlo modificando, refinándolo
o desarrollándolo.
• Algunas estrategias son:
– Descendente: parte de un esquema básico y lo
va refinando sucesivamente.
Ejemplo: al añadir atributos a un tipo de entidad se ve que
conviene dividirlo en varios tipos de entidad de menor nivel
o refinarlo en varias subclases (1)
– Ascendente: parte de un esquema básico 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 (1)
– De adentro hacia fuera: caso especial del
ascendente. Empieza por los conceptos más
evidentes. Luego se agregan progresivamente
los más relacionados con los ya considerados.
– Mixta: empieza de manera descendente y se
hacen varias particiones del esquema que se
diseñan ascendentemente. Por último se
combinan los esquemas obtenidos.
_________
(1) Estos conceptos se estudian en los temas 2 y 3
Enfoque de integración de vistas: Pasos
• En integración de vistas se diseña un esquema o vista por
aplicación o grupo de usuarios. Las vistas son más
pequeñas y fáciles de diseñar.
• Al integrarlas en un esquema global se necesita una
metodología 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 teléfono es numérico
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 intentaría
eliminar redundancias o complejidad innecesaria.
Enfoque de integración de vistas: Estrategias
• Escalera binaria: se empieza por dos
vistas similares. La vista resultante se
integra con la más similar de las
restantes y así sucesivamente.
Adecuada para la integración manual.
• N-aria: se integran todas las vistas a la
vez. Precisa herramientas informáticas.
Todavía 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.
V1 V2
V3
V4
Vi1
Vi2
Esq
V1 V2 V3 V4
Esq
V1 V2 V3 V4
Vi1 Vi2
Esq
V1 V2 V3 V4
Vi1 Vi2
Esq
V5
Vi.
...
Fase 3: Elección del SGBD
• Costes económicos:
– Compra del SGBD: opciones (lenguajes, herramientas
para GUI, respaldo/recuperación, ...). Tomar versión y
plataforma que interesa.
– Mantenimiento: para la actualización de versiones.
– Renovación del hardware: puede hacer falta más
memoria, disco, controladores más rápidos, etc.
– Conversión de la BD (o creación): coste difícil 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, ...
– Formación: para el ABD, programadores, etc.
– Operación: este coste es independiente del SGBD
• Factores organizativos:
– Nueva filosofía: por ejemplo cuando se elige OO frente
a relacional.
– Conocimiento del SGBD: optar por uno desconocido
implicará gasto en formación
– Asistencia técnica: al principio se precisa mucha ayuda.
Interesa disponer de un buen servicio.
• Factores técnicos: modelo de datos (relacional, oo, ...), qué
estructuras e índices tiene, qué interfaces, lenguajes de
consulta, herramientas de desarrollo, comunicación con
otros SGBD, sistemas operativos en los que funciona.
También qué aplicaciones existen para respaldo,
recuperación, mejora del rendimiento, seguridad y cómo
pueden establecerse restricciones de integridad

Fase 4: Diseño lógico
(Transformación al modelo de datos)
• Se transforma el esquema conceptual (por ejemplo
E/R) al modelo de datos del SGBD (por ejemplo
relacional) obteniendo un esquema también
llamado conceptual y esquemas externos (vistas).
• La transformación se suele plantear en dos etapas:
1. Independiente del SGBD: por ejemplo E/R se
transforma en tablas, sin considerar
características disponibles en el SGBD
concreto
2. Adaptación 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 diseño físico (siguiente fase).
• Las herramientas CASE suelen disponer de
opciones para obtener automáticamente las
instrucciones en LDD
Fase 5: diseño físico
• 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
– Técnicas de direccionamiento calculado
– Agrupación de registros relacionados en un bloque
– Punteros entre registros
• Criterios para tomar decisiones de diseño físico: se
suelen concretar los límites superior y medio de cada uno
1. Tiempo de respuesta: el necesario para ejecutar una
transacción. Influyen el tiempo de acceso a la BD, la
carga del sistema, la planificación de tareas en el
sistema operativo y retrasos de comunicación
2. Aprovechamiento de espacio: el que ocupan los
ficheros y sus estructuras
3. Productividad de las transacciones: número medio
de transacciones que se pueden procesar por minuto
Fase 5: diseño físico (2)
• Se estima por cada fichero (tabla):
– El tamaño de los registros (filas) y el número de
registros (el rendimiento depende de cómo sean)
– Sus patrones de actualización y obtención de datos
(para todas las transacciones en su conjunto)
– Su crecimiento tanto en el tamaño del registro
como en el número de registros
• El resultado del diseño físico es la determinación
inicial del tipo de fichero para cada tabla de la BD y
los índices (u otros caminos de acceso)
• El ajuste de BD (tunning) continúa a lo largo de la
existencia de la BD siempre que se descubra algún
problema de rendimiento o cambien los requisitos
Fase 6: Implementación y ajuste del SBD
• La implementación de la BD suele realizarla el
ABD (en combinación con los diseñadores de BD).
• El ABD ejecuta las instrucciones en LDD y LDA
creando tablas vacías.
• Después se cargan los datos. Si existía un sistema
anterior se necesitarán rutinas de conversión.
• Acabada la implementación comienza la fase de
operación.
• La mayoría de SGBD tienen utilidades de
supervisión que recogen estadísticas de
rendimiento, como número de ejecuciones de cada
transacción, actividad de E/S con cada fichero,
frecuencia de utilización de cada índice.
• Si cambian los requisitos o surgen problemas de
rendimiento habrá que ajustar el diseño de la BD.
• El ajuste puede suponer añadir o eliminar tablas,
cambiar el tipo de fichero a alguna tabla, añadir o
eliminar índices, reescribir transacciones o
consultas, etc.

Herramientas de diseño
• Conviene usarlas cuando:
– La complejidad de los datos (relaciones, restricciones)
produce muchas alternativas de diseño.
– La BD consta de cientos de tipos de entidad y relación.
Entonces la meta-información constituye otra BD.
• Crece la convicción de que:
– Son valiosas, sobre todo cuando el problema abordado
tiene cierto tamaño.
– El diseño de esquemas y aplicaciones deben ir de la
mano
• Hay muchas herramientas CASE (Ing. SW asistida por
ordenador). Suelen incluir algunos de estos recursos:
– Diseño gráfico de diagramas: como E/R o UML.
Representan diseños conceptuales y se almacenan, se
pueden modificar, ...
– Diseño lógico automático: generando instrucciones
LDD para diversos SGBD, que podrán ser modificadas.
– Normalización automática: las dependencias
funcionales (en las que se basa el proceso más básico de
normalización) se introducen en los diseños conceptual y
lógico. No suelen generar soluciones alternativas.
– Diseño físico: proponen algunos índices, pero todavía es
una actividad donde las decisiones las toman personas.
Herramientas de diseño (2)
• Características deseables en una herramienta:
– Interfaz fácil de usar
– Que analice automáticamente tareas como evaluar
diseños alternativos (pros y contras) o identificar
restricciones contradictorias (poco desarrollado)
– Que compare diseños alternativos basándose en
reglas heurísticas (características que dan buenos
resultados)
– Buena presentación de los diagramas: estéticamente
aceptables, fáciles de leer si ocupan varias páginas.
No es fácil conseguirlo al generarlos de forma
automática.
– Verificar que el diseño 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)

01.introduccion

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (11)

Similar a 01.introduccion

Similar a 01.introduccion (20)

Último

Último (18)

01.introduccion