Diseño de una Base de Datos

Análisis de las necesidades y/o problemáticas (ciclo de vida del sistema)

Un sistema de información es un sistema, automatizado o manual, que engloba a personas,
máquinas y/o métodos organizados para recopilar, procesar, transmitir datos que representan
información. Un sistema de información engloba la infraestructura, la organización, el
personal y todos los componentes necesarios para la recopilación, procesamiento,almacenamiento, transmisión, visualización, diseminación y organización de la información

Una base de datos no es más que un componente de un sistema de información. Por tanto, el
ciclo de vida del sistema de información incluye el ciclo de vida de la base de datos que forma
parte de él. En particular, desde el punto de vista de la base de datos, centraremos
principalmente nuestra atención en las siguientes actividades:
-
Definición del sistema
: Durante la etapa de análisis de requerimientos del
sistema, nos fijaremos especialmente en todos los requerimientos asociados a los
datos con los que ha de trabajar nuestro sistema.
-
Diseño de la base de datos
: El análisis de los requerimientos del sistema nos
permitirá organizar los datos con los que nuestro sistema habrá de trabajar. Este
proceso de diseño, que está íntimamente ligado a la futura base de datos de
nuestro sistema, lo descompondremos en tres fases:
·
Diseño conceptual
(descripción del esquema de la base de datos utilizando
un modelo de datos conceptual).
·
Diseño lógico
(descripción de la base de datos con un modelo de datos
implementable, como puede ser el caso del modelo relacional).
·
Diseño físico
(descripción de la base de datos a nivel interno, de acuerdo
con las características del sistema gestor de bases de datos que decidamos
utilizar).
-
Implementación de la base de datos
(la parte de la implementación del sistema
correspondiente a la creación de la base de datos).
-
Carga o conversión de los datos
: Como parte de la instalación o despliegue del
sistema, tendremos que introducir en la base de datos todos aquellos datos que
resulten necesarios para que las aplicaciones de nuestro sistema de información
puedan funcionar. Como parte de esta
inicialización
de la base de datos, puede
que resulte necesario extraer datos de otro sistema y convertirlos a un formato
adecuado para nuestro sistema (entre otras cosas, porque el esquema de nuestra
base de datos probablemente diferirá del esquema de las bases de datos de las que
se extraigan los datos necesarios para arrancar nuestro sistema).
-
Conversión de aplicaciones
: Si determinadas aplicaciones (que ya existiesen
anteriormente al diseño de nuestro sistema) han de seguir funcionando, dichas
aplicaciones deberán adaptarse al esquema de nuestra base de datos. Por tanto,
como parte del mantenimiento de dichas aplicaciones, tendremos que diseñar los
mecanismos adecuados para que estas aplicaciones puedan seguir funcionando
correctamente sobre una base de datos diferente a la base de datos sobre la que
fueron diseñadas inicialmente. A veces, podremos solucionar este problema
creando vistas adecuadas de nuestra base de datos para tales aplicaciones. Otras
veces, tendremos que modificar la implementación de las aplicaciones antiguas e,incluso, rehacerlas casi por completo
De las actividades descritas en los párrafos anteriores, todas ellas relacionadas directamente
con la base o bases de datos utilizadas en un sistema de información, estudiaremos a fondo las
correspondientes a las etapas iniciales del ciclo de vida de la base de datos. Antes de estudiar
técnicas concretas, no obstante, detallares algo más el proceso de diseño que utilizaremos paraconstruir correctamente una base de datos

Reglas de normalizacion de una base de datos

La normalización de bases de datos es un proceso que consiste en designar y aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional.

Las bases de datos relacionales se normalizan para:
Evitar la redundancia de los datos.
Disminuir problemas de actualización de los datos en las tablas.
Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea considerada como una relación tiene que cumplir con algunas restricciones:
Cada tabla debe tener su nombre único.
No puede haber dos filas iguales. No se permiten los duplicados.
Todos los datos en una columna deben ser del mismo tipo.

Claves de una Base de Datos

Primarias :

En el diseño de bases de datos relacionales, se llama clave primaria a un campo o a una combinación de campos que identifica de forma única a cada fila de una tabla. Una clave primaria comprende de esta manera una columna o conjunto de columnas. No puede haber dos filas en una tabla que tengan la misma clave primaria.
Ejemplos de claves primarias son DNI (asociado a una persona) o ISBN (asociado a un libro). Las guías telefónicas y diccionarios no pueden usar nombres o palabras o números del sistema decimal de Dewey como claves candidatas, porque no identifican unívocamente números de teléfono o palabras.
El modelo relacional, según se lo expresa mediante cálculo relacional y álgebra relacional, no distingue entre clave primaria y otros tipos de claves. Las claves primarias fueron agregadas al estándar SQL principalmente para conveniencia del programador. En una arquitectura entidad-relación, la clave primaria permite las relaciones de la tabla que tiene la clave primaria con otras tablas que van a utilizar la información de esta tabla.
Tanto claves únicas como claves primarias pueden referenciarse con claves foráneas.

Secundarias:
Todo conjunto de campos de una tabla que sirva para identificar univocamente 1 fila de otra, se llama Clave Candidata.
La menor de las Claves Candidatas, se le llama Clave Primaria.
Una Clave Secundaria es un orden que no necesariamente identifica una fila de otra (puede haber repeticiones), pero sirve para procesar la informacion en un orden adecuado, para algun proceso en particular. Por ejemplo, la Fecha de una factura es importante para listar los Libros de IVA o para filtrar facturas entre fechas, por ello se la establece como Clave Secundaria. Tambien los campos que hacen referencia a otras tablas son Claves Secundarias, aunque se les suele llamar, en ese caso, Claves Foraneas.  

Externas:
Una clave externa es un campo (o campos) que señala la clave primaria de otra tabla. El propósito de la clave externa es asegurar la integridad referencial de los datos. En otras palabras, sólo se permiten los valores que se esperan que aparezcan en la base de datos. 

Foràneas:
En el contexto de bases de datos relacionales, una clave foránea o clave ajena (o Foreign Key FK) es una limitación referencial entre dos tablas. La clave foránea identifica una columna o grupo de columnas en una tabla (tabla hija o referendo) que se refiere a una columna o grupo de columnas en otra tabla (tabla maestra o referenciada). Las columnas en la tabla referendo deben ser la clave primaria u otra clave candidata en la tabla referenciada.
Los valores en una fila de las columnas referendo deben existir solo en una fila en la tabla referenciada. Así, una fila en la tabla referendo no puede contener valores que no existen en la tabla referenciada. De esta forma, las referencias pueden ser creadas para vincular o relacionar información. Esto es una parte esencial de la normalización de base de datos. Múltiples filas en la tabla referendo pueden hacer referencia, vincularse o relacionarse a la misma fila en la tabla referenciada. Mayormente esto se ve reflejado en una relación uno (tabla maestra o referenciada) a muchos (tabla hija o referendo).
La tabla referendo y la tabla referenciada pueden ser la misma, esto es, la clave foránea remite o hace referencia a la misma tabla. Esta clave externa es conocida en SQL:2003 como auto-referencia o clave foránea recursiva. Una tabla puede tener múltiples claves foráneas y cada una puede tener diferentes tablas referenciadas. Cada clave foránea es forzada independientemente por el sistema de base de datos. Por tanto, las relaciones en cascada entre tablas pueden realizarse usando claves foráneas. Configuraciones impropias de las claves foráneas o primarias o no forzar esas relaciones son frecuentemente la fuente de muchos problemas para la base de datos o para el modelamiento de los mismos.
Por ejemplo, digamos que hay dos tablas, una tabla CONSUMIDOR que incluye todos los datos de los consumidores, y otra que es la tabla de ORDENES. La intención es que todas las órdenes estén asociadas a la información del consumidor y que viven en su propia tabla. Para lograr esto debemos colocar una clave foránea en la tabla ORDENES con relación a la llave primaria de la tabla CONSUMIDOR.
La clave foránea identifica una columna(s) en una TABLA REFERENCIANTE a una columna(s) en la TABLA REFERENCIADA.

Integridad Referencial :

La integridad referencial significa que la clave externa de una tabla de referencia siempre debe aludir a una fila válida de la tabla a la que se haga referencia. La integridad referencial garantiza que la relación entre dos tablas permanezca sincronizada durante las operaciones de actualización y eliminación.
Por ejemplo, supongamos que la aplicación tiene una tabla Titles y una tabla Publishers como se muestra en la siguiente tabla.

Tabla Titles	Tabla Publishers
isbn_ti (clave)	id_edit (clave)
título_ti	nombre_edit
añopublic_ti	dir_edit
id_edit (clave externa)	teléfono_edit

La integridad referencial requiere que estas dos tablas estén sincronizadas. Es decir, la identificación de cada editorial (id_edit) de la tabla Titles también debe aparecer en la tabla Publishers.
La aplicación no puede eliminar la fila id_edit de la tabla Publishers porque la fila id_edit de la tabla Titles se quedaría sin una referencia. Sin embargo, se podría permitir la eliminación de la fila id_edit de la tabla Publishers y eliminar también todas las filas de la tabla Titles que tengan la misma identificación id_edit. Con esta acción se mantendría la integridad referencial en ambas tablas.
De forma similar, la aplicación no puede añadir una fila a la tabla Titles si no existe ya una identificación válida id_edit en la tabla Publishers. Esta acción daría lugar a la inserción de datos "defectuosos" en el campo id_edit. De manera que la aplicación debe asegurarse de que haya una clave id_edit válida en la tabla Publishers antes de insertar la identificación id_edit en la fila de Titles relacionada.
La implementación real de la integridad referencial depende totalmente del motor de almacenamiento de datos que se elija y de los requisitos de diseño de la aplicación. Históricamente, las aplicaciones que utilizan archivos VSAM de gran sistema usaban código basado en aplicaciones para controlar la integridad referencial. Hoy en día, aunque la aplicación utilice SQL Server, eso no significa que se deban utilizar desencadenadores, claves externas, restricciones y eliminaciones en cascada para mantener la integridad referencial. Una vez más se puede elegir la opción de controlar aspectos relacionales con código basado en aplicaciones.

Indices y Disparadores 

El índice de una base de datos es una estructura de datos que mejora la velocidad de las operaciones, por medio de identificador único de cada fila de una tabla, permitiendo un rápido acceso a los registros de una tabla en una base de datos.

El índice tiene un funcionamiento similar al índice de un libro, guardando parejas de elementos: el elemento que se desea indexar y su posición en la base de datos. Para buscar un elemento que esté indexado, sólo hay que buscar en el índice dicho elemento para, una vez encontrado, devolver un registro que se encuentre en la posición marcada por el índice.
Los índices pueden ser creados usando una o más columnas, proporcionando la base tanto para búsquedas rápidas al azar como de un ordenado acceso a registros eficiente.
Los índices son construidos sobre árboles B, B+, B* o sobre una mezcla de ellos, funciones de cálculo u otros métodos.
El espacio en disco requerido para almacenar el índice es típicamente menor que el espacio de almacenamiento de la tabla (puesto que los índices generalmente contienen solamente los campos clave de acuerdo con los que la tabla será ordenada, y excluyen el resto de los detalles de la tabla), lo que da la posibilidad de almacenar en memoria los índices de tablas que no cabrían en ella. En una base de datos relacional un índice es una copia de una parte de la tabla.
Algunas bases de datos amplían la potencia del indexado al permitir que los índices sean creados de funciones o expresiones. Por ejemplo, un índice puede ser creado sobre la función upper(apellido), que almacenaría en el índice solamente las versiones mayúsculas del campo apellido. Otra opción a veces soportada, es el uso de índices "filtrados", donde las entradas del índice son creadas solamente para los registros que satisfagan una cierta expresión condicional. Un aspecto adicional de flexibilidad es permitir la indexación en funciones definidas por el usuario, también como expresiones formadas de un surtido de funciones incorporadas. Todos estos refinamientos de la indexación son soportados en Visual FoxPro y otros lenguajes de programación, por ejemplo.¹
Los índices pueden ser definidos como únicos o no únicos. Un índice único actúa como una restricción en la tabla previniendo filas idénticas en el índice.

Los Triggers o Disparadores son objetos que se asocian con tablas y se almacenan en la base de datos. Su nombre se deriva por el comportamiento que presentan en su funcionamiento, ya que se ejecutan cuando sucede algún evento sobre las tablas a las que se encuentra asociado. Los eventos que hacen que se ejecute un trigger son las operaciones de inserción (INSERT), borrado (DELETE) o actualización (UPDATE), ya que modifican los datos de una tabla.
La utilidad principal de un trigger es mejorar la administración de la base de datos, ya que no requieren que un usuario los ejecute. Por lo tanto, son empleados para implementar las REGLAS DE NEGOCIO (tipo especial de integridad) de una base de datos. Una Regla de Negocio es cualquier restricción, requerimiento, necesidad o actividad especial que debe ser verificada al momento de intentar agregar, borrar o actualizar la información de una base de datos. Un trigger puede prevenir errores en los datos, modificar valores de una vista, sincronizar tablas, entre otros.

Relaciones de una Base de Datos 

Existen relaciones de diferentes tipos. El tipo de relación que utiliza Access al unir
dos tablas dependerá de cómo estén definidos los campos relacionados.

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.
Relación de varios a varios (n,m). En este caso, ninguno de los campos relacionados son claves principales. Cada registro de la primera tabla puede estar enlazado con varios registros de la segunda y viceversa. Este tipo de relación implica la repetición de los campos de cada tabla; esto es lo que Access pretende evitar. Para establecer relaciones de este tipo, es necesario crear una tabla intermedia que esté relacionada con las dos de uno a varios.