Published 20 years ago
(updated 13 years ago)
Los modeladores de datos son herramientas indispensables para el desarrollo de software. Es importante que conozcamos su funcionalidad, así como las limitaciones que pueden tener. En este artículo, Artemio Mendoza nos narra su experiencia con ERwin Data Modeler de Computer Associates.ERwin es uno de los productos más conocidos para modelado de datos. Su funcionalidad va más allá de simplemente dibujar diagramas, ya que también genera los scripts de creación de la base de datos, permitiendo escoger entre diferentes DBMS destino como Oracle, DB2, Sybase, SQL Server y otros más. También es posible conectarse al DBMS de manera nativa —en el caso de Oracle, utilizando SQL*Net— o por ODBC para generar en línea los objetos y sus relaciones o hacer ingeniería en reversa para obtener el diagrama Entidad Relación (ER) de una base de datos existente. En fin, si observamos el conjunto de servicios que ofrece, podemos entender porqué ERwin goza de tanta popularidad.
Sin embargo, aún con todas sus gracias, si dejamos demasiadas cosas en las manos de ERwin terminaremos con bases de datos altamente ineficientes. ¿Por qué esta afirmación?
Bueno, para justificarla voy a hablar acerca del RDBMS que conozco, el cual es Oracle. Sucede que he llegado a varios proyectos porque tienen problemas con la fragmentación de los discos de la base de datos, tablas que no pueden crecer más, problemas con integridad referencial —no se pueden borrar datos de alguna tabla con Foreign Key—, y algunos otros más sutiles que no se ven a simple vista pero que afectan al desempeño global del DBMS como encadenamiento en bloques de datos, espacios más grandes de lo necesario, niveles de concurrencia inadecuados.
¿Por qué sucede esto? La respuesta es muy simple, resulta que en el caso de Oracle, la creación de un objeto, como una tabla o un índice, necesita parámetros de almacenamiento, tales como PCTFREE, PCTINCREASE, INITIAL, MAXEXTENTS y otros más. Pero, si se realiza automáticamente por un usuario que no conoce la existencia de estos, los valores se toman por omisión y rara vez resultan ser
los adecuados.
Un ejemplo típico es el PCTINCREASE, que indica el porcentaje de espacio que se va a reservar para el objeto creado cuando se acabe el espacio (extent) actual. El valor por omisión es de 50. ¿Qué significa esto? Bueno, que si tengo una tabla que de INITIAL tiene 10MB pero sigue creciendo y rebasa estos 10MB, la próxima extensión que se va a tomar será 50% más grande, es decir, de 15MB, y la siguientes de 22MB, 33.8 MB, 50.7MB y 76MB. Así, en tan sólo cinco iteraciones se incrementó en casi 800% el valor inicial. ¿Resultado? Fragmentación y
espacio mal utilizado, además de que no permite saber si el próximo extent va a caber en el tablespace.
Otro ejemplo es el parámetro MAXEXTENTS que indica el número máximo de extents que se permiten alojar para ese objeto. Así, si se indica un valor demasiado bajo, puede ser que la tabla rebase estos valores y marque un error ORA-01631 max # of extents num reached in [table name].
Evidentemente, después de que se corren los scripts y se crea toda la base de datos, no existen problemas y se procede al desarrollo de las aplicaciones. Sin embargo, no pasa mucho tiempo cuando empiezan a surgir las consecuencias. Todos sabemos que cuesta más arreglar un problema que prevenirlo —el costo de arreglar un problema durante el desarrollo debe de tomar en cuenta a los programadores que quedan parados sin poder trabajar—. ¿Y qué decir cuando estos sistemas se liberan a producción con los parámetros por omisión mencionados? Siempre se termina por llamar a alguien que arregle los dimensionamientos.
¿Entonces no debemos utilizar para nada ERwin y hacer nuestros diagramas y scripts a mano? ¡Por supuesto que no! El planteamiento es que subordinemos esta excelente herramienta a los criterios de quien conoce los requerimientos específicos del DBMS para el que está generando, de tal forma que realize los cálculos pertinentes e indique los valores óptimos. Si no hacemos esto, aún cuando generemos nuestros objetos a mano, el riesgo será el mismo. Toma en cuenta que “Es mejor prevenir que remediar”. Este es un consejo muy sabio y económico. ¿no lo creen?
Acerca del Autor
Artemio Mendoza es Director de Operaciones de Towa Software, empresa de consultoría en TI de la cual es socio fundador. Durante más de once años se ha desempeñado como consultor, gerente y director en empresas de tecnología en México y Estados Unidos para clientes como GE Plastics, McKinsey & Company, Bancomer y Alestra. Artemio tiene el grado de Maestría en Administración de TI, otorgado por el Tec de Monterrey.
Sin embargo, aún con todas sus gracias, si dejamos demasiadas cosas en las manos de ERwin terminaremos con bases de datos altamente ineficientes. ¿Por qué esta afirmación?
Bueno, para justificarla voy a hablar acerca del RDBMS que conozco, el cual es Oracle. Sucede que he llegado a varios proyectos porque tienen problemas con la fragmentación de los discos de la base de datos, tablas que no pueden crecer más, problemas con integridad referencial —no se pueden borrar datos de alguna tabla con Foreign Key—, y algunos otros más sutiles que no se ven a simple vista pero que afectan al desempeño global del DBMS como encadenamiento en bloques de datos, espacios más grandes de lo necesario, niveles de concurrencia inadecuados.
¿Por qué sucede esto? La respuesta es muy simple, resulta que en el caso de Oracle, la creación de un objeto, como una tabla o un índice, necesita parámetros de almacenamiento, tales como PCTFREE, PCTINCREASE, INITIAL, MAXEXTENTS y otros más. Pero, si se realiza automáticamente por un usuario que no conoce la existencia de estos, los valores se toman por omisión y rara vez resultan ser
los adecuados.
Un ejemplo típico es el PCTINCREASE, que indica el porcentaje de espacio que se va a reservar para el objeto creado cuando se acabe el espacio (extent) actual. El valor por omisión es de 50. ¿Qué significa esto? Bueno, que si tengo una tabla que de INITIAL tiene 10MB pero sigue creciendo y rebasa estos 10MB, la próxima extensión que se va a tomar será 50% más grande, es decir, de 15MB, y la siguientes de 22MB, 33.8 MB, 50.7MB y 76MB. Así, en tan sólo cinco iteraciones se incrementó en casi 800% el valor inicial. ¿Resultado? Fragmentación y
espacio mal utilizado, además de que no permite saber si el próximo extent va a caber en el tablespace.
Otro ejemplo es el parámetro MAXEXTENTS que indica el número máximo de extents que se permiten alojar para ese objeto. Así, si se indica un valor demasiado bajo, puede ser que la tabla rebase estos valores y marque un error ORA-01631 max # of extents num reached in [table name].
Evidentemente, después de que se corren los scripts y se crea toda la base de datos, no existen problemas y se procede al desarrollo de las aplicaciones. Sin embargo, no pasa mucho tiempo cuando empiezan a surgir las consecuencias. Todos sabemos que cuesta más arreglar un problema que prevenirlo —el costo de arreglar un problema durante el desarrollo debe de tomar en cuenta a los programadores que quedan parados sin poder trabajar—. ¿Y qué decir cuando estos sistemas se liberan a producción con los parámetros por omisión mencionados? Siempre se termina por llamar a alguien que arregle los dimensionamientos.
¿Entonces no debemos utilizar para nada ERwin y hacer nuestros diagramas y scripts a mano? ¡Por supuesto que no! El planteamiento es que subordinemos esta excelente herramienta a los criterios de quien conoce los requerimientos específicos del DBMS para el que está generando, de tal forma que realize los cálculos pertinentes e indique los valores óptimos. Si no hacemos esto, aún cuando generemos nuestros objetos a mano, el riesgo será el mismo. Toma en cuenta que “Es mejor prevenir que remediar”. Este es un consejo muy sabio y económico. ¿no lo creen?
Acerca del Autor
Artemio Mendoza es Director de Operaciones de Towa Software, empresa de consultoría en TI de la cual es socio fundador. Durante más de once años se ha desempeñado como consultor, gerente y director en empresas de tecnología en México y Estados Unidos para clientes como GE Plastics, McKinsey & Company, Bancomer y Alestra. Artemio tiene el grado de Maestría en Administración de TI, otorgado por el Tec de Monterrey.
- Log in to post comments