Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Diseño físico y rendimiento de la bd2

916 views

Published on

Published in: Design
  • Be the first to comment

  • Be the first to like this

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>

×