Cmo crear un modelo relacional de datos

Te asignaron la creacin de un modelo de datos empresarial?

Necesitas construir una base de datos relacional que pueda albergar
terabytes de datos?

1
No te preocupes por las tablas an. Obviamente ests creando una
base de datos, y las bases de datos (al menos las relacionales) estn
compuestas principalmente por tablas, que a su vez estn compuestas
de filas y columnas (registros y atributos, para los que conocen).

2
Preocpate por las relaciones entre entidades. Tu primera meta es
hacer un mapa de las relaciones que tendrn los distintos objetos
comerciales. Es la parte de modelado lgico. El modelo fsico es la
implementacin prctica. No confundas ni combines los dos.
o Los requisitos son difciles de conseguir y dolorosos. Un
analista comercial talentoso en esos momentos sera un regalo del
cielo.

3
Preprate para librar una guerra en solitario, dedicndote solo t a la
normalizacin de calidad. La mayora de las bases de datos son un
desperdicio porque sus diseadores son perezosos y slo quieren
conseguir algo. Siempre se puede arreglar ms adelante . S, claro.
4
Una vez que llegue el momento de escribir las tablas, concntrate en
las bsquedas y en los tipos de tablas (cdigos postales, estados,
categoras de productos, etc.). Las necesitars para relaciones clave
exteriores en las tablas verdaderas. Adems, te dar un
precalentamiento antes de llegar a las tablas transaccionales
centrales.

5
Como regla general: no almacenes datos que puedan inferirse de otros
campos. Si conoces la fecha de nacimiento y la fecha de inicio, tambin
conocers la edad en la fecha de inicio; no incluyas esta edad en la
tabla.

6
Ningn NULL. Un valor NULL (nulo) representa un atributo indefinido de
una identidad. Si una entidad puede tener o no un atributo en particular,
entonces necesita ser manipulada mediante una tabla cruzada.

7
Los valores NULL contradictorios son tiles en s mismos para
identificar atributos que an no hayan sido completados por los
usuarios. Esto es particularmente til cuando un usuario necesita
seleccionar un valor predeterminado para determinar la aplicacin de
las reglas comerciales adecuadas. En el caso 2, cmo disearas una
tabla de direcciones en la que Direccin1 fuera completada y
Direccin2 no fuera necesaria, pero si Direccin2 fuera completada
debera conformarse a las reglas comerciales del campo? Seguro,
podras poner como predeterminado un espacio en blanco, pero es
mejor que saber que el usuario no edit el campo? Prueba con un tercer
formulario normal en una direccin internacional... Probablemente se
pueda hacer, pero observa la complejidad de la reestructuracin de los
datos en una forma significativa.

8
NULL/NOT NULL Revisa los foros de bases de datos, y vers que es un
tema popular en el que hay defensores de las ventajas y desventajas de
cada uno.
o Sin embargo, todos coinciden en que nunca deberas permitir
valores NULL en variables clave. Estos son los campos que se usan
para identificar un registro nico, como puede ser el nmero de
identificacin del cliente.
o La escuela NULL dice que deberas usar libremente los
valores NULL en los dems campos. Por ejemplo, no es obligatorio
que los clientes tengan un telfono celular, ni que te den el nmero.
Usar un valor NULL y nada ms que NULL es la manera ms
eficiente de registrar que no hay un telfono celular disponible.
o Si es realmente importante saber por qu no hay un valor, lo
mejor es introducir una variable nueva que indique el motivo, en vez
de introducir algn cdigo extravagante para almacenar en lugar del
nmero de telfono celular. Evita agregar campos como esos,
porque a) el cliente tampoco est obligado a decirte el motivo por el
que no te da su nmero de telfono celular, ni es una buena
pregunta, y tampoco te dir espontneamente la razn, y b) nunca
 nadie lo mirar justamente debido a a). Las variables faltantes slo
desperdician tiempo.
o Ten cuidado con las variables s/no (booleanas), ya que en
general no pueden contener un NULL. Por lo tanto, suelen contener
informacin intil, como o era republicano, o se rehus a contestar.

9
Familiarzate con las tablas cruzadas (muchos a muchos). Las usars en
todas partes, si ests haciendo bien las cosas. Un ejemplo sera una
base de datos de una escuela en la que hay una tabla para los maestros
y otra para los estudiantes. Los estudiantes tienen ms de un maestro,
y los maestros tienen ms de un estudiante, por lo que la tabla cruzada,
aparte de las de 'maestros' y 'alumnos', tendra dos columnas con
claves externas apuntando a las dos. La clave primaria sera la
combinacin de esas dos.

10
Usa una buena convencin para los nombres. Coloca las facturas en
una tabla llamada factura. Los productos van en producto. La tabla
cruzada sera facturaProducto, o productoFactura, dependiendo de cul
tabla sea el verdadero centro de la relacin.

11
Si vas a hacer replicaciones o envos de registros, prueba configurar
mientras lo desarrollas para ver cmo funciona.

12
Las uniones internas son muy buenas, pero probablemente tambin
haya muchas declaraciones de UNIONES EXTERNAS SOBRANTES con
las que podra funcionar. Acostmbrate a las distintas declaraciones de
uniones (excepto UNION).

13
Si tienes que lidiar con una aplicacin heredada, construye tu esquema
independientemente de eso (ni siquiera lo mires). Concntrate en las
reglas y relaciones comerciales que intentas ejecutar, pero podras
distraerte si miras la forma en la que alguien ms la configur.
Refirete al paso #4.

14
Es difcil migrar desde un sistema de herencia hacia un modelo ms
ajustado con una normalizacin apropiada, pero se puede facilitar un
poco si se usan tablas temporales para las importaciones. Adems,
conserva fichas en los ID de herencia para que la gente pueda
buscarlos.

Consejos
No esperes replicaciones, envos de registros ni reflejos para
trabajar cuando pases a la produccin. Desarrolla y prueba desde el
inicio. Que sea parte de tu aplicacin.
Hay algunos casos extremadamente especficos en los que
necesitars desnormalizar las tablas por cuestiones de rendimiento.
Pero eso es fcil de hacer; concntrate en la parte difcil, que es
crear una normalizacin correcta.
La flexibilidad y la potencia de un modelo relacional son
sorprendentes en comparacin a las estructuras ms planas.
Como ests definiendo relaciones absolutas, una buena forma de
obtener preguntas de participantes reacios es formular cosas
como As que es absolutamente cierto que slo puede haber un
cliente en una factura? Preguntas como esa tienden a provocar una
respuesta en las personas.
Con respecto a las relaciones de entidades, por ejemplo, un
cliente podra tener muchos nmeros de telfono. El cliente tambin
podra tener muchos contactos, y cada uno de ellos tener muchos
nmeros de telfono. Pero una factura slo puede asociarse con un
cliente. Hay un representante de cuenta que puede asignarse a un
cliente, excepto en ciertos casos en los que hay dos, etc. stos son
los tipos de cosas que debes definir antes de escribir ninguna lnea
de cdigo sql.
Deja las s fuera de los nombres de tabla (tabla factura); se
entiende que como es una base de datos, probablemente haya ms
de una factura adentro.
Tambin son importantes las copias de respaldo en el desarrollo.
Asegrate de hacer una al menos cada noche. Verifcalas todas las
semanas para asegurarte de no perder meses de trabajo (y
probablemente tambin tu empleo) en caso de que haya una falla
masiva de hardware.

Advertencias
Si intentas ahorrar cdigo (valores NULL, tablas desnormalizadas
por los motivos equivocados), habr consecuencias directas y reales
 (hurfanos, compromiso de la integridad de los datos, uniones que
no funcionan, etc.).
El modelado de datos es una habilidad crtica y hay muy pocas
personas que construyen bases de datos relacionales de manera
correcta.
No ahorres cdigo porque te resulte ms fcil. Si quieren algo
inservible, deberan haber contratado a otra persona.
Si no normalizas correctamente, los informes hechos a partir de la
base de datos sern totalmente incorrectos y tu jefe se enfadar
mucho.