Thomas H. Grayson
23 enero de 2002

• Mantener los datos bien diferenciados (p.ej., el primero y el último de los nombres van separados). Acercar unas columnas a otras posteriormente sobre la marcha es, en general, bastante fácil, pero separarlas no.
• ¿Cuál sería un ejemplo en el que analizar los subcampos de una columna podría dar mal resultado?
• ¿Cuándo nos puede interesar incluir los campos combinados en una columna?
  
  
• Primero, definir la clave primaria. Utilizar un nombre descriptivo (PARCELA_ID, no sólo ID).
  
  
• El uso de nombres descriptivos permite que los nuevos usuarios tengan alguna oportunidad de adivinar lo que es cada una de las columnas (p.ej., utilizar CUENTA_PARCELA en lugar de CTPA).
  
  
• Siempre que sea posible, utilizar una sóla columna para la clave primaria; las claves primarias de más de una columna son adecuadas para las interrelaciones de muchos a muchos.
  
  
• Utilizar tablas de referencia en lugar de almacenar valores de gran longitud.
  
  
• Emplear claves de tipo numérico siempre que sea posible (¿qué pasa con los códigos postales?).
  
  
• Evitar las claves autonuméricas (salvo en las tablas de referencia).
  
  
• Evitar utilizar más de una columna para representar una interrelación uno a muchos (p.ej., poner columnas como HIJO1, HIJO2, etc.; en una tabla llamada PADRES, en lugar de poner a los hijos en una tabla a parte).
  
  
• Con el fin de facilitar la lectura, utilizar el nombre de la clave primaria para las claves secundarias, a menos que se utilice la misma clave secundaria varias veces en la misma tabla (p.ej., 'situación laboral' y 'situación de residencia' de una persona; ambas pueden ser claves secundarias que apunten a una tabla de situaciones).
  
  
• No incluir dos columnas cuyos valores estén entrelazados (p.ej., el nombre del condado y el ID de condado), salvo que una de las columnas sea la clave primaria de la tabla.
  
  
• Procurar restringir la introducción de valores NULOS en columnas que carecen de una amplia gama de valores posibles; por ejemplo, enteros entre 1 y 10, ambos inclusive
(esto no es aplicable a archivos DBF, ya que éstos, de por sí, no aceptan valores NULOS).


• Evitar utilizar varias tablas con estructuras similares para representar pequeñas variaciones de la misma entidad (p.ej., poner las parcelas de Boston y las de Cambridge en distintas tablas).
¿Por qué a menudo resulta tan difícil aplicar esta regla cuando se trabaja con GIS?


• Planear con antelación la transferencia de datos a una base de datos distinta. Por ejemplo, puede que nos interese mover algunos datos de Oracle a DBF, o de Microsoft Access a Oracle.
• Evitar poner en los nombres de las columnas caracteres que no sean mayúsculas (A-Z), números (0-9) o el subrayado (_). Cualquier otro caracter puede no ser aceptado por la base de datos. Algunos sistemas de bases de datos son sensibles al uso de mayúsculas y minúsculas en los nombres de las columnas, otros no.
• Procurar que los nombres de las columnas sean relativamente cortos. Cada tipo de base de datos soporta un número distinto de caracteres (p.ej., 30 en el caso de Oracle, 64 para Microsoft Access o 10 si es DBF). Intentar que los nombres de las columnas varíen en los primeros caracteres y no en los últimos, con el fin de evitar que se duplique alguno de los nombres por error al cortarlos para abreviar durante el proceso de conversión (p.ej., utilizar COL1 y COL2, en lugar de NOMBRE_COLUMNA_LARGA_1 Y NOMBRE_COLUMNA_LARGA_2).

Observar que el poner nombres cortos a las columnas puede ser incompatible con procurar que sean descriptivos para los nuevos usuarios. Comprobar que se está realizando una buena combinación.

Es importante recordar que éstas son reglas no escritas, basadas únicamente en la experiencia, ¡no leyes absolutas! Se pueden romper las reglas si es necesario, pero justificando la decisión. Las limitaciones de un paquete de software GIS suelen ser un buen motivo.