Novena sesión diseño físico

383 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
383
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Novena sesión diseño físico

  1. 1. Diseño Físico Base de DatosLic. César Alcántara Loayza
  2. 2. Tópicos Diseño Físico Indice Clustering Particionamiento Creación de Base de datos Errores de DiseñoCAL/Modelo Relacional
  3. 3. Diseño Físico - Rendimiento  ¿Donde almacena la data de una base de datos? El medio es el disco duro; existen diversos fabricantes y características de los discos duros.  Para manejar los datos sobre el disco duro el sistema operativo divide el disco en bloques, cada bloque puede guardar cierta cantidad de información.CAL/Modelo Relacional
  4. 4. Diseño Físico  La información se puede grabar en bloques contiguos de haber espacio.  Si no existe espacio en bloques contiguos, la información puede usar otros bloques libres.CAL/Modelo Relacional
  5. 5. Diseño Físico  La mayoría de RDBMS son capacez de manejar el almacenamiento de datos sobre un disco duro. Revisamo las técnicas para mejorar el rendimiento de la base de datos:  Indices  Clustering  ParticionamientoCAL/Modelo Relacional
  6. 6. RDBMS  No existe una formula mágica para maximizar el rendimiento de la base de datos:  Cada base de datos es diferente. La decisión de que tablas combinar dependen frecuentemente de las tablas y las necesidades de la organización.  Las necesidades de la organización pueden cambiar  cambio en el diseño físico.CAL/Modelo Relacional
  7. 7. RBDMS  Cada RDBMS maneja los joins y búsquedas de forma distinta. Hay que revisar los internals de cada RDBMS para aprovechar al maximo sus capacidades.CAL/Modelo Relacional
  8. 8. Indices  Cada vez que se agregan filas a una tabla, el RDBMS escribe el registro en una pagina donde encuentre espacio, muy probablemente al final de la tabla, sin fijarse en el valor de los datos; si leemos la tabla esta se mostrará en el orden cronológico de grabación. Si deseamos recuperar los datos en ordenado por otro campo el RDBMS deberá leer toda la tabla y luego clasificarla.CAL/Modelo Relacional
  9. 9. Indices  Las busquedas de este tipo consumen recursos valiosos (memoria, I/O hacia el disco duro), lo que resulta en pobre rendimiento, es decir lentitud.  En vez de forzar a que el RDBMS lea toda la tabla y la clasifique podemos crear índices por los campos que deseemos sea la consulta.CAL/Modelo Relacional
  10. 10. Indices  Los indices son estructuras que permiten un acceso mas rápido a los datos en un orden determinado. Es semejante a los indices de los libros, son estructuras que sirven para ubicar mas rápidamente la información que buscamos.CAL/Modelo Relacional
  11. 11. Indices  En vez de buscar la tabla, el RDBMS buscará el indice. ORDEN INDICE NumOr FeOr NumArt Cos Rec NumArt NumOrd d d 101 104 101 01/01 105 8.5 Si 105 101 102 01/01 127 12.90 Si 108 103 103 01/11 108 13.9 No 127 102, 302 104 01/11 101 12.5 Si ... ... ... ... ... 302 127 12.90 NoCAL/Modelo Relacional
  12. 12. Indices  Si la recuperación por los índices es mas rápida entonces ¿por qué no se crea un índice por cada campo?  La razón está en la operación de escritura, cada vez que se actualiza información tendrá que actualizarse cada indice también, en consecuencia habrá mas lentitud. Establecer un balance.CAL/Modelo Relacional
  13. 13. Indices  Indexar un campo resulta en búsquedas y reuniones mas rápidos pero:  Incrementa el espacio en disco (auqnue ahora la tecnología permite mayores capacidades).  Hace mas lentas las inserciones, borrados y modificaciones.CAL/Modelo Relacional
  14. 14. Indices  Cada RDBMS crea automáticamente un indice por cada llave primaria.  Se pueden obtener mejores resultados creando indices por cada llave foránea, y por aquellos campos que no son llaves pero por los cuales se hacen muchas consultas.CAL/Modelo Relacional
  15. 15. Clustering  El computador almacena la data en bloques, si la información está guardada en pocos bloques contiguos podemos recuperar la información sin examinar mucho el disco, ahorrando tiempo.  Clustering es almacenar los datos relacionados en bloques contiguos de disco.CAL/Modelo Relacional
  16. 16. Clustering  Debido a que las operaciones de reunión son muy frecuentes, usar clustering para registros relacionados en la reunión puede mejorar el rendimiento de la base de datos.  Por ejemplo almacenar el cliente con todos sus pedidos, de modo que cuando se lea el cliente también se obtenga sus pedidos.CAL/Modelo Relacional
  17. 17. Clustering  Si bien es cierto que se gana rendimiento usando el clustering de datos también puede ocurrir:  Hacer lentas la operaciones que requieren una exploración completa de la tabla.  Puede ocasionar que la inserción de datos sea mas lenta pues el RDBMS debe buscar el disco por el último registro de la tabla.  Puede incrementar el tiempo necesario para actualizar datos en los campos usados para definir el cluster pues el RDBMS debe determinar cuales registros incluir en el cluster.CAL/Modelo Relacional
  18. 18. Particionamiento  El Clustering dispone registros desde dos o mas tablas juntos en el disco duro para mejorar las reuniones de tablas. Particionar una tabla, de otro lado, parte una única tabla en dos o mas tablas para limitar la cantidad de datos que el RDBMS deba recuperar de una vez.CAL/Modelo Relacional
  19. 19. Particionamiento  Existen dos tipos de particionamiento:  Particionamiento horizontal – Parte los registros de una tabla en dos o mas tablas.  Particionamiento vertical – Parte las columnas de la tabla en dos o mas tablas.CAL/Modelo Relacional
  20. 20. Particionamiento Horizontal ARTICULO Bloque 1 ArtID Titulo DistID Preci GrEdad o 101 Cuentos 102 14.90 13 102 Novelas 101 13.90 9 103 Poemas 102 9.90 13 ARTICULO ArtID Titulo DistID Preci GrEdad o 104 Deportes 102 12.90 11 105 Cocina 102 13.90 13 106 Historia 101 14.90 11CAL/Modelo Relacional Bloque 2
  21. 21. Particionamiento Horizontal  Se podría considerar el particionamiento horizontal cuando una tabla crece mucho de modo que las busquedas y reuniones tengan un tiempode respuesta inaceptable. Ejem. Almacer en una tabla las ordenes de hasta tres meses, que son las mas usadas; el resto dejarlas en otra tabla de ordenes.CAL/Modelo Relacional
  22. 22. Particionamiento Horizontal  Partir los registros de la tabla en dos o mas tablas reduce la cantidad de datos que el RDBMS debe trabajar en búsquedas y reuniones. De otro lado cuando se tenga que buscar cada fila en las tablas para hallar por ejemplo todas las ordenes de un distribuidor.  La única manera de saber si el particionamiento mejora el rendimiento es analizar los patrones de uso de los datos.CAL/Modelo Relacional
  23. 23. Particionamiento Vertical  Para reducir el tamaño de la tabla manteniendo las columnas mas comunmente usadas en una tabla en un número pequeño de bloques en el disco duro del computador.CAL/Modelo Relacional
  24. 24. Particionamiento Vertical ARTICULO ArtId titulo DistID  Ejemplo 101 Cuentos 102 102 Novelas 101 103 Poemas 102 ARTICULO ArtId Precio GrEdad 101 12.90 11 102 13.90 13 103 14.90 11CAL/Modelo Relacional
  25. 25. Particionamiento  Tanto el particionamiento horizontal y vertical ofrecen ventajas y desventajas.  Si alguna operación requiere manipular toda la tabla original podría necesitarse una reunión que haga lenta la operación.CAL/Modelo Relacional
  26. 26. SQL Para Crear Base Datos  La cuarta etapa del Ciclo de Vida de la Base de Datos es la Implementación, donde se usa el SQL para crear la base de datos y sus tablas.CAL/Modelo Relacional
  27. 27. SQL Para Crear Base Datos  Cuando se crea una base de datos se crea el contenedor de la tablas y vistas. El nombre tecnico es Esquema.  Create Schema nombre_del_esquemaCAL/Modelo Relacional
  28. 28. SQL Para Crear Base Datos  Las tablas se crean con:  Create Table Nombre_Tabla  (Nombre_Col1 Tipo_Dato  Nombre_Col2 tipo_Dato ....  Primary Key (Nombre_Colx)  Foreign Key (Nombre_ColX))CAL/Modelo Relacional
  29. 29. Catálogo Diccionario  El RDBMS almacena la definición de la base de datos en el Catálogo o diccionario de datos. El diccionario de datos es el corazón del RDBMS, ahí se encuentran todas las definiciones de columnas, tablas, vistas, indices, llaves etc.  El catálogo también almacena tablas para el control del RDBMS.CAL/Modelo Relacional
  30. 30. Errores De Diseño  Los errores comunes de diseño ocurren en cuatro áreas:  Objetos y reglas del negocio  Restricciones, columnas y llaves.  Vínculos e integridad referencial  Problemas internacionales.CAL/Modelo Relacional
  31. 31. Errores De Diseño  Los errores de Objetos y reglas del negocio caen en dos categorias;  Representar mas de una objeto del negocio en una sola tabla.  Incluir muchos objetos o muchos atributos de un objeto en la base de datos.CAL/Modelo Relacional
  32. 32. Errores De Diseño  Implementar reglas del negocio como restricciones es adecuado solo cuando las restricciones:  Ayudan a preservar la integridad de los datos.  No minan el potencial de crecimiento de la compañía (que requiera una revisión de la base de datos).CAL/Modelo Relacional
  33. 33. Errores De Diseño  Los errores comunes asociados con columnas incluyen:  Representar mas de un atributo en una columna.  Duplicar el nombre de la columna en diferentes tablas.  Dar nombre cripticos a las columnas.CAL/Modelo Relacional
  34. 34. Errores De Diseño  Si tiene problemas con una restricción, verifique la restricción cuidadosamente para asegurarse que regleja la regla del negocio y que fue ingresada correctamente.CAL/Modelo Relacional
  35. 35. Errores De Diseño  Errores comunes asociados a las llaves primaria y foránea:  Descuido al identificar llaves primarias.  Almacenar información significativa en una llave primaria.  Descuido al identificar llaves foráneas.CAL/Modelo Relacional
  36. 36. Errores De Diseño  Errores asociados con los vinculos y la integridad referencial:  Crear muchas relaciones  Agregar llaves foráneas innecesarias.  Reforzar integridad referencial no necesaria.CAL/Modelo Relacional
  37. 37. Aspectos Internacionalizacion  Los paises tienen sus propias formas de escribir fechas, simbolos monetarios y direcciones, si su base de datos va ha servir corporaciones multinacionales deberá considerar todos estos aspectos en el diseño de su base de datos.CAL/Modelo Relacional
  38. 38. Errores De Diseño  “Si los usuarios no pueden usar la data de la base de datos para responder sus preguntas, las base de datos no es útil”.CAL/Modelo Relacional
  39. 39. Resumen  Cada tabla debería representar un objeto del negocio que combinada con otras tablas produzca información.  Cada restricción debería ayudar a los usuarios ingresar información correcta.  Se debería reforzar la integridad referencial para asegurar que la tabla permanece consistente.  Las vistas deben combinar los datos en información que los usuarios puedan usar como base para decisiones de negocio.CAL/Modelo Relacional

×