DISEÑO DE UNA BASE DE DATOS

El ciclo de vida de un sistema de información

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.

El ciclo de vida de una base de datos

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

30

Diseño de Bases de Datos

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.

-

Verificación y validación

: Como en todo sistema de información, deberemos

verificar que la base de datos y las aplicaciones funcionan correctamente.

Además, deberemos comprobar que el sistema construido se ajusta a las

necesidades reales que promovieron su proyecto de desarrollo (esto es, validar el

sistema y sus requerimientos).

-

Operación, supervisión y mantenimiento

: Finalmente, una vez puesto en

marcha el sistema, se llega a la etapa "final" del ciclo de vida de todo sistema de

información (en la que, como ya vimos, se repetirá todo el ciclo cada vez que

tengamos que realizar modificaciones sobre el sistema ya existente).

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 para

construir correctamente una base de datos.

El proceso de normalización de una base de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo E-R (entidad-relación) al modelo relacional.

Objetivo de la normalización

Las bases de datos relacionales se normalizan para:

• Evitar la redundancia de los datos.
• Evitar 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 bidimensional sea considerada como una relación tiene cumplir con algunas restricciones:

• Cada columna 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.

Terminología equivalente

• relación = tabla o archivo
• tupla = registro, fila o renglón
• atributo = campo o columna
• base de datos = banco de datos
• dependencia multivaluada = dependencia multivalor
• clave = llave
• clave primaria = superclave
• clave ajena = clave extranjera o clave foránea
• RDBMS = del inglés Relational Data Base Manager System que significa, Sistema Gestor de Base de Datos Relacionales

Dependencia funcional Una dependencia funcional son conexiones entre uno o más atributos. Por ejemplo si conocemos el valor de FechaDeNacimiento podemos conocer el valor de Edad.

Las dependencias funcionales se escriben utilizando una flecha, de la siguiente manera:

FechaDeNacimiento->Edad

Aquí a FechaDeNacimiento se le conoce como un determinante. Se puede leer de dos formas FechaDeNacimiento determina a Edad o Edad es funcionalmente dependiente de FechaDeNacimiento. De la normalización (lógica) a la implementación (física o real) puede ser sugerible tener éstas dependencias funcionales para lograr mayor eficiencia en las tablas.

Dependencia funcional transitiva Supongamos que los estudiantes solo pueden estar matriculados en un solo curso y supongamos que los profesores solo pueden dar un curso. ID_Estudiante -> Curso_Tomando Curso_Tomando -> Profesor_Asignado ID_Estudiante -> Curso_Tomando -> Profesor_Asignado

Entonces tenemos que ID_Estudiante determina a Curso_Tomando y el Curso_Tomando determina a Profesor_Asignado, indirectamente podemos saber a través del ID_estudiante el Profesor_Asignado. Entonces tenemos una dependencia transitiva.

Claves

Clave ajena

Cuando se tienen dos tablas o más, una clave ajena es aquella columna de una tabla que hace referencia a una clave primaria de otra tabla.

También existe el caso de Relaciones Autoreferenciales. Sucede cuando en la misma relación se tiene una clave ajena que hace referencia a la clave primeria de la misma relación. Por otro lado las claves ajenas pueden tomar valores nulos.

Regla de Integridad Referencial

La base de datos no debe conter valores de clave ajena sin concordancia. Así como los valores de clave primaria representan identificadores de entidades, las claves ajenas representan referencia a entidades.

La regla dice: Si B hace referencia a A entonces A debe existir. Surgen los siguientes dos puntos:

• La integridad referencial exige concordancia en las claves ajenas, con las claves primerias, no con la claves alternativas.
• Los conceptos de clave ajena e integridad referencial se definen uno en termino del otro.

Clave candidata

Por lo general la forma más eficiente y segura para escoger o hacer la clave primaria es poniendo un número y aumentando éste a medida que se van añadiendo filas, pero si de casualidad se diera el caso de que existan varias claves candidatas de las cuales se deba escoger la clave primaria, esta elección se hace utilizando el sentido común.

Claves alternativas

Son aquellas claves candidatas que no han sido elegidas.

Clave simple

Es una clave que esta compuesta solo de un atributo.

Clave compuesta

Es una clave que esta compuesta por más de un atributo.

Formas Normales

Las primeras tres formas normales son suficientes para cubrir las necesidades de la mayoría de las bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar F. Codd, éste introdujo la normalización en un artículo llamado A Relational Model of Data for Large Shared Data Banks.

Primera Forma Normal (1FN)

Sea α un conjunto de atributo perteneciente (Є) a la relación R, en donde R está en la Primera Forma Normal si todos los atibutos α[n] son atómicos, es decir no pueden seguir dividiéndose. Por ejemplo:

La Relación:

cursos: nombre, código, vacantes, horario, bibliografía

Queda después de aplicar la Forma Normal 1 de la siguiente manera:

cursos1: nombre, código, vacantes horario1: código, día, módulo bibliografia1: código, nombre, autor

Segunda Forma Normal (2FN)

Dependencia completa. Esta en 2FN si esta en 1FN y si sus atributos no principales dependen de forma completa de la clave principal.

Tercera Forma Normal (3FN)

Está en segunda forma normal y todo atributo no primo es implicado por la clave primaria en una secuencia no transitiva.Se eliminan las dependencias transitivas.

Forma normal de Boyce-Codd (FNBC)

Una tabla está en FNBC sí y sólo sí las únicas dependencias funcionales elementales son aquellas en las que la clave primaria determinan un atributo.

Cuarta Forma Normal (4FN)

Está en forma normal de Boyce-Codd y se eliminan las dependencias multivaluadas y se generan todas las relaciones externas con otras tablas u otras bases de datos.

Quinta Forma Normal (5FN)

Está en cuarta forma normal y toda dependencia-join viene implicada por claves candidatas.

La integridad referencial es un sistema de reglas que utilizan la mayoría de las bases de datos relacionales para asegurarse que los registros de tablas relacionadas son válidos y que no se borren o cambien datos relacionados de forma accidental produciendo errores de integridad. Primero repasemos un poco los tipos de relaciones.

Tipos de relaciones.

Entre dos tablas de cualquier base de datos relacional pueden haber dos tipos de relaciones, relaciones uno a uno y relaciones uno a muchos: Relación Uno a Uno:  Cuando un registro de una tabla sólo puede estar relacionado con un único registro de la otra tabla y viceversa. Por ejemplo: tenemos dos tablas una de profesores y otra de departamentos y queremos saber qué profesor es jefe de qué departamento, tenemos una relación uno a uno entre las dos tablas ya que un departamento tiene un solo jefe y un profesor puede ser jefe de un solo departamento.            Relación Uno a Varios: Cuando un registro de una tabla (tabla secundaria) sólo puede estar relacionado con un único registro de la otra tabla (tabla principal) y un registro de la tabla principal puede tener más de un registro relacionado en la tabla secundaria, en este caso se suele hacer referencia a la tabla principal como tabla 'padre' y a la tabla secundaria como tabla 'hijo', entonces la regla se convierte en 'un padre puede tener varios hijos pero un hijo solo tiene un padre (regla más fácil de recordar). Por ejemplo: tenemos dos tablas una con los datos de diferentes poblaciones y otra con los habitantes, una población puede tener más de un habitante, pero un habitante pertenecerá (estará empadronado) en una única población. En este caso la tabla principal será la de poblaciones y la tabla secundaria será la de habitantes. Una población puede tener varios habitantes pero un habitante pertenece a una sola población. Esta relación se representa incluyendo en la tabla 'hijo' una columna que se corresponde con la clave principal de la tabla 'padre', esta columna es lo denominamos clave foránea (o clave ajena o clave externa). Una clave foránea es pues un campo de una tabla que contiene una referencia a un registro de otra tabla. Siguiendo nuestro ejemplo en la tabla habitantes tenemos una columna población que contiene el código de la población en la que está empadronado el habitante, esta columna es clave ajena de la tabla habitantes, y en la tabla poblaciones tenemos una columna codigo de poblacion clave principal de la tabla.