Evaluar Conozca los pros y contras de las tecnologías, productos y proyectos que está considerando.

Normalizar sistemas database transaccionales induce BI y reduce costos

Whitehorn argumenta que la normalización de databases, puede apoyar los esfuerzos de BI, reducir mantenimiento de databases y gastos de licencia.

Históricamente, la elección de motores de base de datos dentro de las organizaciones se debió casi totalmente por la elección de las aplicaciones. Cuando una empresa necesita un sistema de control de inventario o de recursos humanos, la decisión de compra se basa generalmente en la idoneidad de la aplicación y a las personas involucradas no les importaba qué base de datos transaccional sustentaba el programa elegido. Las bases de datos a menudo proliferaban como consecuencia de ello, y lo hicieron aún más rápido si se presentaban las adquisiciones o fusiones.

En lo que ahora parece un pasado lejano, las aplicaciones generalmente operaron como sistemas autónomos dentro de los departamentos, sin entradas de, o salidas a otras partes de la organización. Si el uso aislado de las aplicaciones persistió, habría mucho menos situaciones hacia la normalización de bases de datos ahora. Pero, por supuesto, no se hizo.

Los sistemas departamentales fueron diseñados para ejecutar transacciones, y así lo hicieron. Ahora estamos viendo la imperiosa necesidad de información, no sólo los datos transaccionales gruesos. Descubriendo el Business Intelligence (BI) y los resultados de análisis que las empresas pueden utilizar para obtener ventajas competitivas sobre sus rivales requiere la correlación cruzada de datos de múltiples sistemas de procesamiento de transacciones. Esto hace que la tarea de integrar y correlacionar datos mucho más fácil si todos estos sistemas se han migrado (en un proceso bien administrado durante un período de tiempo) para ejecutarse en un motor de base de datos.

La extracción de información para uso de BI es el principal impulsor del negocio de la normalización de bases de datos, y puede ser una razón de peso por sí mismo para ponerse de acuerdo en un estándar de base de datos en toda la empresa. También hay otras ventajas potenciales, lo más importante de lo cual - más aún en estos tiempos de desafíos económicos - es una reducción en el mantenimiento de bases de datos y los costos de integración. Su equipo de gestión de base de datos puede concentrarse en la supervivencia del motor, y puede incluso ser capaz de reducir el tamaño del equipo (pero lea hasta el final del artículo, antes de empezar a despedir gente).

Los costos de licenciamiento de software con frecuencia también pueden reducirse. Si su empresa utiliza seis aplicaciones en plataformas de bases de datos diferentes, usted estará pagando seis cuotas de licencia independientes. Los costos de bases de datos no desaparecen mágicamente si usted estandariza en una única plataforma, pero podría ser capaz de negociar un acuerdo de licencia que ofrece descuentos por volumen más grandes de lo que su empresa obtiene ahora.

En los primeros días del mercado de base de datos, había disponibles muchos motores de bases de datos transaccionales y los usuarios a menudo se limitan a las aplicaciones que se ejecutan en bases de datos específicas para las cuales habían sido desarrollados. Que efectivamente convirtieron la normalización de bases de datos en imposible. Un avance rápido hasta hoy: el número de bases de datos relacionales convencionales se ha reducido a un puñado, y aplicaciones más tradicionales se pueden ejecutar en cualquiera de ellos. Como resultado, el soporte de aplicaciones en la mayoría de los casos ya no puede ser utilizado como un argumento válido en contra de la normalización de las bases de datos. De hecho, la falta de disponibilidad en múltiples bases de datos podría ser una buena razón para decidir no comprar una aplicación deseada; discutible si se trata de una que no funciona en todas las plataformas de bases de datos líderes es probable que no sobreviva a largo plazo.

Normalización de base de datos: ¿Qué tan lejos es demasiado lejos?

Sin embargo, cualquier política de normalización debe basarse en las necesidades de negocio de una organización y no necesariamente ser aplicada bajo una base de “un solo tamaño para todos” que abarca tanto las operaciones de negocio como los procesos de BI. Hasta ahora, el enfoque de este artículo ha sido hacia el motor de base de datos transaccionales. La elección de uno de los principales sistemas de gestión de base de datos relacionales para ejecutar aplicaciones transaccionales tiene mucho sentido.

Pero obligar a los sistemas analíticos dentro del molde RDBMS no tiene mucho sentido para muchas organizaciones. Así que muchas empresas utilizan bases de datos ligeras como Microsoft Access para el desarrollo de aplicaciones o para apoyar a unos cuantos usuarios finales - por ejemplo, para administrar una lista telefónica utilizada solo por 6 personas en el departamento de compras de un pequeño fabricante. Dichas aplicaciones son por lo tanto una mala solución para una base de datos relacional en toda regla.

En general, es mejor conservar una mente abierta y evitar tratar de forzar los requisitos de la base de datos de toda la empresa en una única plataforma. Usted podría, por ejemplo, pensar en la estandarización de un motor de base de datos relacional para sus principales sistemas transaccionales, un producto multidimensional una u otra base de datos analítica especializada para sus sistemas de BI y los sistemas de almacenamiento de datos y un motor de base de datos de escritorio para aplicaciones a pequeña escala.

Las diferentes tecnologías, por supuesto, requieren soporte y mantenimiento de su equipo de base de datos. Pero si usted ha logrado reducir el número de plataformas de bases de datos de, por ejemplo, seis transaccionales, dos analíticas y tres tecnologías de escritorio a sólo tres en el total, las ganancias de eficiencia, - costo y otros - están casi obligados a acumularse.

SOBRE EL AUTOR: Mark Whitehorn es Profesor de Análisis en la Escuela de Computación de la Universidad de Dundee en Escocia, donde imparte un curso de maestría en Inteligencia de Negocios. Es también Investigador Asociado en la Universidad de Cambridge en Inglaterra y, a través PenguinSoft Consulting trabaja con empresas en el diseño de base de datos y almacenamiento de datos.

Profundice más

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close