Diseñando bases de datos

Una buena práctica que he aprendido durante mis desarrollos es el de construir bases de datos sin diseñadores visuales ¿Por qué? Porque me permiten visualizar mientras escribo las relaciones entre las tablas y entidades, además de que me permite tener presente toda la base de datos (no memorizada, sino tener presente sus relaciones a grandes rasgos para futuras referencias). Otra razón es que trabajo más rápido que con diseñadores visuales: clic aquí, escribir allá, arrastrar para acá, navegar por todo el mapa, en cambio al usar solo texto, simplemente voy digitando, pongo nombres y defino un estándar para documentar posteriormente.

Otra práctica es la de generar scripts para diferentes objetivos: script de estructura (esquemas, tablas, llaves, índices), script de modelado (vistas, SSPP que devuelvan resultados), script de procesamiento (SSPP que procesan en transacciones, funciones), script de datos iniciales. Si los scripts se vuelven más largos, hay que dividirlos, por ejemplo: script de estructura en script de tablas y script de llaves e índices.

Cuando diseñes una base de datos comienza por tener a mano lápiz y goma (sino, entonces unas plumas de colores) y hojas de papel medianas a grandes (sino, aunque sea tamaño media carta) ¿por qué? Porque construir una base de datos, además de requerir análisis de la información para organizarla, necesita imaginación, organización espacial y cierta capacidad de previsión, además de que estás creando algo intangible y abstracto, y para el cerebro, lidiar con todas las entidades que vayas creando e vuelve complejo, de modo que si las plasmas en papel a como tu mente te vaya dictando, irás refinando tu diseño cada vez y será más fluido. Entonces ¿por qué no usar un diseñador visual en vez de estos rudimentos? Durante mi estudio en la Maestría nos mencionaron que debemos hacer uso de la tecnología buscando el modo más eficaz posible, y que tecnología no es por fuerza algo electrónico o digital, un lápiz y una goma son tecnología también. Además ¿te has preguntado por qué no han desaparecido aún? Para nuestro caso: no hay monitor suficientemente grande que te permita ver cómodamente la totalidad de un diagrama, y que puedas modificar, incluso entre varias personas al mismo tiempo. (Tema para otra discusión). Al momento de diseñar ten en cuenta las necesidades actuales y futuras posibles para establecer tu nivel de normalización.

Ya que tengas el diagrama, organiza los atributos de las entidades agrupándolos para que encuentres patrones y estandarices tu diseño (te será más fácil mantener tu base de datos y hacerla crecer cuando se requiera). Esto será tu diccionario de datos, y hay motores de BB.DD. que te permiten definir dominios y tipos personalizados, de esta forma te es más fácil organizar todo (solo cuida de no abusar en la creación de los tipos personalizados). Tendrás también bien definidos los nombres para tus llaves principales y foráneas. Algunos motores de BB.DD., como SQL Server, permiten definir esquemas para agrupar los elementos que construyas y tener mejor organización.

Ya que tienes estos elementos y todo organizado para la estructura de las tablas y sus relaciones, es hora de comenzar a crear los scripts para la base de datos. Verás que es mucho más rápido y tendrás buen conocimiento de tu base de datos. Una vez concluido el script lo puedes guardar y ejecutar para construir tu base de datos. De aquí puedes construir el conjunto básico de vistas que utilizarás para recuperar información.