Documentos de Académico
Documentos de Profesional
Documentos de Cultura
El modelado de datos no acaba con el uso de esta técnica. Son necesarias otras
técnicas para lograr un modelo directamente implementable en una base de datos.
Brevemente:
Diseño Conceptual
Durante esta fase, plasmaremos nuestras entidades y las relaciones que existirán
entre ellas. Cada entidad la identificaremos con un rectángulo y dentro de este
colocaremos su nombre. A cada entidad le colocaremos sus respectivos atributos y
resaltaremos el atributo principal, aquel atributo que identificará cada registro de
manera única. Y por último crearemos las relaciones que existen entre dichas
entidades.
Aquí no te preocupas por el motor de bases de datos aún.
Diseño Lógico
Aquí podemos tabular nuestro diseño conceptual. Este proceso es más utilizado
que el anterior (no debería ser así), ya que cuando ya llevas bastante trabajando en
bases de datos, el proceso tabular es más rápido de realizar y vemos resultados
más rápidamente. En esta fase, debemos pensar en cómo normalizar nuestras
tablas para evitar duplicidad de información y para ahorrar espacio de
almacenamiento. Esto último (ahorrar espacio) ya no es tan importante como hace
algunos años, incluso hoy en día hablamos de inteligencia de negocios, minería de
datos, entre otros términos que nos exigen eliminar la normalización, pero de eso
hablaremos en otros posts. Para este proceso, las herramientas de modelado te
ayudan bastante a ver las relaciones de las tablas. En teoría, aquí tampoco te
preocupas por el motor, ya que el modelo tabular es igual en todos los motores de
bases de datos relacionales.
Diseño físico
En esta última fase ya debemos revisar a detalle los tipos de datos que utilizaremos,
sus dominios (qué valores va a permitir), cuales índices debemos crear para
optimizar las consultas, entre otros. Aquí ya escribimos nuestro SQL para plasmar
todo nuestro diseño en el motor de bases de datos elegido.
Tipos de Campos
Cada Sistema de Base de Datos posee tipos de campos que pueden ser similares
o diferentes. Entre los más comunes podemos nombrar:
Normalización
En principio, la información de una base de datos relacional podría guardarse sin
problemas en una sola tabla, con la ventaja de que no sería necesario interconectar
diversas tablas ni utilizar la compleja sintaxis derivada de las consultas a varias
tablas diferentes. Sin embargo, es aquí precisamente donde reside la fuerza del
modelo relacional, pues el reparto de información en varias tablas contribuye a
reducir las entradas dobles (las llamadas anomalías), un proceso que se conoce
como “normalización”. El grado de normalización de una tabla puede definirse a
partir de varias formas normales:
Los requisitos de cada una de estas formas normales y la translación de una base
de datos de una forma normal a otra son temas de nuestro artículo sobre la
normalización.
Claves: los atributos que sirven para identificar un registro de forma inequívoca.
BIN - Binary (stores data as binary strings. There is no character set so sorting
and comparison is based on the numeric values of the bytes in the values.)
[Almacena datos como strings binaries. No hay personaje elejido para
ordenar y comparar si se basa en valores numéricos de bytes en los valores.]
ZF - ZF - Zero-Filled (if the length is 5 like INT (5) then every field is filled with
0’s to the 5th digit. 12 = 00012, 400 = 00400, etc.) [Si la longitud es 5 como
INT (5) entonces cualquier campo es llenado con 0´s hasta el 5to digito.]
AI - Auto Increment (El valor del campo es incrementado automáticamente,
ocurre en toda la columna.)
NN - NOT NULL (No permite que el campo quede sin dato, no nulo.)
Relación de uno a varios (1,n). Se crea una relación de uno a varios si uno
de los campos relacionados es una clave principal. Esta relación es la más
común. Cada registro de una tabla puede estar enlazado con varios registros
de una segunda tabla, pero cada registro de la segunda sólo puede estar
enlazado con un único registro de la primera.
Relación de uno a uno (1,1). Se creará una relación de este tipo si ambos
campos relacionados son claves principales. En este tipo de relación, un
registro de la tabla uno sólo puede estar relacionado con un único registro de
la tabla dos y viceversa. No es muy usada.