Son muchas las consideraciones a tomar en cuenta al momento
de hacer el diseño de la base de datos, quizá las más fuertes sean:
- La velocidad de
acceso,
- El
tamaño de la información,
- El
tipo de la información,
- Facilidad
de acceso a la información,
- Facilidad
para extraer la información requerida,
- El comportamiento del
manejador de bases de datos con cada tipo de información.
No obstante que pueden desarrollarse sistemas de
procesamiento de archivo e incluso manejadores de bases de datos
basándose en la experiencia del equipo
de desarrollo de software logrando resultados altamente
aceptables, siempre es recomendable la utilización de determinados estándares
de diseño que garantizan el nivel de eficiencia más alto en lo que se refiere
a almacenamiento y recuperación de la información.
De igual manera se obtiene modelos que optimizan
el aprovechamiento secundario y la sencillez y flexibilidad en las consultas
que pueden proporcionarse al usuario.
OBJETIVOS DEL DISEÑO DE BASES DE DATOS
Entre las metas más importantes que se persiguen al diseñar
un modelo de bases de datos, se encuentran las siguientes:
- Almacenar Solo La Información Necesaria.
A menudo pensamos en todo lo que quisiéramos que estuviera
almacenado en una base de datos y diseñamos la base de datos para guardar
dichos datos. Debemos de ser realistas acerca de nuestras necesidades y decidir
qué información es realmente necesaria.
Frecuentemente podemos generar algunos datos sobre la marcha
sin tener que almacenarlos en una tabla de una base de datos. En estos casos
también tiene sentido hacer esto desde el punto de vista del desarrollo de la
aplicación.
- Normalizar la Estructura de las
Tablas.
Si nunca antes hemos oído hablar de la
"normalización de datos", no debemos temer. Mientras que la
normalización puede parecer un tema complicado, nos podemos beneficiar
ampliamente al entender los conceptos más elementales de la normalización.
Una de las formas más fáciles de entender esto es pensar en
nuestras tablas como hojas de cálculo. Por ejemplo, si quisiéramos seguir
la pista de nuestra colección de CD’s en una hoja de cálculo, podríamos
diseñar algo parecido a lo que se muestra en la siguiente tabla.
Esto parece razonable. Sin embargo el problema es que el
número de pistas que tiene un CD varía bastante. Esto significa que con
este método tendríamos que tener una hoja de cálculo realmente
grande para albergar todos los datos, que en los peores casos podrían ser de
hasta 20 pistas. Esto en definitiva no es nada bueno.
Uno de los objetivos de una estructura de tabla
normalizada es minimizar el número de "celdas vacías". El darnos
cuenta de que cada lista de CD’s tiene un conjunto fijo de campos (título,
artista, año, género) y un conjunto variable de atributos (el número de
pistas) nos da una idea de cómo dividir los datos en múltiples tablas que luego
podamos relacionar entre sí.
Mucha gente no está familiarizada con el concepto "relacional",
de manera sencilla esto significa, que grupos parecidos de
información son almacenados en distintas tablas que luego pueden ser
"juntadas" (relacionadas) basándose en los datos que tengan en común.
Es necesario que al realizar la estructura de una base de
datos, esta sea flexible. La flexibilidad está en el hecho que podemos agregar
datos al sistema posteriormente sin tener que rescribir lo que ya tenemos.
Por ejemplo, si quisiéramos agregar la información de los artistas de cada
álbum, lo único que tenemos que hacer es crear una tabla artista que esté
relacionada a la tabla álbum de la misma manera que la tabla pista. Por lo tanto,
no tendremos que modificar la estructura de nuestras tablas actuales,
simplemente agregar la que hace falta.
La eficiencia se refiere al hecho de que no tenemos
duplicación de datos, y tampoco tenemos grandes cantidades de "celdas
vacías".
El objetivo principal del diseño de bases de datos
es generar tablas que modelan los registros en los que guardaremos nuestra
información.
Es importante que esta información se almacene sin
redundancia para que se pueda tener una recuperación rápida y eficiente de los datos.
A través de la normalización tratamos de evitar ciertos
defectos que nos conduzcan a un mal diseño y que lleven a un procesamiento
menos eficaz de los datos.
Podríamos decir que estos son los principales objetivos de
la normalización:
- Controlar
la redundancia de la información.
- Evitar
pérdidas de información.
- Capacidad
para representar toda la información.
- Mantener
la consistencia de los datos
- Seleccionar el Tipo de Dato Adecuado.
Una vez identificadas todas las tablas y columnas que
necesita la base de datos, debemos determinar el tipo de dato de cada campo.
Existen tres categorías principales que pueden aplicarse prácticamente a
cualquier aplicación de bases de datos:
- Texto
- Números
- Fecha
y hora
Cada uno de éstos presenta sus propias variantes, por lo que
la elección del tipo de dato correcto no sólo influye en el tipo de información
que se puede almacenar en cada campo, sino que afecta al rendimiento global de
la base de datos.
A continuación se dan algunos consejos que nos ayudarán a
elegir un tipo de dato adecuado para nuestras tablas:
- Identificar
si una columna debe ser de tipo texto, numérico o de fecha.
- Elegir
el subtipo más apropiado para cada columna.
- Configurar
la longitud máxima para las columnas de texto y numéricas, así como otros
atributos.
- Utilizar Índices Apropiadamente
Los índices son un sistema especial que utilizan las bases
de datos para mejorar su rendimiento global. Dado que los índices hacen que las
consultas se ejecuten más rápido, podemos estar incitados a indexar todas las
columnas de nuestras tablas.
Sin embargo, lo que tenemos que saber es que el usar índices
tiene un precio. Cada vez que hacemos un INSERT, UPDATE, REPLACE, o DELETE
sobre una tabla, MySQL tiene que actualizar cualquier índice en la
tabla para reflejar los cambios en los datos.
¿Así que, cómo decidimos usar índices o no? La respuesta es
"depende". De manera simple, depende que tipo de consultas ejecutamos
y que tan frecuentemente lo hacemos, aunque realmente depende de muchas otras
cosas.
Así que antes de indexar una columna, debemos considerar que
porcentaje de entradas en la tabla son duplicadas. Si el porcentaje es
demasiado alto, seguramente no veremos alguna mejora con el uso de un índice.
Ante la duda, no tenemos otra alternativa que probar.
·
Recomendaciones.
El último paso del diseño de la base de datos es adoptar
determinadas convenciones de nombres. Aunque MySQL es muy flexible en cuanto a
la forma de asignar nombre a las bases de datos, tablas y columnas, he aquí
algunas reglas que es conveniente observar:
- Utilizar
caracteres alfanuméricos.
- Limitar
los nombres a menos de 64 caracteres (es una restricción de MySQL).
- Utilizar
el guion bajo (_) para separar palabras.
- Utilizar
palabras en minúsculas (esto es más una preferencia personal que una
regla).
- Los
nombres de las tablas deberían ir en plural y los nombres de las columnas en
singular (es igual una preferencia personal).
- Utilizar
las letras ID en las columnas de clave primaria y foránea.
- En
una tabla, colocar primero la clave primaria seguida de las claves foráneas.
- Los
nombres de los campos deben ser descriptivos de su contenido.
- Los
nombres de los campos deben ser unívocos entre tablas, excepción hecha de las
claves.
Los puntos anteriores corresponden muchos de ellos a
preferencias personales, más que a reglas que debamos de cumplir, y en
consecuencia muchos de ellos pueden ser pasados por alto, sin embargo, lo más
importante es que la nomenclatura utilizada en nuestras bases de
datos sea coherente y consistente con el fin de minimizar la posibilidad de
errores al momento de crear una aplicación de bases de datos.
