Diseño de Bases de datos

    Todos los cursos de DBA, libros de certificación y currículas que conozco, comienzan con una introducción a Oracle, y los fundamentos del modelo relacional. Sin embargo, en los exámenes de certificación no existe ninguna pregunta que debamos responder acerca de entidad - relación, normalización ni otro punto relacionado


No me pondré a preguntar el porqué de esto, sino a advertirles que todo lo que aprendamos y apliquemos sobre dicho tema no será importante: será fundamental


Temas a tener en consideración:

Muchas veces ni nos acordamos que Oracle es un sistema de administración de bases de datos relacionales, pero que además admite tipos de datos complejos ya que agrega el paradigma "orientado a objetos" al mismo tiempo que el "relacional", con lo que nos "venden" que este sistema híbrido toma lo mejor de ambos modelos

Otra cosa que frecuentemente nos han dicho es que la normalización de una base de datos tiene múltiples formas, pero que cumpliendo con las tres primeras obtenemos un sistema eficiente y funcional

Finalmente, nos advierten que una base de datos que cumple estrictamente la "tercera forma normal" puede ser ineficiente, así que seamos realistas antes de puristas y no exageremos normalizando hasta el infinito

Descartado el modelo orientado a objetos, la normalización más allá de la tercera forma normal, y la des-normalización voluntaria, nos quedamos con el habitual modelo relacional, el cual en mi larga experiencia trabajando con bases de datos alcanzó para resolver cualquier problema que se me hubiese presentado


Teniendo en cuenta además que normalizar una base de datos es un proceso bastante intuitivo y guiado por reglas, ¿qué más puede agregarse?


Para mi gusto podemos agregar varias cosas, pero gustos aparte, cualquier equivocación incurrida al momento de crear el "modelo de datos", hará ineficiente el sistema de información, llevando al fracaso la aplicación que maneje la base de datos

Dado mi fanatismo en enfatizar el diseño de la base de datos, permítanme entonces ofrecerles el siguiente rejunte de...

    Recetas y/o consejos:

    Piensen por sí mismos: no crean en las recetas y consejos que les ofrecen. En todo caso evalúen las justificaciones que las preceden y en caso de duda, desconfíen

    Siéntanse culpables si sienten la tentación de des-normalizar una base de datos: no recuerdo ningún caso de pérdida de desempeño por haber exagerado en la normalización, y si piensan que el desempeño puede agravarse trabajando en un ambiente de altísimo volumen de transacciones, piensen que dichos volúmenes sólo se manejan en empresas con un nivel de ganancias proporcional al volumen de sus datos, y en tal caso no deberían tener problemas en adquirir la infraestructura para manejar ágilmente 10 millones de transacciones por segundo. ¿Será suficiente?

    Sean coherentes: tómense todo el tiempo necesario para normalizar los nombres de tablas y sus columnas, y el tipo de datos. Una vez definidas las normas, ¡a cumplirlas!

    Creen para cada tabla una columna sin otro propósito que el de almacenar las claves primarias. En caso de necesitar restringir valores únicos a través de una o más columnas de datos, utilicen claves únicas

    Utilicen tipos de datos numéricos para las claves primarias y ajenas

    No se dejen llevar por las costumbres: crear una columna llamada "sexo" que almacene valores "M" o "F" nunca será mejor que la columna sea numérica que almacene "unos" y "dos"

    Reserven en las claves primarias, únicas y ajenas los valores con el número "0" (no lo utilicen como dato). Disponer de este número libre me ha ayudado a encontrar la forma más eficiente de realizar búsquedas (cláusula "WHERE")

    No se confíen en la automatización. Busquen una alternativa antes de utilizar disparadores (triggers), los cuales seguramente dejarán de funcionar al agregar o quitar una columna, o peor aún, podrían seguir funcionando pero arrojando resultados diferentes a los deseados

    Planifiquen su base de datos a futuro: una aplicación sencilla para una empresa pequeña debería crecer junto con el negocio, o en todo caso debería poder ser "reciclada" para un proyecto de mayor escala, por lo tanto piensen en todos los "multi" que puedan: multi-usuario, multi-moneda, multi-empresa, multi-plataforma, y diseñen con el crecimiento en mente: piensen en la incomodidad que sería tras 3 años de funcionamiento de un sistema, tener que adaptar todas las columnas que almacenen montos de dinero, para agregar la posibilidad de manejar distintas "monedas" y que la cosa pueda seguir funcionando. Piensen también en lo que podría pasar si en un país conviven 2 o más monedas, o si de repente una saludable economía se contagia de inflación

    Piensen de qué manera poder integrar otros sistemas que son imprescindibles para algunos usuarios, tales como aplicaciones impositivas administradas por agencias gubernamentales, o aplicaciones técnicas tales como administración de proyectos o CAD-CAM, las cuales, casualmente son "compatibles" con Oracle, o en el peor de los casos con ODBC

    Piensen qué pasaría si su sistema de repente debe acoplarse a un nuevo sistema, el cual se encargará de manejar módulos que hasta ahora estaban bajo su exclusiva administración