iPOWER 2026

In this sesion we are going to review a practical case with the option that we have to partition a table.

Presents a clear strategy for index management in DB2 for i, focused on improving performance and maintaining consistency. It explains component selection and weighting criteria, along with rules for periodic updates and quality control mechanisms. Tactics for optimizing efficiency, reducing costs, and ensuring representativeness of the analyzed market or system are highlighted. Furthermore, it emphasizes the importance of transparency and continuous evaluation, providing a robust framework for sustainably managing and evolving indices.

En una base de datos IBM i construida sobre DDS a lo largo de treinta años, las relaciones entre archivos nunca se declararon como restricciones: viven en el código de las aplicaciones y en la memoria de quien lo escribió. Puede que exista un diagrama, pero ¿está realmente actualizado? ¿Incluye todos los elementos relevantes de IBM i? ¿Muestra los nombres de sistema o los nombres largos? Y así, cuántas cosas más podríamos cuestionarnos acerca de él. Con la documentación de las columnas suele pasar lo mismo. Esta sesión recorre cómo cerrar esa brecha sin reescribir la base de datos: reunir en un solo modelo lo que el catálogo Db2 sabe y lo que solo está escrito en los fuentes DDS y SQL, descubrir las relaciones no declaradas comprobándolas contra los datos reales, y volver a extraerlo cuando la base cambie sin perder lo que se agregó a mano. Con ese modelo se puede por fin dibujar diagramas Entidad-Relación que incluyen elementos particulares de IBM i —archivos físicos, archivos lógicos y los lógicos multiformato— junto a tablas, vistas e índices, y sus relaciones, armados alrededor del proceso de negocio que hace falta explicar y no de la librería entera; y sobre el mismo modelo, documentar cada columna en lenguaje de negocio marcando la que contiene información personal.