En búsqueda de un modelo estándar de diseño de Bases de Datos
Siempre he sido criticado por mantener mi posición neutral en cuanto al diseño, selección de modelos, patrones, estilos y prototipos de todo lo que refiere a la programación y a las bases de datos.
Pero en esta ocasión voy a romper un poco el hielo proponiendo un "estándar" para el modelado de bases de datos.
No es el objetivo en este momento de seleccionar una base de datos, los cual haré en una próxima ocasión.
Pero antes supondré que ya posee unos conocimientos básicos de bases de datos, especialmente en cuanto a normalización refiere, y que al menos se ha trabajado una base de datos.
Es probable que alguien se haya preguntado el porqué del título; si se lleva una gran bagaje en el mundo de las bases de datos, posiblemente se identifique la siguiente cita:
Datamining: El arte de torturar los datos hasta hacerlos confesar
Pero, ¿cómo se podría hacer "confesar" unos datos mal organizados y estructurados? Una tarea casi imposible.
Luego de haber experimentado con varias de las propuestas de diferentes autores, modelos y "estándares", me aventuro a presentar una propuesta un tanto arriesgada y atrevida, y para muchos contraproducente y abusiva, queriendo aclarar que no es mi objetivo decir que es la panacea o una declaración que deba ser asumida de inmediato, es sencillamente una propuesta que cada uno pondrá en práctica según lo considere.
A medida que se desarrollan las diferentes entidades o tablas, con el principal problema al cual me he enfrentado al hacerles manteniemiento es es cuanto a la asignación de los nombres a las tablas y sus respectivos campos.
Existen diversas propuestas para designar nombres a las tablas y sus campos, los cuales pienso enumerar a continuación, además de presentar los pros y contras de cada uno.
- Notación 1:
- Reglas:
- El nombre de la tabla debe tener máximo 12 caracteres y todas sus letras deben estar en mayúsculas. (Ej: ESTUDIANTE)
- Las tres primeras letras de cada campo, deben hacer referencia a la tabla, seguido por un guión de piso o de suelo (_) y luego tres caracteres que indiquen el contenido del campo, y todos sus caracteres deben estar en mayúsculas. (Ej.: EST_COD, EST_NOM, EST_APE, EST_DIR)
- Ventajas:
- Para su tiempo la principal ventaja que ofrececía era que debido a la limitación que poseía el MS-DOS y similares de solo poder archivos de máximo 8 caracteres, garantizaba que el nombre siempre iba a ser válido. Esto nunca aplicó a bases de datos sobre Unix o similares.
Código SQL muy breve y relativamente fácil de modificar - Desventajas:
- Puede presentarse el caso que dos campos puedan tener nombres MUY similares y complicar el mantenimiento de las tablas
- Notación 2:
- Reglas:
- Todos los nombres de campos y tablas son en mayúsculas
- El nombre de la tabla debe ser de la menor cantidad posible de caracteres y para esto se suprimen todas las vocales. Sólo existen dos excepciones a esta regla. La primera si la palabra inicia en vocal, y la segunda, cuando las vocales de la última sílaba son significativas o pueden aclarar la palabra (Ej: ESTDNTE)
- Los nombres de los campos deben iniciar con tres caracteres, correspondientes a la tabla a donde pertenecen o, en el caso de los campos foráneos, el nombre de la tabla maestra (Ej: EST_CDGO, EST_NMBRE, EST_APLLDO CIU_NCMNTO)
- Ventajas:
- Tablas y campos organizados, donde se puede definir el origen de los datos en el caso de los campos foráneos.
- Desventajas:
- Código SQL resultante supremamente complejo y confuso, debido a la posible similitud entre palabras, éstas al no contener vocales dificulta la lectura y así un mantenimiento adecuado a la base de datos
A continuación expondré dos propuestas las cuales son muy similares pero mutuamente excluyentes, como lo podrán notar más adelante, pero tienen como propósito presentar una alternativa a los estándares actuales de diseño, formulación y desarrollo de bases de datos.
Inicio con la base común para ambas propuestas:
Propuesta de diseño y convenciones para bases de datos:
- Los nombres tanto de entidades como de atributos (tablas y campos) deben estar escritos en mayúscula. Podrán ser usados los caracteres [A-Z][a-z][_][0-9]: Esto se hace debido a las diferentes limitaciones de las bases de datos especialmente antiguas, así que debería evitarse el uso de caracteres especiales por cuestiones de compatibilidad, pero si se dispone de una base de datos con soporte para las diferentes codificaciones existentes, de las cuales personalmente recomiendo la UTF-8, ya que es la universal y se rige por el estándar UNICODE., recomiendo que se usen los caracteres especiales, ya que estos facilitarían en gran manera la lectura de cada una de las sentencias, pero hay que tener en cuenta cada una las limitaciones de las bases de datos y los cambios especialmente en sentencias SQL que esto generaría; por lo tanto, úsese pero teniendo en cuenta que esto exige pequeños cambios en la generación y creación especialmente de las consultas SQL.
- El nombre de una entidad o de un campo no puede empezar con número: Aunque en la actualidad sí es posible, no se debería, incluso creo que no se presenta ningún caso en el cual se requiera, si existe, me encantaría conocerlo, pero mientras eso sucede, no se debería hacer.
- El nombre de la entidad o del campo, en el caso que esté compuesto por dos o más palabras, éstas deben ser separadas por el signo de subrayado (ej: personal_departamento)
- Un nombre de entidad puede llegar a estar compuesto de dos partes: un prefijo de algunos caracteres que indica el ámbito de utilización de la entidad o su pertenencia principal, ya sea un tema o módulo y un nombre de que representa la identificación de la entidad, unidos por un signo de subrayado
- Para cualquier caso los nombres de los campos o de las entidades, se debe procurar que no sean excesivamente extensos, sin dejar a un lado la expresividad y claridad en los nombres
- Los nombres de entidades y campos deben estar escritos en singular y evitar para ellos la utilización de verbos
- Los campos que sean claves primarias de una entidad se deben denotar con el prefijo o sufijo ID, y el nombre de la entidad sin prefijo (si lo tuviese) unidos por un signo de subrayado preferiblemente.
- Los campos de clave foránea y las claves principales con las que se relacionan deben ser de igual nombre, salvo cuando una entidad disponga de mas de una clave foránea a la misma clave primaria. En este caso se dará un nombre adecuado que represente la relación.
- Los campos de tipo booleano aunque deberían evitarse por medio de listas, en el caso de existir, deben estar en participio en el caso de verbos o usar algún prefijo o sufijo que los identifique como tal, separados por el signo de subrayado
Pero independientemente de cualquier teoría, estándar o norma, la regla general para el desarrollo, diseño e implementación de bases de datos radica en una primitiva bastante sencilla.
Si cualquier persona que vea el diseño puede definir el funcionamiento, lógica y significado de cada una de las entidades y sus relaciones, se puede considerar que el trabajo ha sido realizado correctamente
