1. UNIDAD 3 Diseño y Creación de Base de Datos

2. Introducción La creación de una base de datos tiene tres fases: 1. Diseño del modelo conceptual o entidad relación, que consiste en la determinación de los aspectos de interés de una organización y como esos aspectos se relacionan. Estos aspectos de interés se les conoce como entidades, y de cada uno de éstos se deben identificar atributos o características que deben ser almacenadas. El modelo conceptual se representa con el diagrama entidad relación de la base de datos.

3. Introducción 2. Diseño del modelo lógico consiste en transformar el diagrama entidad relación a tablas mediante un conjunto de reglas preestablecidas. En otras palabras, es el proceso de transformar desde el modelo entidad relación, en donde la información se representa con entidades y sus relaciones, al modelo relacional en donde la información se representa en tablas. Esto se hace porque el modelo conceptual no tiene una implementación a nivel de estructuras de datos, pero si lo tiene el modelo relacional (tablas). En esta fase también se elimina la redundancia en las tablas a través de un proceso conocido como normalización. 3. Diseño del modelo físico, consiste en la creación de la base de datos en un computador utilizando un SGBD, para lo cual se crea el Script (instrucciones en SQL) para la creación de la base de datos, cada tabla con sus atributos, restricciones e integridad o constraints como: notnull, default, unique, claves primarias, checks, integridad referencial y triggers. Otros objetos útiles para la gestión, seguridad y rendimiento de la Base de datos como: vistas, procedimientos almacenados, índices, grupos de usuarios, permisos, etc. Finalizando esta fase, la base de datos queda lista para su utilización.

4. De Modelo Lógico a Base de Datos Físico Para realizar esta transformación se debe conocer aspectos sobre el DBMS como: Los objetos de Base de Datos soportados y los archivos requeridos. Detalles de: índices soportados, integridad referencial, constraints, tipos de datos, etc. , como de las diferentes funcionalidades del DBMS. Detalles de las nuevas y viejas versiones. Parámetros de configuración. Experiencia en el Lenguaje de definición de datos (DDL) para traducir el diseño físico a objetos de la base de datos.

5. Transformación de Entidades a Tablas Se puede variar el mapeo de entidades a tablas a través de la desnormalización para aumentar el rendimiento y la disponibilidad.

6. Transformación de Dominios a Tipos de Datos Además de definir un tipo de dato y longitud, también es necesario de aplicar un constrainta dicha columna. Es preferible usar compresión, que implementar columnas de longitud variable, la ventaja mas importante de la compresión de datos es que el código resultante tiende a ser de menor tamaño que el original.

8. Columnas no actualizables de tipo variable

9. Columnas frecuentemente actualizablesEsto es para hacer mas livianos los registros de los archivos log.

10. Integridad Referencial Una clave foránea es cuando la clave primaria de una tabla se coloca como atributo de otra tabla, para relacionarlas. La integridad referencial garantiza que los valores que se insertan en la columna clave foránea sean validados previamente en la tabla donde es clave primaria. Si un valor de clave foránea no está insertado previamente en la columna donde es clave primaria, no será admitido por el sistema.

11. Construya Estructuras de Datos Físicas Se debe mapear cada tabla a un archivo según su uso.

12. Construya Estructuras de Datos Físicas Calcular el tamaño de cada tabla. Para calcular el almacenamiento necesario para una tabla se debe determinar el tamaño en bytes de cada fila, sumando los tamaños de cada columna, luego, se debe determinar el número esperado de filas que tendrá la tabla, el producto de tamaño de filas x número de filas es el tamaño de la tabla. Se debe reservar un espacio adicional tomando en cuenta que se tienen punteros que enlazan a las filas, y las cabeceras de los bloques de datos, que almacenan información de control. El espacio adicional para punteros y cabeceras depende de cada SGBD.Hay que reservar espacio de almacenamiento para los índices y para inserciones adicionales en las tablas.Se debe usar compresión en el almacenamiento porque ahorra espacio en disco y hace mas eficiente la Entrada Salida.

13. Diseño y Desempeño de la Base de Datos Existen varias técnicas para mejorar el acceso a los datos. Diseño de Índices Un índice es una ruta de acceso alternativa a los datos. La estructura de un índice hace fácil encontrar datos en la base de datos, con menos operaciones de E / S. El DBMS decide cuando usar un índice.

15. Cuando el resultado de las consultas tiene menos del 25% del total de las filas de una tabla.

16. En las claves foráneas, para mejorar el rendimiento de las junturas y el chequeo de integridad referencial.

17. En la claves primarias, para reforzar la unicidad de los datos.

18. En las claves candidatas, si se hacen búsquedas por esas columnas.

19. Si se agregan columnas adicionales a un índice, se puede satisfacer consultas solo accediendo al índice.

21. Por una clave foránea, cuando ésta representa la parte “muchos” de una cardinalidad uno a muchos y se necesita recuperar los datos por la clave foránea.

23. Desnormalización Normalización es ubicar cada hecho en el lugar más apropiado, para minimizar la redundancia de datos y los problemas de integridad. La integridad mejora los procesos de actualización de datos, porque solo se actualiza una vez cada dato, pero puede afectar al rendimiento de las consultas, porque para recuperar un dato a veces debemos enlazar varias tablas, y eso es un proceso costoso.La desnormalización es un proceso en el que deliberadamente se crea redundancia para que un mismo dato esté disponible en varios sitios de la base de datos, para aligerar las consultas de dicho dato. CUANDO DESNORMALIZAR Nunca se debe desnormalizar, a menos que se tenga problemas severos de rendimiento en las consultas, a su conocimiento de cómo la SGBD trabaja, le asegure que los beneficios de la desnormalización superan a los beneficios de tener una base de datos normalizada.

24. Desnormalización Siempre se debe considerar los siguientes aspectos antes de la desnormalización. • ¿El sistema puede alcanzar un rendimiento aceptable sin desnormalización? . • ¿El rendimiento del sistema después de la desnormalización todavía es inaceptable? . • ¿El sistema se volverá menos confiable luego de la desnormalización? .

25. Desnormalización En el diseño y el funcionamiento se recomienda mantener tablas normalizadas y desnormalizadas para que las tablas desnormalizadas solo sean de lectura y mejore así el rendimiento de la Base de Datos. Se debe usar triggers para sincronizar datos redundantes en actualizaciones. Estas situaciones no siempre requieren desnormalización, pero son recomendaciones de cuando la desnormalización puede ser considerada, siempre que hayan problemas de rendimiento.

27. Cuando consultas que necesitan cálculos entre varias columnas, requieren almacenar cálculos.

28. Las tablas deben ser accesibles en diferentes maneras, por diferentes usuarios, durante el mismo período.

29. Cuando una clave primaria es muy extensa.

31. Contienen sólo las columnas que sea absolutamente necesarias para satisfacer las necesidades de la aplicación.

32. Sea genera periódicamente, utilizando SQL para juntar las tablas normalizadas El beneficio de la prejuntura es que se ahorra el costo de la combinación, ya que se efectúa una sola vez.

34. Tener sus filas físicamente en la secuencia en que deben aparecer en el informe para que el ordenamiento no es necesario.

36. Desnormalización Dividir tablas (fragmentación) Si diferentes partes de una tabla son accedidos por diferentes usuarios, se puede dividir la tabla en dos o más partes, para que cada grupo de usuarios acceda solo a la parte que le interesa. La tabla original también puede ser mantenida, si otras aplicaciones utilizan toda la tabla. Este mecanismo mejora el rendimiento de las consultas ya que cada parte de la tabla se puede ubicar en un servidor físicamente cercano de los usuarios que la necesitan, disminuyendo el tráfico de red y permitiendo que una misma tabla sea accedida en paralelo por varios usuarios.

37. Desnormalización Fragmentación vertical Separa las columnas de una tabla en dos tablas, manteniendo en las dos a la clave primaria de la tabla original y se debe generar integridad referencial entre las dos y la tabla original. No eliminar filas de ninguna de las tablas fragmentadas en forma aislada. Si se conserva a la tabla original y las particiones son tablas solo de lectura, no es necesario generar integridad referencial.

38. Desnormalización Fragmentación horizontal Divide a una tabla en dos o mas tablas, ubicando a las filas en cada tabla resultante, en base a un criterio de selección. Por ejemplo, si se tiene una tabla Estudiante, en la que están todos los estudiantes de la Universidad, se puede dividir para que en cada fragmento queden estudiantes de una sola facultad. Se puede también mantener a la tabla original, para procesos que así lo requieren, pero siempre manteniendo sicronizados los datos con cada fragmento.

39. Desnormalización Tablas combinadas Si hay tablas con una relación uno a uno, considere la posibilidad de combinarlas en una sola tabla. Por supuesto, si cada participante en la relación uno-a-uno tiene diferentes relaciones con otras tablas, tendrá que tomar eso en cuenta a la hora desnormalización. A veces, incluso las relaciones uno-a-muchos se pueden combinar en una sola tabla, pero el proceso de actualización de datos será considerablemente complicado debido al aumento en los datos redundantes.

40. Desnormalización Datos Redundantes Algunas veces los datos de una o más columnas de una tabla son accedidas casi todo el tiempo en una consulta de otra tabla. En estos casos, considere añadir las columnas a la tabla de consulta como datos redundantes. Mediante la realización de estas columnas adicionales, las junturas pueden ser eliminadas y así mejorar el rendimiento. Esto se debe intentar sólo si el acceso a los datos, se ejecuta con rendimiento insuficiente.

41. Desnormalización Grupos de datos repetidos El proceso de normalización transforma grupos de datos repetidos en filas distintas, en lugar de ubicar esos datos en columnas separadas en la misma fila. Aunque la normalización de grupos de datos repetidos optimiza la integridad de los datos y el rendimiento de actualización, por lo general los procesos de consultas producen mas accesos adisco y son menos eficientes. Esto sucede porque hay más filas en la tabla y más filas deben ser leídos con el fin de satisfacer las consultas.

42. Desnormalización Ejemplo de grupos de datos repetidos. Tabla normalizada: CREATE TABLE CUST_BALANCE (CustNum INTEGER NOT NULL, BalancePeriod INTEGER NOT NULL, Balance DECIMAL(15,2), constraint PKCB PRIMARY KEY (CustNum, BalancePeriod)) Ventajas: puedealmacenar un infinito número de saldos (Balance) por cliente. Desventajas: para obtener 6 saldos de un cliente se deben acceder a 6 filas distintas.

43. Desnormalización Ejemplo de grupos de datos repetidos. Tabla normalizada: CREATE TABLE CUST_BALANCE (CustNum INTEGER NOT NULL, Period1_Balance DECIMAL(15,2), Period2_Balance DECIMAL(15,2), Period3_Balance DECIMAL(15,2), Period4_Balance DECIMAL(15,2), Period5_Balance DECIMAL(15,2), Period6_Balance DECIMAL(15,2), constraint PKCB PRIMARY KEY (CustNum)) Ventajas: para obtener 6 saldos de un cliente se debe acceder a 1 sola filas. Desventajas: solo puede almacenar hasta 6 saldos por cliente.

44. Desnormalización Datos derivados o calculados Son aquellos cuyo valor depende de los valores de otras columnas, y se los obtiene con un proceso de cálculo matemático. Si el costo de obtener datos mediante fórmulas complicadas es prohibitivo, piensa en almacenar físicamente los datos calculados en una columna en lugar de calcularlo cada vez que se lo necesita.

46. El costo de realizar el cálculo del valor derivado es bastante alto.