• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Diseño físico y rendimiento de la bd2
 

Diseño físico y rendimiento de la bd2

on

  • 767 views

 

Statistics

Views

Total Views
767
Views on SlideShare
767
Embed Views
0

Actions

Likes
0
Downloads
36
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Introducción a las Bases de Datos 26 de abril de 2011 UPC - Ingeniería de Sistemas

Diseño físico y rendimiento de la bd2 Diseño físico y rendimiento de la bd2 Presentation Transcript

  • Base de Datos Profesor: MSC Luis Serna Jherry
  • Diseño Físico Recomendaciones en el modelo ER Diseño físico de la BD Implementación y Ajuste Optimización del rendimiento
  • Recomendaciones en Modelo ER
    • Denominación adecuada y definición de todas las entidades (tablas) como singulares y no plurales.
    • El nombre de la entidad (tabla) debe ser descriptible por si solo.
    • Denominación única de acuerdo al estándar de todos los atributos (campos) y definición apropiada de los principales, dentro de cada entidad.
    • Frase verbal (única) que denomine cada relación.
    • Asignación adecuada de dominios (validaciones, valores por omisión).
    • Establecimiento de soporte para nulos en campos no PK.
    • Asignación adecuada de integridad referencial.
    • Creación de índices únicos (AK) y no únicos (IE) necesarios.
    • Solución del problema por lo menos en 3FN.
  • Diseño físico de la BD
    • Es el proceso de elegir estructuras de almacenamiento y caminos de acceso específicos para que los ficheros de la BD tengan buen rendimiento con las aplicaciones :
      • Organización de ficheros y caminos de acceso
      • Diversos tipos de indexación
      • Agrupación de registros relacionados en bloques de disco
      • Enlace de registros relacionados mediante apuntadores
      • Técnicas de dispersión
  • Diseño Físico de la BD - Criterios a considerar -
    • Tiempo de respuesta : el que transcurre entre la introducción de una transacción y la obtención de la respuesta
      • Tiempo de acceso a la BD para obtener los elementos de información (bajo el control del DBMS)
      • Carga del sistema, tareas del SO y comunicación
    • Aprovechamiento del espacio : cantidad de espacio que ocupan los ficheros y sus estructuras de acceso (índices)
    • Productividad de las transacciones : número medio de transacciones que la BD puede procesar por minuto
      • Medido en las condiciones pico para el sistema
    • Análisis de consultas y transacciones
    • Para elaborar el diseño físico de la base de datos debemos tener una idea clara del uso que se le va a dar, definiendo a alto nivel las transacciones y consultas que se espera ejecutar en ella.
    Diseño Físico de la BD - Criterios a considerar -
  • Análisis de Consultas y Transacciones
    • Para cada consulta establecer:
    • Las tablas a las que accederá
    • Los atributos sobre los que se especificarán condiciones de selección (WHERE)
    • Los atributos sobre los que se especificarán condiciones de reunión o de enlace de tablas
    • Los atributos cuyos valores se obtendrá en la consulta
    • Los atributos de los incisos b y c son candidatos a constituir índices (estructuras de acceso)
  • Análisis de Consultas y Transacciones
    • Para cada transacción de actualización establecer:
    • Las tablas que actualizará
    • El tipo de operación en cada tabla (insertar, modificar o eliminar)
    • Los campos sobre los que se especificarán condiciones de selección para operaciones de eliminación o modificación
    • Los campos cuyos valores alterará una operación de modificación
    • Los campos del inciso c son candidatos para índices
    • Los campos del inciso d son candidatos a evitar en los índices, ya que su modificación requerirá la actualización de estas estructuras de acceso.
  • Create Index
    • CREATE UNIQUE INDEX index_name
      • ON table_name (column_name)
    • CREATE INDEX index_name
      • ON table_name (column_name1, column_name 2…)
    • CREATE INDEX idx_address_district
      • ON Address (district);
  • Diseño físico de la BD
    • El rendimiento de la BD depende del tamaño y del número de registros que contienen los ficheros:
      • Estimación de estos valores para cada fichero
      • Considerar el crecimiento esperado de cada uno
    • Se debe estimar los patrones de actualización y obtención de datos del fichero para todas las transacciones en conjunto.
      • Considerar la construcción de caminos de acceso primarios e índices secundarios para los atributos con los que se suelen seleccionar los registros.
  • Implementación y Ajuste
    • Creación del esquema de la BD, con los ficheros vacíos
    • Carga de datos (poblado de tablas)
      • Rutinas de conversión para migrar datos desde una versión anterior
    • Implementación de las transacciones
      • Codificación de programas con instrucciones DML incrustadas
      • Prueba de programas
    • Monitoreo del rendimiento en producción:
      • Estadísticas sobre el número de invocaciones a las transacciones o consultas predefinidas
      • Actividades de entrada / salida sobre ficheros
      • Conteo de páginas de ficheros o registros de índices
      • Frecuencia de utilización de los índices
  • Optimización del rendimiento
    • Ajuste de índices
      • Evaluar dinámicamente los requerimientos, que pueden cambiar según época del año, día del mes o de la semana
      • Reorganizar los índices para obtener mejor rendimiento
        • Ciertas consultas pueden tardar mucho en ejecutarse por falta de un índice apropiado
        • Puede haber índices que no se utilicen
        • Puede haber índices que originen trabajo adicional por estar definidos sobre atributos que sufren continuos cambios
  • Optimización del rendimiento
    • Ajuste de consultas
      • Indicadores:
      • Demasiados accesos al disco (por ejemplo una consulta de emparejamiento exacto que recorre una tabla completa)
      • El plan de ejecución de consulta muestra que no se están usando los índices relevantes.
    • =
    • >, <
    • >=, <=
    • LIKE
    • <>
    • Siempre mejor es operar sobre números que sobre cadenas.
    Ajuste de Consultas – Eficiencia de operadores -
  • Ajuste de Consultas - Casos
    • Muchos optimizadores no usan índices en presencia de:
      • Expresiones aritméticas
        • SALARIO/365 > 10.50
      • Comparaciones numéricas de campos de diferente tamaño y precisión
        • ACANT = BCANT donde ACANT es de tipo Integer y BCANT es Smallinteger
      • Comparaciones con NULL
        • FECHA IS NULL
      • Comparaciones de subcadenas
        • APELLIDO LIKE ‘%EZ’
  • Ajuste de Consultas - Casos
    • Los índices podrían no usarse en consultas anidadas que utilizan IN :
    • SELECT NSS FROM EMPLEADO
    • WHERE DNO IN ( SELECT DNUMERO
    • FROM DEPARTAMENTO
    • WHERE NSS_JEFE = ‘3334444’)
    • Puede no utilizar el índice definido sobre DNO en EMPLEADO, mientras que la utilización de DNO = DNUMERO en la cláusula WHERE con una consulta de un solo bloque puede ocasionar que el índice sí se utilice.
  • Ajuste de Consultas - Casos
    • Algunos DISTINCT pueden ser redundantes y podrían evitarse sin modificar el resultado. Un DISTINCT generalmente provoca una operación de clasificación y debe evitarse siempre que sea posible
  • Ajuste de Consultas - Casos
    • El uso innecesario de tablas temporales puede evitarse juntando varias consultas en una sola, a menos que la relación temporal sea necesaria para algún resultado intermedio
  • Ajuste de Consultas - Casos
    • En algunas situaciones en las que se usa consultas correlacionadas son útiles las tablas temporales
      • SELECT NSS
      • FROM EMPLEADO E
      • WHERE SALARIO = SELECT MAX (SALARIO)
      • FROM EMPLEADO AS M
      • WHERE M.DNO = E.DNO)
      • Esto tiene el peligro potencial de buscar en toda la tabla M EMPLEADO interna para cada tupla de E EMPLEADO externa.
  • Ajuste de Consultas - Casos
    • Para hacerlo más eficiente puede descomponerse en dos consultas, la primera de las cuales calcula el salario máximo de cada departamento:
    • SELECT MAX(SALARIO) AS SALARIO_MAYOR, DNO INTO TEMP
    • FROM EMPLEADO
    • GROUP BY DNO;
    •  
    • SELECT NSS
    • FROM EMPLEADO, TEMP
    • WHERE SALARIO = SALARIO_MAYOR AND EMPLEADO.DNO = TEMP.DNO
  • Ajuste de Consultas - Casos
    • De haber varias opciones posibles para la condición de reunión, elegir una que use un índice de agrupación (CLUSTER), y evitar aquellas que contengan comparaciones de cadenas:
      • Aún si el campo NOMBRE fuera una clave candidata tanto en EMPLEADO como en ALUMNO, es mejor usar
      • EMPLEADO.NSS = ALUMNO.NSS
      • como condición de reunión, en lugar de
      • EMPLEADO.NOMBRE = ALUMNO.NOMBRE
      • si NSS tiene un índice de agrupación en una o en ambas tablas.
  • Ajuste de Consultas - Casos
    • En algunos optimizadores de consultas el orden en el que aparecen las tablas en el FROM puede afectar el procesamiento de la reunión.
      • En esos casos debe cambiarse el orden para que procese primero la tabla con menos data, y la más grande se use con el índice correspondiente
  • Ajuste de Consultas - Casos
    • Algunos optimizadores dan peores tiempos con consultas anidadas que con sus equivalentes no anidadas. Hay 4 tipos de consultas anidadas:
      • Subconsultas no correlacionadas con agregados en la consulta interna
      • Subconsultas no correlacionadas sin agregados
      • Subconsultas correlacionadas con agregados en la consulta interna
      • Subconsultas correlacionadas sin agregados
  • Ajuste de Consultas - Casos
    • Este tipo rara vez presenta problemas, porque la consulta interna se evalúa una sola vez
    • En este tipo se puede presentar el problema mostrado en el caso # 2, en el que no se usa el índice sobre DNO en EMPLEADO
      • SELECT NSS FROM EMPLEADO
      • WHERE DNO IN ( SELECT DNUMERO
      • FROM DEPARTAMENTO
      • WHERE NSS_JEFE = ‘3334444’)
      • La transformación de subconsultas correlacionadas puede llevar a que se creen tablas temporales.
  • Ajuste de Consultas - Casos
    • Muchas aplicaciones se basan en vistas que definen los datos de interés para las aplicaciones.
      • A veces estas vistas pueden ser excesivas cuando la consulta puede realizarse directamente sobre la tabla base, en lugar de usar una vista que se ha definido sobre una reunión
  • Ajuste de Consultas - Casos
    • Una consulta con varias condiciones OR puede hacer que no se empleen los índices que existen:
      • SELECT NOMBRE, APELLIDO, SALARIO, EDAD
      • FROM EMPLEADO
      • WHERE EDAD > 45 OR SALARIO < 5000
    • Alternativa:
      • SELECT NOMBRE, APELLIDO, SALARIO, EDAD
      • FROM EMPLEADO
      • WHERE EDAD > 45
      • UNION
      • SELECT NOMBRE, APELLIDO, SALARIO, EDAD
      • FROM EMPLEADO
      • WHERE SALARIO < 5000
    • Puede usar los índices definidos sobre SALARIO y sobre EDAD
  • Ajuste de Consultas - Casos
    • Las condiciones WHERE pueden reescribirse de modo que se utilicen índices por varias columnas:
    • SELECT REGION, TIPO_PROD, MES, VENTAS
    • FROM ESTADISTICA_VENTAS
    • WHERE REGION = 3 AND ((TIPO_PROD BETWEEN 1 AND 3) OR (TIPO_PROD BETWEEN 8 AND 10))
    • Puede usar un índice únicamente sobre REGION y debe buscar a través de todas las páginas hoja del índice un emparejamiento con TIPO_PROD.
    • En cambio:
    • SELECT REGION, TIPO_PROD, MES, VENTAS
    • FROM ESTADISTICA_VENTAS
    • WHERE (REGION = 3 AND (TIPO_PROD BETWEEN 1 AND 3)) OR (REGION = 3 AND (TIPO_PROD BETWEEN 8 AND 10))
    • Puede usar un índice compuesto sobre (REGION, TIPO_PROD) y trabajará mucho más eficientemente.
  • Ajuste del Diseño de la BD
    • Reunir tablas existentes, porque ciertos campos de dos o más tablas se necesitan juntos con frecuencia: pasar de FNBC a 3FN, 2FN ó 1FN (¡¡¡¡¡¡¡)
    • Para un cierto conjunto de tablas, elegir uno de entre varios diseños alternativos en la misma forma normal
    • Fragmentación vertical : una tabla de la forma
    • R( k , a, b, c, d, …)
      • puede reemplazarse por varias tablas como
      • R1( k , a, b), R2( k , c, d) y R3( k , …)
      • (Según la necesidad de acceso conjunto a los campos)
  • Ajuste del Diseño de la BD
    • Fragmentación horizontal : almacenar fragmentos horizontales de una tabla en tablas diferentes. Si se desea acceder a todos los datos la consulta debe combinarlas nuevamente.
    • Repetir uno o más campos de una tabla en otra, aún creando redundancia y anomalías potenciales. En este caso debe haber siempre una tabla principal donde el campo esté correctamente actualizado con absoluta seguridad.
  • RESUMEN
    • El diseño conceptual es una descripción estable , muy expresiva y general del contenido de la BD, que es independiente del DBMS
    • El diseño físico empieza por la elección del DBMS y está fuertemente marcado por éste.
    • El adecuado rendimiento de la BD depende en gran medida de las condiciones de implementación propias de cada instalación: volúmenes de datos, tiempos, carga de trabajo, etc.
    • El punto de partida para conseguir una BD eficiente es, siempre , un adecuado diseño conceptual.