Estandarizacin de Bases de Datos

(postgresql)
Este es artculo no ha sido escrito por mi sino por un amigo (Miguel Ortega), me pareci muy buen
trabajo, aunque le hice unas mnimas correciones, espero no te moleste migueln en fin, el me
coment que lo podia publicar y aqui est.
El siguiente documento abarca las caractersticas mnimas y consideraciones necesarias al momento
de modelar cualquier base de datos para los proyectos que decidas desarrollar.Esta serie de reglas es
un intento de estandarizar nuestros procedimientos de desarrollo y ayudar en cierta medida a que
cualquier analista, independientemente del proyecto que este manejando, sea capaz de leer, analizar
y tomar decisiones con respecto al modelado de una base de datos.En principio son algunas normas,
que de forma ms o menos escueta, nos van a guiar en la construcciones de nuestras bases de datos
y que poco a poco iran evolucionando con la ayuda de los lectores del documento. Puede ser dificil
al comienzo pero cualquier duda o recomendacion pueden enviarla via e-mail.
Les recomiendo que lean este texto antes, durante y despus del modelado mientras nos
acostumbramos a tomarnos estas normas un poco ms en serio.
Regla N 01: Nombrando la BD
Al momento de nombrar la base de datos se sugiere usar una palabra corta, toda en minsculas (la
razon se explica luego). Por lo general se suele utilizar la actividad que se esta automatizando o en
su defecto (en caso de que haya alguna causa de fuerza mayor que impida hacerlo as) el nombre de
la empresa para la que se est desarrollando o una abreviacin de la misma; p.e.:
administrativo,contable,transporte.
Regla N 02: Uso de Esquemas
Toda base de datos debe constar de al menos DOS (02) esquemas. El primero (de nombre public) es
el que aparece automaticamente al crear la base de datos y que esta destinado a guardar todas las
tablas que puedan ser utilizadas por mas de un sistema (tablas comunes entre sistemas); es decir, si
tenemos dos sistemas integrables (Administrativo <-> Contable) que manejan un maestro de
empresas, entonces una tabla empresas debe existir en el esquema public que maneje la misma
informacin en ambos sistemas.
Por otro lado, se debe crear tantos esquemas como sean necesarios para que la modularizacin de la
base de datos sea amigable, esta es una consideracin que queda en manos del analista y que no
puede ser definido de una manera objetiva, la forma de nombrar estos esquemas es la misma que en
la regla N01 ya que debemos recordar que todo esquema (exceptuando public) debe ser usado
como prefijo a la hora de hacer un SELECT (A menos que se configure el motor para modificar esta
conducta).
Regla N 03: Nombre de Tablas
A diferencia de las maneras estandar de codificacin, en base de datos la codificacin tipo camello
no sirve ya que nos complica mucho a la hora de armar nuestras consultas. Esto se debe a que, para
el motor de base de datos,
SELECT * FROM PrimeraTabla
es lo mismo que
SELECT * FROM primeratabla
si tenemos una tabla llamada PrimeraTabla entonces la consulta adecuada sera:
SELECT * FROM "PrimeraTabla";
Otra consideracin que debemos tomar en cuenta es que las tablas se van a manejar en plural. Por
ejemplo: clientes, empresas, companias (ojo con no usar acentos o caracteres especiales).
Si el nombre de la tabla es compuesto debemos separar las palabras usando underscores (_) Ej:
primera_tabla.
Si el nombre compuesto es demasiado largo, es correcto usar una abreviacion CLARA de cada una
de las palabras.
Regla N 04: Nombre de Campos
Para los campos de cada tablas aplican exactamente las mismas reglas que para nombrar las tablas
con una salvedad: los nombres de los campos deben expresarse en singular.
Regla N 05: Tipos de Dato
Si existe un error fatal en el modelado de una base de datos, estoy seguro de que el primer paso es
asignarle un tipo de dato no adecuado a un campo.
Los tipos ms comunes son:
-> bigserial/serial: autonumericos
-> integer: enteros
-> float8: reales (aunque si se necesita precision se sugire usar el campo numeric definiendo su
tamao entero y su tamao decimal)
-> char(n): generalmente para almacenar opciones (en conjunto con un CHECK)
-> varchar(n): textos de longitud limitada
-> text: textos de longitud ilimitada
-> date: fecha
-> timestamp: fecha/hora
Regla N 06: USO PK, FK, INX, UNQ, CHK, DEFAULT
Toda tabla debe tener un Primary Key, siempre va a ser un campo serial/bigserial con el nombre
id.
Todos los campos que hagan referencia a un PK (es decir, todo FK) deben ser de tipo Int4/Int8.
La creacin de ndices es a juicio del analista, el tipo de ndice ms utilizado es btree.
No es adecuado hacer uso indiscriminado de los indices.
Por lo general todos los PKs y FKs son autoindexados pero no se olviden de revisar que esto sea
as.
Un ndice creado correctamente puede optimizar una consulta infinitamente.
Debido a que estamos haciendo uso de un campo id para ser el PK, vamos a recurrir a usar los
Uniques para definir otro punto de validacin. Por ejemplo: imaginemos una tabla de facturacin
(id, nro_factura, cod_empresa), el PK lo creamos de acuerdo a la regla anterior pero es necesario
validar que no exista dos veces el mismo nmero de factura entonces utilizamos un
unique(nro_factura, cod_empresa).
Es muy comn que tengamos la necesidad de guardar un campo que tiene 2 o ms valores
exclusivos el uno del otro y que son fijos (digamos el tipo de persona). En estas situaciones es muy
recomendable crear un CHECK con las opciones que permite el campo y tal vez colocarle un valor
por defecto (DEFAULT). Estos Checks es recomendable hacerlos tipo char(1) o char(2) (cuando
mucho) y utilizar letras asociadas a la opcin; adems, en el comentario del campo es indispensable
documentar que opciones maneja el check y que significa cada una.
El manejo de DEFAULTs es til para evitarnos los errores con campos nulos. Por ejemplo un
campo fecha podriamos colocarle como default la funcion current_date de manera de que en vez de
NULL se guarde la fecha en la que se agreg el registro.
Regla N 07: Nombres PK,FK,INX,UNQ,CHK
Los nombres de los Primary Keys y Foreing Keys los asigna la base de datos directamente si no son
escritos explicitamente. As que por ahora podemos despreocuparnos de los nombres de estos dos.
En el caso de ndices, claves nicas, y checks se anteponen INX (index), UNQ(unique) o
CHK(check) (de acuerdo al tipo) seguido de un underscore _ y el nombre del campo (o los
nombres de los campos, si son varios, tambien separados por underscores)
Si desean llevar tambien el control de los nombres de los PKs y los FKS, estas en la plena libertad
de aplicarle la misma regla.
Regla N 08: Documentacin
Al final del modelado, se esta en la obligacin de presentar un diccionario de datos y el modelo
entidad relacion.
Para construir el diccionario de datos es muy util definir comentarios BIEN COMPLETOS Y
DETALLADOS para cada columna, tabla y/o base de datos, de esta manera, es posible tomar los
catlogos de la base de datos y armar el diccionario sin re-trabajar.
Con respecto a los modelos de entidad relacin, puedes realizarlos con herramientas como
umbrello, aunque tambien hay una opcin de obtener el diagrama a partir de la base de datos con
Microsoft Visio (su herramienta de ingeniera inversa) un diagrama de la base de datos completa, y
adems generar tantos diagramas como mdulos tenga el sistema de manera que por mdulo se
pueda saber que tablas estan directamente relacionadas, si alguien conoce una herramienta libre que
haga esta labor aviseme por email o comentando este documento.
Regla N 09: Triggers
Los triggers y las funciones en lenguajes de procedimiento pl/? son indispensables en el
desarrollo de complejas aplicaciones. Mientas ms trabajo le demos a la base de datos, ms ptimas
son las aplicaciones, se hacen ms portables (aunque hay que aceptar que a veces los sistemas se
hacen ms abstractos). Hay varias razones para hacer usar triggers y procedimientos almacenados
pero eso es una tarea.
Por ahora se est empleando pl/pgsql; sin embargo, no es limitante, si alguno se aventura a usar
pl/ruby, pl/perl, pl/java o pl/python son libres de hacerlo. Las nica regla que se podran aplicar se
van a contemplar en los estandares de programacin.
Regla N 10: Vistas
Ms que una regla, el uso de vistas, es un consejo. Con las vistas se puede facilitar el cdigo que se
ve en el front-end. La experiencia que se tiene en el manejo de vistas no es muy amplia, pero se
sabe lo suficiente como para tenerlas en cuenta como herramienta en el desarrollo, sobretodo en el
manejo de reportes.
Por ahora esto es todo, de acuerdo a las experiencias que se tengan y sus aportes, estas reglas irn
creciendo.