Diseño físico y rendimiento de la bd2

894 visualizaciones

Publicado el

Publicado en: Diseño
0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
894
En SlideShare
0
De insertados
0
Número de insertados
2
Acciones
Compartido
0
Descargas
39
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.
  • 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

    1. 1. Base de Datos Profesor: MSC Luis Serna Jherry
    2. 2. Diseño Físico Recomendaciones en el modelo ER Diseño físico de la BD Implementación y Ajuste Optimización del rendimiento
    3. 3. Recomendaciones en Modelo ER <ul><li>Denominación adecuada y definición de todas las entidades (tablas) como singulares y no plurales. </li></ul><ul><li>El nombre de la entidad (tabla) debe ser descriptible por si solo. </li></ul><ul><li>Denominación única de acuerdo al estándar de todos los atributos (campos) y definición apropiada de los principales, dentro de cada entidad. </li></ul><ul><li>Frase verbal (única) que denomine cada relación. </li></ul><ul><li>Asignación adecuada de dominios (validaciones, valores por omisión). </li></ul><ul><li>Establecimiento de soporte para nulos en campos no PK. </li></ul><ul><li>Asignación adecuada de integridad referencial. </li></ul><ul><li>Creación de índices únicos (AK) y no únicos (IE) necesarios. </li></ul><ul><li>Solución del problema por lo menos en 3FN. </li></ul>
    4. 4. Diseño físico de la BD <ul><li>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 : </li></ul><ul><ul><li>Organización de ficheros y caminos de acceso </li></ul></ul><ul><ul><li>Diversos tipos de indexación </li></ul></ul><ul><ul><li>Agrupación de registros relacionados en bloques de disco </li></ul></ul><ul><ul><li>Enlace de registros relacionados mediante apuntadores </li></ul></ul><ul><ul><li>Técnicas de dispersión </li></ul></ul>
    5. 5. Diseño Físico de la BD - Criterios a considerar - <ul><li>Tiempo de respuesta : el que transcurre entre la introducción de una transacción y la obtención de la respuesta </li></ul><ul><ul><li>Tiempo de acceso a la BD para obtener los elementos de información (bajo el control del DBMS) </li></ul></ul><ul><ul><li>Carga del sistema, tareas del SO y comunicación </li></ul></ul><ul><li>Aprovechamiento del espacio : cantidad de espacio que ocupan los ficheros y sus estructuras de acceso (índices) </li></ul><ul><li>Productividad de las transacciones : número medio de transacciones que la BD puede procesar por minuto </li></ul><ul><ul><li>Medido en las condiciones pico para el sistema </li></ul></ul>
    6. 6. <ul><li>Análisis de consultas y transacciones </li></ul><ul><li>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. </li></ul>Diseño Físico de la BD - Criterios a considerar -
    7. 7. Análisis de Consultas y Transacciones <ul><li>Para cada consulta establecer: </li></ul><ul><li>Las tablas a las que accederá </li></ul><ul><li>Los atributos sobre los que se especificarán condiciones de selección (WHERE) </li></ul><ul><li>Los atributos sobre los que se especificarán condiciones de reunión o de enlace de tablas </li></ul><ul><li>Los atributos cuyos valores se obtendrá en la consulta </li></ul><ul><li>Los atributos de los incisos b y c son candidatos a constituir índices (estructuras de acceso) </li></ul>
    8. 8. Análisis de Consultas y Transacciones <ul><li>Para cada transacción de actualización establecer: </li></ul><ul><li>Las tablas que actualizará </li></ul><ul><li>El tipo de operación en cada tabla (insertar, modificar o eliminar) </li></ul><ul><li>Los campos sobre los que se especificarán condiciones de selección para operaciones de eliminación o modificación </li></ul><ul><li>Los campos cuyos valores alterará una operación de modificación </li></ul><ul><li>Los campos del inciso c son candidatos para índices </li></ul><ul><li>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. </li></ul>
    9. 9. Create Index <ul><li>CREATE UNIQUE INDEX index_name </li></ul><ul><ul><li>ON table_name (column_name) </li></ul></ul><ul><li>CREATE INDEX index_name </li></ul><ul><ul><li>ON table_name (column_name1, column_name 2…) </li></ul></ul><ul><li>CREATE INDEX idx_address_district </li></ul><ul><ul><li>ON Address (district); </li></ul></ul>
    10. 10. Diseño físico de la BD <ul><li>El rendimiento de la BD depende del tamaño y del número de registros que contienen los ficheros: </li></ul><ul><ul><li>Estimación de estos valores para cada fichero </li></ul></ul><ul><ul><li>Considerar el crecimiento esperado de cada uno </li></ul></ul><ul><li>Se debe estimar los patrones de actualización y obtención de datos del fichero para todas las transacciones en conjunto. </li></ul><ul><ul><li>Considerar la construcción de caminos de acceso primarios e índices secundarios para los atributos con los que se suelen seleccionar los registros. </li></ul></ul>
    11. 11. Implementación y Ajuste <ul><li>Creación del esquema de la BD, con los ficheros vacíos </li></ul><ul><li>Carga de datos (poblado de tablas) </li></ul><ul><ul><li>Rutinas de conversión para migrar datos desde una versión anterior </li></ul></ul><ul><li>Implementación de las transacciones </li></ul><ul><ul><li>Codificación de programas con instrucciones DML incrustadas </li></ul></ul><ul><ul><li>Prueba de programas </li></ul></ul><ul><li>Monitoreo del rendimiento en producción: </li></ul><ul><ul><li>Estadísticas sobre el número de invocaciones a las transacciones o consultas predefinidas </li></ul></ul><ul><ul><li>Actividades de entrada / salida sobre ficheros </li></ul></ul><ul><ul><li>Conteo de páginas de ficheros o registros de índices </li></ul></ul><ul><ul><li>Frecuencia de utilización de los índices </li></ul></ul>
    12. 12. Optimización del rendimiento <ul><li>Ajuste de índices </li></ul><ul><ul><li>Evaluar dinámicamente los requerimientos, que pueden cambiar según época del año, día del mes o de la semana </li></ul></ul><ul><ul><li>Reorganizar los índices para obtener mejor rendimiento </li></ul></ul><ul><ul><ul><li>Ciertas consultas pueden tardar mucho en ejecutarse por falta de un índice apropiado </li></ul></ul></ul><ul><ul><ul><li>Puede haber índices que no se utilicen </li></ul></ul></ul><ul><ul><ul><li>Puede haber índices que originen trabajo adicional por estar definidos sobre atributos que sufren continuos cambios </li></ul></ul></ul>
    13. 13. Optimización del rendimiento <ul><li>Ajuste de consultas </li></ul><ul><ul><li>Indicadores: </li></ul></ul><ul><ul><li>Demasiados accesos al disco (por ejemplo una consulta de emparejamiento exacto que recorre una tabla completa) </li></ul></ul><ul><ul><li>El plan de ejecución de consulta muestra que no se están usando los índices relevantes. </li></ul></ul>
    14. 14. <ul><li>= </li></ul><ul><li>>, < </li></ul><ul><li>>=, <= </li></ul><ul><li>LIKE </li></ul><ul><li><> </li></ul><ul><li>Siempre mejor es operar sobre números que sobre cadenas. </li></ul>Ajuste de Consultas – Eficiencia de operadores -
    15. 15. Ajuste de Consultas - Casos <ul><li>Muchos optimizadores no usan índices en presencia de: </li></ul><ul><ul><li>Expresiones aritméticas </li></ul></ul><ul><ul><ul><li>SALARIO/365 > 10.50 </li></ul></ul></ul><ul><ul><li>Comparaciones numéricas de campos de diferente tamaño y precisión </li></ul></ul><ul><ul><ul><li>ACANT = BCANT donde ACANT es de tipo Integer y BCANT es Smallinteger </li></ul></ul></ul><ul><ul><li>Comparaciones con NULL </li></ul></ul><ul><ul><ul><li>FECHA IS NULL </li></ul></ul></ul><ul><ul><li>Comparaciones de subcadenas </li></ul></ul><ul><ul><ul><li>APELLIDO LIKE ‘%EZ’ </li></ul></ul></ul>
    16. 16. Ajuste de Consultas - Casos <ul><li>Los índices podrían no usarse en consultas anidadas que utilizan IN : </li></ul><ul><li>SELECT NSS FROM EMPLEADO </li></ul><ul><li>WHERE DNO IN ( SELECT DNUMERO </li></ul><ul><li>FROM DEPARTAMENTO </li></ul><ul><li>WHERE NSS_JEFE = ‘3334444’) </li></ul><ul><li>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. </li></ul>
    17. 17. Ajuste de Consultas - Casos <ul><li>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 </li></ul>
    18. 18. Ajuste de Consultas - Casos <ul><li>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 </li></ul>
    19. 19. Ajuste de Consultas - Casos <ul><li>En algunas situaciones en las que se usa consultas correlacionadas son útiles las tablas temporales </li></ul><ul><ul><li>SELECT NSS </li></ul></ul><ul><ul><li>FROM EMPLEADO E </li></ul></ul><ul><ul><li>WHERE SALARIO = SELECT MAX (SALARIO) </li></ul></ul><ul><ul><li>FROM EMPLEADO AS M </li></ul></ul><ul><ul><li>WHERE M.DNO = E.DNO) </li></ul></ul><ul><ul><li>Esto tiene el peligro potencial de buscar en toda la tabla M EMPLEADO interna para cada tupla de E EMPLEADO externa. </li></ul></ul>
    20. 20. Ajuste de Consultas - Casos <ul><li>Para hacerlo más eficiente puede descomponerse en dos consultas, la primera de las cuales calcula el salario máximo de cada departamento: </li></ul><ul><li>SELECT MAX(SALARIO) AS SALARIO_MAYOR, DNO INTO TEMP </li></ul><ul><li>FROM EMPLEADO </li></ul><ul><li>GROUP BY DNO; </li></ul><ul><li>  </li></ul><ul><li>SELECT NSS </li></ul><ul><li>FROM EMPLEADO, TEMP </li></ul><ul><li>WHERE SALARIO = SALARIO_MAYOR AND EMPLEADO.DNO = TEMP.DNO </li></ul>
    21. 21. Ajuste de Consultas - Casos <ul><li>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: </li></ul><ul><ul><li>Aún si el campo NOMBRE fuera una clave candidata tanto en EMPLEADO como en ALUMNO, es mejor usar </li></ul></ul><ul><ul><li>EMPLEADO.NSS = ALUMNO.NSS </li></ul></ul><ul><ul><li>como condición de reunión, en lugar de </li></ul></ul><ul><ul><li>EMPLEADO.NOMBRE = ALUMNO.NOMBRE </li></ul></ul><ul><ul><li>si NSS tiene un índice de agrupación en una o en ambas tablas. </li></ul></ul>
    22. 22. Ajuste de Consultas - Casos <ul><li>En algunos optimizadores de consultas el orden en el que aparecen las tablas en el FROM puede afectar el procesamiento de la reunión. </li></ul><ul><ul><li>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 </li></ul></ul>
    23. 23. Ajuste de Consultas - Casos <ul><li>Algunos optimizadores dan peores tiempos con consultas anidadas que con sus equivalentes no anidadas. Hay 4 tipos de consultas anidadas: </li></ul><ul><ul><li>Subconsultas no correlacionadas con agregados en la consulta interna </li></ul></ul><ul><ul><li>Subconsultas no correlacionadas sin agregados </li></ul></ul><ul><ul><li>Subconsultas correlacionadas con agregados en la consulta interna </li></ul></ul><ul><ul><li>Subconsultas correlacionadas sin agregados </li></ul></ul>
    24. 24. Ajuste de Consultas - Casos <ul><li>Este tipo rara vez presenta problemas, porque la consulta interna se evalúa una sola vez </li></ul><ul><li>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 </li></ul><ul><ul><li>SELECT NSS FROM EMPLEADO </li></ul></ul><ul><ul><li>WHERE DNO IN ( SELECT DNUMERO </li></ul></ul><ul><ul><li>FROM DEPARTAMENTO </li></ul></ul><ul><ul><li>WHERE NSS_JEFE = ‘3334444’) </li></ul></ul><ul><ul><li>La transformación de subconsultas correlacionadas puede llevar a que se creen tablas temporales. </li></ul></ul>
    25. 25. Ajuste de Consultas - Casos <ul><li>Muchas aplicaciones se basan en vistas que definen los datos de interés para las aplicaciones. </li></ul><ul><ul><li>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 </li></ul></ul>
    26. 26. Ajuste de Consultas - Casos <ul><li>Una consulta con varias condiciones OR puede hacer que no se empleen los índices que existen: </li></ul><ul><ul><li>SELECT NOMBRE, APELLIDO, SALARIO, EDAD </li></ul></ul><ul><ul><li>FROM EMPLEADO </li></ul></ul><ul><ul><li>WHERE EDAD > 45 OR SALARIO < 5000 </li></ul></ul><ul><li>Alternativa: </li></ul><ul><ul><li>SELECT NOMBRE, APELLIDO, SALARIO, EDAD </li></ul></ul><ul><ul><li>FROM EMPLEADO </li></ul></ul><ul><ul><li>WHERE EDAD > 45 </li></ul></ul><ul><ul><li>UNION </li></ul></ul><ul><ul><li>SELECT NOMBRE, APELLIDO, SALARIO, EDAD </li></ul></ul><ul><ul><li>FROM EMPLEADO </li></ul></ul><ul><ul><li>WHERE SALARIO < 5000 </li></ul></ul><ul><li>Puede usar los índices definidos sobre SALARIO y sobre EDAD </li></ul>
    27. 27. Ajuste de Consultas - Casos <ul><li>Las condiciones WHERE pueden reescribirse de modo que se utilicen índices por varias columnas: </li></ul><ul><li>SELECT REGION, TIPO_PROD, MES, VENTAS </li></ul><ul><li>FROM ESTADISTICA_VENTAS </li></ul><ul><li>WHERE REGION = 3 AND ((TIPO_PROD BETWEEN 1 AND 3) OR (TIPO_PROD BETWEEN 8 AND 10)) </li></ul><ul><li>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. </li></ul><ul><li>En cambio: </li></ul><ul><li>SELECT REGION, TIPO_PROD, MES, VENTAS </li></ul><ul><li>FROM ESTADISTICA_VENTAS </li></ul><ul><li>WHERE (REGION = 3 AND (TIPO_PROD BETWEEN 1 AND 3)) OR (REGION = 3 AND (TIPO_PROD BETWEEN 8 AND 10)) </li></ul><ul><li>Puede usar un índice compuesto sobre (REGION, TIPO_PROD) y trabajará mucho más eficientemente. </li></ul>
    28. 28. Ajuste del Diseño de la BD <ul><li>Reunir tablas existentes, porque ciertos campos de dos o más tablas se necesitan juntos con frecuencia: pasar de FNBC a 3FN, 2FN ó 1FN (¡¡¡¡¡¡¡) </li></ul><ul><li>Para un cierto conjunto de tablas, elegir uno de entre varios diseños alternativos en la misma forma normal </li></ul><ul><li>Fragmentación vertical : una tabla de la forma </li></ul><ul><li>R( k , a, b, c, d, …) </li></ul><ul><ul><li>puede reemplazarse por varias tablas como </li></ul></ul><ul><ul><li>R1( k , a, b), R2( k , c, d) y R3( k , …) </li></ul></ul><ul><ul><li>(Según la necesidad de acceso conjunto a los campos) </li></ul></ul>
    29. 29. Ajuste del Diseño de la BD <ul><li>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. </li></ul><ul><li>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. </li></ul>
    30. 30. RESUMEN <ul><li>El diseño conceptual es una descripción estable , muy expresiva y general del contenido de la BD, que es independiente del DBMS </li></ul><ul><li>El diseño físico empieza por la elección del DBMS y está fuertemente marcado por éste. </li></ul><ul><li>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. </li></ul><ul><li>El punto de partida para conseguir una BD eficiente es, siempre , un adecuado diseño conceptual. </li></ul>

    ×