A la hora de definir una tabla hay que tener en cuenta ciertos aspectos en la codificación:
? Sólo deben ser numéricas aquellas columnas que sean susceptibles de operaciones aritméticas. Es decir, un código de factura, no debe ser numérico ya que nunca se van a sumar los códigos.
? A la hora de codificar columnas alfanuméricas, hay que tener en cuenta el sistema de ordenación:
Dada la siguiente lista de valores (de distinto tipo de dato):
|| Alfanumérico || Numérico ||
|| '50' || 50 ||
|| '41' || 41 ||
|| '21' || 21 ||
|| '1' || 1 ||
|| '5' || 5 ||
|| '20' || 20 ||
|| '100' || 100 ||
|| '13' || 13 ||
|| '10' || 10 ||
|| '2' || 2 ||
La lista ordenada será la siguiente:
|| Alfanumérico || Numérico ||
|| '1' || 1 ||
|| '10' || 2 ||
|| '100' || 5 ||
|| '13' || 10 ||
|| '2' || 13 ||
|| '20' || 20 ||
|| '21' || 21 ||
|| '41' || 41 ||
|| '5' || 50 ||
|| '50' || 100 ||
El orden, como vemos, difiere mucho uno de otro. Sin embargo, dada la siguiente lista de valores (de distinto tipo de dato):
|| Alfanumérico || Numérico ||
|| '050' || 50 ||
|| '041' || 41 ||
|| '021' || 21 ||
|| '001' || 1 ||
|| '005' || 5 ||
|| '020' || 20 ||
|| '100' || 100 ||
|| '013' || 13 ||
|| '010' || 10 ||
|| '002' || 2 ||
La lista ordenada será la siguiente:
|| Alfanumérico || Numérico ||
|| '001' || 1 ||
|| '002' || 2 ||
|| '005' || 5 ||
|| '010' || 10 ||
|| '013' || 13 ||
|| '020' || 20 ||
|| '021' || 21 ||
|| '041' || 41 ||
|| '050' || 50 ||
|| '100' || 100 ||
La diferencia está en que el método alfanumérico ordena por posiciones, no por valores absolutos.
? Las descripciones deben ser lo suficientemente largas como para almacenar el caso más desfavorable para la columna, aunque tampoco se deben crear columnas demasiado largas. Por ejemplo: para albergar nombre y apellidos nos valdrá un 2 nombres de 10 caracteres cada uno, más dos apellidos de 15 caracteres cada uno. Total 35 caracteres. Para darnos un margen de error podemos poner 40 caracteres. Más de esta estimación será una longitud exagerada para el campo.
Codificación compuesta o "claves inteligentes"
En bases de datos antiguas había una práctica muy común que consistía en utilizar una sola columna con varios significados. El significado de la columna dependía de las posiciones de los dígitos. Por ejemplo, se podría definir la siguiente regla para almacenar las referencias de las facturas:
|| Dígitos 1-2 || Día de emisión. ||
|| Dígitos 3-4 || Mes de emisión. ||
|| Dígitos 5-8 || Año de emisión. ||
|| Dígitos 9-14 || Código de cliente. ||
|| Dígitos 14-20 || Número de factura. ||
Así la referencia de la factura número 1, emitida a 23/8/1999, para el cliente código 567 sería: 23081999000567000001
Esto no tiene ningún sentido, ya que queda mucho más claro separar cada valor a su columna correspondiente, y si es necesario, definir todas las columnas necesarias como clave.
El origen de esta práctica viene de la época de las bases de datos jerárquicas en las que la clave sólo podía estar formada por un campo. Entonces era la única manera de definir una clave compuesta.
Estándar de nomenclatura de objetos
Cuando un equipo de desarrollo da los primeros pasos en un proyecto informático (de bases de datos o de cualquier otro tipo), lo primero que se debe definir es qué estándar de nomenclatura de objetos se va a utilizar. El objetivo principal de esta tarea es que el esquema sea consistente y homogéneo, además de permitir una memorización más rápida de los objetos.
El estándar debe responder a las siguientes preguntas:
? ¿Los nombres de objetos van en mayúsculas o minúsculas?
? ¿Debo utilizar nombres lo más descriptivos posibles o sin embargo nombres muy
cortos? ? ¿Puedo usar abreviaturas? ? ¿Los nombres deben ir en singular o en plural?
El estándar debe ser un documento que tengan presente en todo momento el equipo de desarrollo, y siempre debe aplicarse salvo contadas excepciones.
A continuación tienes ciertas normas, que aunque no pretenden ser un estándar, si que pueden resultarte de utilidad. Tú eres el que tienes que decidir si quieres aplicarlas, o bien crear tus propio estándar de nomenclatura:
- Los nombres de objetos (tablas, índices, claves primarias, claves foráneas…) deben ir en mayúscula. Oracle interpreta por defecto todos los objetos en mayúscula a no ser que se escriba su nombre entre comillas dobles:
- Los nombres de objetos deben ir en singular ya que el nombre representa a la entidad que almacena, y no las entidades que almacena. Una razón práctica es que con los nombres en minúscula se ahorra 1 ó 2 letras, lo cual no es despreciable.
- Los nombres a utilizar deben ser descriptivos, aunque no deben ser demasiado largos. Oracle admite hasta un máximo de 30 caracteres para los identificadores, aunque no es recomendable llegar hasta el límite. Nunca se deben utilizar nombres de objetos crípticos, como XP34TY ó 3456RRDW7E2. con esto lo único que conseguimos es complicar el esquema con nombres de tablas que son difíciles de recordar.
- Es recomendable utilizar abreviaturas, sobre todo si el nombre más descriptivo es demasiado largo. Como veremos más adelante, Oracle sólo permite 30 caracteres para el nombre de las tablas, por lo que muchas veces las abreviaturas se convierten en una obligación. Para nombres cortos no es necesario utilizar abreviaturas.
- A la hora de nombrar tablas relacionadas entre si, es recomendable que el nombre empiece por el sufijo que representa la entidad principal.
- Se pueden establecer ciertas abreviaturas para los nombres de columnas:
- Los nombres de clave primaria deben ir precedidos del prefijo PK_ (Primary key), los de índices por IND_, y los de clave foránea por FK_ (Foreing key). El nombre restante será el de la propia tabla para las claves primarias, el de la tabla referenciada para las claves foráneas y para los índices una o dos palabras descriptivas que indiquen la razón por la que se crea ese índice (si es posible).
||
Nombres ||
Interpretación de Oracle ||
|| Factura, factura y FACTURA || Equivalente. ||
|| "FACTURA", "factura", "Factura" || Distintos objetos. ||
||
Entidad ||
Nombre recomendado ||
|| Facturas || FACTURA ||
|| Facturas de proveedores || FACTURA_PROVEEDOR ||
|| Facturas que no han sido pagadas || FACTURA_PENDIENTE_PAGO ||
|| Facturas caducadas || FACTURA_CADUCADA ||
||
Entidad ||
Nombre recomendado ||
|| Empresas pertenecientes al sector de la construcción || EMPRESA_CONSTRUCCION ||
|| Clientes que han tenido algún impago || CLIENTE_MOROSO ||
|| Proveedores que se suelen retrasar en sus entregas || PROVEEDOR_LENTO, ||
|| || PROVEEDOR_RETRASO ||
|| Facturas caducadas de empresas del sector de la || FACTURA_CONSTRUCCION_CADUC ||
|| construcción || ADA ||
||
Entidad ||
Nombre recomendado ||
|| Empresas pertenecientes al sector de la construcción || EMPRESA_CONSTR_DEMOLICION ||
|| que han tenido alguna demolición || ||
|| Clientes que han tenido algún impago || CLIENTE_MOROSO ||
|| Proveedores que se suelen retrasar en sus entregas || PROVEEDOR_CONSTR_LENTO, ||
|| de empresas del sector de la construcción || PROVEEDOR_ CONSTR _RETRASO ||
|| Facturas caducadas de empresas del sector de la || FACTURA_CONSTR_CADUCADA ||
|| construcción || ||
|| Almacén de productos terminados para empresas del || ALMACEN_ CONSTR _PROD_TERM ||
|| sector de la construcción || ||
||
Entidad ||
Nombre recomendado ||
|| Facturas || FACTURA ||
|| Líneas de Factura (detalle de FACTURA) || FACTURA_LINEA ||
|| Desglose de las líneas de factura (detalle de || FACTURA_LINEA_DESGLOSE ||
|| FACTURA_LINEA) || ||
|| Factura impagadas (Relación 1-1 con FACTURA) || FACTURA_IMPAGADA, ||
|| || FACTURA_IMPAGO ||
||
Columnas típicas ||
Abreviatura ||
|| Código de… || C_xxx ||
|| Descripción de… || D_xxx ||
|| Referencia de … || REF_xxx ||
|| Importe de … || <TD style="BORDER-RIGHT: #808080 1px solid; BORDER-TOP: #808080 1px solid; BORDER-LEFT: #808080 1px solid; WIDTH: 218 ||
