Este documento describe los factores que causan cambios en las bases de datos, como cambios en las aplicaciones, requerimientos de rendimiento y regulaciones. También discute los factores necesarios para una efectiva gestión de cambios, como proactividad, análisis de impacto y automatización. Además, explica los diferentes tipos de cambios que un DBA debe gestionar y las limitaciones del comando ALTER para realizar ciertos cambios.
2. Gestión de Cambios de Base de Datos El cambio es lo único constante en el ambiente de negocios. Por otra parte, los individuos dentro de la empresa por lo general tienen dificultades para hacer frente al cambio. Cambiar por lo general implica funciones y responsabilidades adicionales que, casi inevitablemente, hacen nuestro trabajo más difícil.
7. Para almacenar otros tipos de datos.Los cambiosnuncacesan, poreso, esimperativoque se tengan a mano la solución mas adecuadaparacadatipo de cambio.
8.
9. Inteligencia: examinar las implicaciones de cada cambio antes de realizarlo, planear el cambio buscando la forma más eficiente y menos costosa, y realizar plan de contingencias.
10. Análisis de impacto: un cambiopuedeserrealizado de variasformas, perocada forma impacta de maneradiferentesobre el funcionamiento del sistema.
11.
12. Procesos confiables y predecibles: La fiabilidad y la previsibilidad son factores clave en la producción de un producto de alta calidad.
13. Disponibilidad: hacer los cambios tratando de mantener la disponibilidad de la base de datos y las aplicaciones.
14.
15. Tipos de Cambios DBMS software Los cambios de versiones provocan que el trabajo se lo realice de otras formas, nuevas funciones y opciones se incorporan a la DBMS, y otras desaparecen. El DBA debe crear las políticas y procedimientos apropiados para el uso de estas nuevas opciones. Configuración del hardware El DBMS puede requerir que el hardware se actualice, o cambie su configuración. El DBA debe coordinar con el SA para afinar el hardware a las necesidades de la DBMS.
16. Tipos de Cambios Diseño Lógico y Físico Los cambios en la BD afectan los diseños: conceptual, lógico y físico. Se debe sincronizar los cambios con una herramienta CASE, de tal manera que si se cambia en el modelo físico, el cambio se propague al modelos lógico y al conceptual. Si no hay una herramienta, la sincronización es manual, tediosa y propensa a errores. Aplicaciones Cuando la BD cambia también se debe realizar los cambios necesarios en las aplicaciones que acceden a esa BD. Estos cambios deben ser sincronizados ya que los cambios pueden llegar a inutilizar las aplicaciones que dependan de la BD.
17. Impacto de los Cambios sobre la Estructura de la Base de Datos Necesitamos técnicas infalibles para gestionar los cambios de base de datos. Pero aún más, necesitamos técnicas que no solo sean a prueba de fallos, sino también automatizadas, eficientes y fáciles de usar. Lastimosamente, los DBMS actuales no hacen de la gestión de cambios una tarea fácil.
18. Impacto de los Cambios sobre la Estructura de la Base de Datos Las bases de datos relacionales se crean utilizando Data DefinitionLanguage (DDL). DDL se compone de tres verbos de SQL: CREATE, DROP y ALTER. La sentencia CREATE se utiliza para crear un objeto de base de datos, y la instrucción DROP se utiliza para eliminar un objeto de base de datos. La sentencia ALTER se utiliza para realizar cambios en los objetos de una base de datos, pero su alcance es diferente en cada DBMS .
19. Impacto de los Cambios sobre la Estructura de la Base de Datos Por ejemplo: En algunos DBMS sólo se puede agregar columnas a una tabla existente mediante la instrucción ALTER, al final de la tabla. NOTA: la mayoría de los objetos de base de datos tienen algunos aspectos que no se puede modificar con ALTER.
20. Impacto de los Cambios sobre la Estructura de la Base de Datos Borrado en Cascada Cuando se borra un objeto, también se borran todos sus componentes. Se recomienda respaldar un objeto antes de borrarlo Nota: La figura muestra un esquema jerárquico de objetos, éste puede cambiar según la BD utilizada
21. Impacto de los Cambios sobre la Estructura de la Base de Datos Cuando se borra una tabla también se borran sus columnas, claves, índices, triggers, sinónimos, vistas, información de seguridad y estadísticas. Se puede almacenar la estructura anterior de un objeto antes de modificarlo, recuperando su información desde el catálogo del sistema. Para eso, el DBA debe conocer a fondo el contenido del catálogo y su adecuada gestión. Las aplicaciones deben ser modificadas y revinculadas cuando las BD cambia.
22. Limitaciones del Alter Muchos de los cambios necesario en objetos de una BD no se los puede realizar usando la sentencia SQL ALTER, esto varía entre DBMS y DBMS, y de una versión a otra. Sin embargo, las acciones que comunmente no son soportadas por ALTER son:
23. Limitaciones del Alter • Cambiar el nombre de una Base de Datos.• Traslado de un objeto de base de datos a otra base de datos.• Cambiar el número de tablespaces o archivos de datos. • Traslado de una tabla de un tablespace a otro. • Reorganizar el orden de las columnas de una tabla. • Cambiar el tipo de una columna de datos y la longitud. • Eliminación de las columnas de una tabla. • Cambio de la definición de una clave principal o una clave externa.• Agregar una columna que no acepte nulos a una tabla. • Agregar o quitar columnas de una vista. • Cambio de la instrucción SELECT en la que se basa una vista. • Cambio de las columnas de un índice. • Cambio un índice a único. • Cambiar un índice de no agrupado a agrupado. • Cambio de un índice de ascendente a descendente.• Modificar el contenido de un trigger. • Cambio de una clave hash. Nota: Esto depende de la DBMS y la versión que se este utilizando
24. Limitaciones del Alter Uno de los desafíos que tiene el DBA es el de mantener la BD de prueba sincronizada para aplicaciones que están probándose, para aquello se debe utilizar scripts para setear las BD de alguna manera antes de realizar una prueba, claro que para aquello el DBA puede utilizar varias herramientas disponibles acorde al DBMS que utiliza. Otro desafío es recobrar a la BD de cambios mal hechos y regresar la migración a un punto anterior. Por lo antes expuesto se justifica adquirir una herramienta que gestione los cambios. Claro esto si está al alcance de la empresa, de lo contrario todo ésto pondrá a prueba la habilidad y experiencia del DBA.
30. Escenario para el Cambio de una Base de Datos La sentencia SQL ALTER puede ser utilizada para hacer muchos tipos de cambios en las bases de datos. Sin embargo, otros tipos de cambios pueden requerir medidas adicionales para poner en práctica. Es el trabajo del DBA conocer la mejor manera de llevar a cabo cualquier tipo de cambio de base de datos. Tenga en cuenta que los cambios simples a menudo se vuelven más difíciles en el mundo real. Por ejemplo, un cambio de base de datos simple no es tan simple cuando se van a propagar a varias bases de datos en diferentes servidores en múltiples lugares.
31. Comparando Estructuras de Base de Datos Cuando se trabaja con varios ambientes de Base de Datos, se debe comparar un ambiente con otro. Los cambios que se realizan en el ambiente de desarrollo deben replicarse al ambiente de pruebas, luego debe llevarse esa versión al ambiente de control de calidad, para finalmente ponerle en el ambiente de producción. Las modificaciones realizadas en estos diversos ambientes deben ser trasladados a la base de datos en producción. Se recomienda el uso de herramientas para comparar los cambios en los componentes de las Base de Datos.
32. Comparando Estructuras de Base de Datos Se recomienda que si no se posee una herramienta, guardar los scripts de creación y cambios de la base de datos, en este caso la de pruebas. También se puede recuperar los scripts DDL desde el catálogo. Guardar pistas de todos los cambios realizados, para poder regresar en el caso de que los cambios fallen.
33. Solicitud de Cambios en la Base de Datos El DBA es el custodio de la BD y el usuario de las aplicaciones es el verdadero usuario de las Bases de Datos. El DBA debe implementar procedimientos para que los usuarios soliciten cambios, él debe evaluar las solicitudes de cambio y sus impactos antes de aceptarlas. Los cambios por nuevas aplicaciones deben discutirse entre el DBA y el grupo de Desarrolladores. Una buena práctica para mejorar el proceso de solicitud de cambios es establecer un procedimiento de solicitudes en formularios que deben ser llenados por los usuarios que lo requieren, y deben ser aprobados por el DBA.