Ticb2 - Diseño de Bbdd i

www.haztefuncionario.com

Material registrado. Prohibida su reproducción.

Copia exclusiva de José Ignacio Méndez Yanes. Av de los Poblados 133, 7º - 3ª - 28025 - Madrid - Tel. 917464968

B2G2T04 - DISEÑO DE BASE DE DATOS I.

1.

INTRODUCCIÓN.............................................................................................................................................................. 2 1.1. 1.2.

2.

EVOLUCIÓN HISTÓRICA......................................................................................................................................... 2 VENTAJAS E INCONVENIENTES ........................................................................................................................... 3

LA ARQUITECTURA ANSI/SPARC.............................................................................................................................. 3 2.1 UN POCO DE HISTORIA ........................................................................................................................................... 4 2.2 DESCRIPCIÓN DE LA ARQUITECTURA A TRES NIVELES................................................................................. 4 2.3 ANSI: MODELO DE REFERENCIA .......................................................................................................................... 5 2.4 DESCRIPCIÓN DEL MODELO DE REFERENCIA ................................................................................................. 6 2.4.1 FUNCIONES DE ADMINISTRACIÓN ................................................................................................................ 6 2.4.2 DEFINICIÓN DE LAS ESTRUCTURAS DE DATOS........................................................................................... 7 2.5 ENTORNO DE UN SGBD........................................................................................................................................... 7

3.

EL MODELO LÓGICO RELACIONAL ........................................................................................................................ 7 3.1. CONCEPTOS Y ESTRUCTURA DEL MODELO RELACIONAL............................................................................ 8 3.2 RESTRICCIONES ....................................................................................................................................................... 8 3.2.1 RESTRICCIONES INHERENTES ........................................................................................................................ 9 3.2.2 RESTRICCIONES EXPLÍCITAS .......................................................................................................................... 9 3.3 LENGUAJES RELACIONALES............................................................................................................................... 10 3.3.1 ALGEBRA RELACIONAL .................................................................................................................................. 10 3.3.2 CALCULO RELACIONAL.................................................................................................................................. 11 3.4 BASES DE DATOS RELACIONALES..................................................................................................................... 11

4.

NORMALIZACIÓN ........................................................................................................................................................ 13 4.1 INTRODUCCIÓN...................................................................................................................................................... 13 4.2 DESCRIPCIÓN.......................................................................................................................................................... 13 4.2.1 PRIMERA FORMA NORMAL (1FN) ................................................................................................................. 13 4.2.2 SEGUNDA FORMA NORMAL (2FN)................................................................................................................ 14 4.2.3 TERCERA FORMA NORMAL (3FN) ................................................................................................................. 14 4.3 NOTACIÓN ............................................................................................................................................................... 14 4.4 OTRAS FORMAS NORMALES ............................................................................................................................... 18 4.4.1 FORMA NORMAL DE BOYCE-CODD (FNBC) ............................................................................................... 18 4.4.2 CUARTA FORMA NORMAL (4FN) ................................................................................................................... 18 4.4.3 QUINTA FORMA NORMAL (5FN).................................................................................................................... 18

5.

CONCLUSIÓN ................................................................................................................................................................. 18

6.

BIBLIOGRAFÍA .............................................................................................................................................................. 18

7.

ESQUEMA – RESUMEN ................................................................................................................................................ 19

TEMARIO-TICB-feb04 Actualizado en febrero de 2004

B2G2T04 Página 1 de 21




1.

INTRODUCCIÓN

En las Empresas y Organizaciones de hoy en día el Sistema de Información es un sistema más al servicio de aquellas y de sus objetivos, en ningún caso independiente de sus estrategias y, como algunos autores afirman, formando parte de sus infraestructuras. La implantación del Sistema de Información en las Empresas y Organizaciones utilizando las Tecnologías de la Información no ha sido un camino fácil de recorrer por diversas razones, entre las que hay que destacar la siguiente y más evidente: “No es posible hacer lo mismo que antes y de la misma manera, sólo que utilizando unas tecnologías diferentes, porque la tecnología no es neutral y aporta su propia idiosincrasia”. Una de las aportaciones más relevantes que, en las últimas décadas, ha supuesto la informática para los Sistemas de Información es el concepto de Base de Datos al menos por los siguientes motivos:

Incorpora una visión global del conjunto de datos de una organización o empresa, en cuyo diseño todos los departamentos de las mismas deben estar de acuerdo.

Estructura el Sistema de Información alrededor de la Base de Datos considerada ahora como el Núcleo del Sistema.

En los últimos años la evolución de los Sistemas de Información ha sido realmente notable, haciéndose cada vez mayores las exigencias de prestaciones de información almacenada en el Sistema, lo que ha supuesto un avance continuado de la tecnología de las Bases de Datos y un fuerte impacto económico sobre las organizaciones que han aplicado esta tecnología.

1.1.

EVOLUCIÓN HISTÓRICA

En el comienzo de la informática los datos estaban integrados en los programas de aplicación como constantes. Posteriormente aparecieron los ficheros. En ellos ya podemos diferenciar aunque de manera incipiente la estructura lógica, que representa el punto de vista del usuario, y la estructura física de los datos referida al soporte en el que se almacenaban. En base a lo anterior la definición de ficheros independientes del resto del programa podía llevarse a cabo por medio del lenguaje de programación. De este modo, se facilitaba el acceso y correspondiente actualización de los ficheros de datos, evitando asimismo la programación de muchas tareas repetitivas Con todo, el nivel de diferenciación alcanzado entre las estructuras lógica y física no era suficiente para evitar la dependencia de los programas respecto de los datos y viceversa, y de ambos respecto de la máquina en la que se ejecutaban los programas. En la década de los años 60 nacen los primeros Sistemas de Gestión de Bases de Datos SGBD. Los sistemas dejan de estar orientados hacia los procesos o tratamientos y se orientan hacia las Bases de Datos. Los datos y sus correspondientes interrelaciones se integran en las Bases de Datos y se aíslan de las aplicaciones o programas. La estructura lógica se hace más flexible y sencilla y la estructura física, por el contrario, se complica buscando mejorar el rendimiento. La Arquitectura de los primeros SGBD comprendía, pues, dos niveles:

Estructura Global (características lógicas y físicas): Esquema.

Vistas Lógicas Externas de los usuarios: Subesquemas.






1.2.

VENTAJAS E INCONVENIENTES

Las ventajas de los sistemas de Bases de Datos más destacables son las siguientes:

En relación con los datos: à

Independencia de los datos respecto de los tratamientos o programas y viceversa, lo que evita un esfuerzo notable de reprogramación de las aplicaciones cuando se producen cambios en la estructura de los datos.

à

Disminución de las redundancias.

à

Mayor y mejor disponibilidad para el conjunto de los usuarios.

à

Elevada eficiencia en la recogida, codificación y entrada en el sistema.

à

Protección de los datos.

En relación con los resultados: à

Mayor coherencia.

à

Mayor valor informativo.

à

Mayor eficiencia.

à

Mejor y más normalizada documentación de la información.

En relación con los usuarios: à

Acceso rápido y sencillo para los usuarios finales

à

Facilidades de compartición de datos.

No obstante también hay que indicar algunos inconvenientes:

2.

Instalación costosa.

Requiere habitualmente personal muy especializado.

Falta de rentabilidad a corto plazo.

Resistencia al cambio en algunas organizaciones.

LA ARQUITECTURA ANSI/SPARC

Las Bases de Datos requieren un software de gestión que facilite las operaciones y la interfaz con los usuarios. Este software es el que ya hemos denominado Sistema de Gestión de Bases de Datos SGBD. Para definirlo con mayor precisión podemos utilizar la definición de A. de Miguel (1985): “Conjunto coordinado de programas, procedimientos, lenguajes, etc., que suministra, tanto a los usuarios no informáticos, como a los analistas, programadores, o al administrador, los medios necesarios para describir y manipular los datos integrados en la base, manteniendo su integridad, confidencialidad y seguridad.” A destacar en este software dos tipos de lenguaje:

DLL (Data Definition Language, Lenguaje de definición de datos): Proporciona facilidades para poder crear tablas, columnas, etc.

DML (Data Manipulation Language, Lenguaje de manipulación de datos): Suministra facilidades para poder consultar y actualizar (altas, bajas y modificaciones) los datos existentes en la Base de Datos.






2.1

UN POCO DE HISTORIA

Desde principios de los años 70 el Comité ANSI/X3/SPARC (American National Standards Institute, grupo de estudio Standards Planning and Requirementes Committee) se ocupaba de la normalización de los SGBD. Después de una serie de informes parciales, publica en 1975 un informe provisional ANSI (1975), donde propone la arquitectura a 3 niveles. Un informe posterior ANSI (1977) revisa y detalla esta arquitectura. Prosiguen los trabajos y en Mayo de 1985 aparece un nuevo informe del DAFTG (Database Architecture Framework TaskGroup) subgrupo del DBSSG (Database System Study Group) en donde se presenta el Modelo de Referencia para la estandarización de los SGBD (ANSI-1986). Todos estos informes resultaron claves para la evolución de los SGBD, siempre con el objetivo de conseguir una total independencia entre datos y programas de aplicación.

2.2

DESCRIPCIÓN DE LA ARQUITECTURA A TRES NIVELES

Lo que propuso ANSI/SPARC en 1975 es que las bases de datos se construyan siguiendo un modelo o arquitectura de tres niveles: nivel externo, nivel conceptual y nivel interno o físico. Estos tres niveles están organizados de forma jerárquica, siendo el nivel interno el más cercano a la máquina y el nivel externo aquél con el que interactúa el usuario. Ver la representación de la figura 1:






La arquitectura interna del SGBD de este modelo presenta en su interior tres niveles perfectamente diferenciados:

El Nivel Físico se encarga de tratar con el software más interno de cada máquina (Sistema Operativo y Sistema de Gestión de Ficheros). El Esquema Interno especifica cómo son almacenados los datos. Describe la estructura de la Base de Datos en forma de Modelo Conceptual de almacenamiento.

El Nivel Conceptual materializa el lugar donde definir el resultado del diseño de la Base de Datos. El Esquema Conceptual debe captar y almacenar el “universo del discurso” que describe a la organización o empresa y que es necesaria para su funcionamiento. Sirve de punto de partida para futuros desarrollos de la Base de Datos. Aísla la representación de la información de los requerimientos de la máquina y de las exigencias de cada usuario en particular.

El Nivel Lógico o externo de descripción, contiene las vistas externas de la Base de Datos que están asociadas cada una a un Esquema Externo. Permite “ver” a cada tipo de usuario de la Base de Datos sólo aquella parte del esquema que sea de su interés. De una determinada Base de Datos se pueden derivar tantas vistas como haga falta.

El propósito principal de esta arquitectura de tres niveles es que el Esquema Conceptual sea una descripción estable de la organización e independiente de las “vistas” y de la forma de almacenamiento de los datos. Debido a esta independencia de niveles, las Bases de Datos pueden ser flexibles y adaptables a los cambios.

2.3

ANSI: MODELO DE REFERENCIA

En 1985 el DAFTG (Database Architecture Framework Task Group) del ANSI / X3 / SPARC Database System Study Group presentó el estudio final “Modelo de Referencia para la estandarización de los SGBD”. El Modelo de Referencia no es por si mismo un estándar sino un marco conceptual cuyo objetivo principal es simplificar el trabajo de estandarización de los distintos componentes y sus relaciones de un SGBD. Está basado en la Arquitectura de tres niveles de ANSI (1975), aunque la revisa y la simplifica. Los objetivos que el Modelo de Referencia pretende son:

Servir de herramienta para el desarrollo y coordinación de estándares en el área de SGBD.

Describir las interacciones entre el SGBD y otros componentes lógicos del Sistema de Información, tales como el Sistema de Diccionario de Datos.

Facilitar la formación del personal dando un marco común para la descripción de los SGBD.

Permitir la clasificación de los productos comerciales.

Ayudar a los usuarios a analizar, cambiar e introducir SGBD en su organización.

Las ventajas que puede traer la estandarización de los SGBD también son múltiples:

Portabilidad de las aplicaciones.

Mejora de la productividad y disminución de gastos de formación.

Simplificación de los procesos de evaluación y selección de los SGBD.

Reducción de costes.

Posibilidad de intercambio de datos entre distintos SGBD.

Para alcanzar los objetivos del Modelo de Referencia se deben cumplir los siguientes requisitos:

La definición del Modelo debe adaptarse a los nuevos desarrollos tecnológicos (Bases de Datos Distribuidos, etc.).






La simplificación de la arquitectura ANSI/SPARC (ANSI 77).

La unificación de los modelos de Datos.

La compatibilidad con otros Modelos.

2.4

DESCRIPCIÓN DEL MODELO DE REFERENCIA

En la figura siguiente aparecen los distintos componentes del Modelo de Referencia:

Vamos a pasar a describir los distintos elementos de la figura.

2.4.1

FUNCIONES DE ADMINISTRACIÓN

Administrador de la Empresa: diseña el Esquema Conceptual.

Administrador de la Base de Datos: especifica el Esquema Interno más eficiente para el esquema conceptual ya almacenado en los Metadatos.






Administrador de Aplicaciones: construye Esquemas Externos a partir del Esquema Conceptual y controla los distintos programas de aplicación que utiliza la Base de Datos.

En esta estructura lógica de tres tipos de esquemas se diferencian dos partes:

La parte superior para la Definición de la Base de Datos.

La parte inferior para la Manipulación de la Base de Datos.

2.4.2

DEFINICIÓN DE LAS ESTRUCTURAS DE DATOS

La definición se realiza por funciones de programa y sus correspondientes interfaces, que dan como resultado los METADATOS (información sobre los datos). Estos se almacenan en el Diccionario de Datos que constituye el núcleo de la Arquitectura. Creación de los tres tipos de esquemas:

Se especifica el esquema conceptual con la interfaz correspondiente al lenguaje de Definición, (ej. : SQL)

El procesador del esquema conceptual compila el esquema conceptual.

Se almacena el esquema conceptual en el diccionario de datos.

El procesador del esquema conceptual facilita información sobre este esquema, necesaria para la definición de los esquemas externo e interno.

Los procesadores controlan los esquemas externo e interno y los almacenan en la Base de Datos.

2.4.3

MANIPULACIÓN DE LOS DATOS

Una vez definidas las Bases de Datos el usuario mediante la interfaz del Lenguaje de Manipulación de Datos (LMD), ej.: SQL, puede realizar cualquier función de manipulación: insertar, borrar, modificar datos. Una petición del usuario es ejecutada por los transformadores Esquema Externo \ Esquema Conceptual, Esquema Conceptual \ Esquema Interno y Esquema Interno \ Almacenamiento Físico, que utilizan los metadatos almacenados en el Diccionario.

2.5

ENTORNO DE UN SGBD

En el entorno de un SGBD encontramos:

Programas de aplicación y procesadores de lenguaje de aplicación

Herramientas de Gestión

Diccionario de Datos

Sistema Operativo y Sistema de Gestión de Ficheros

Protocolos y Sistemas Distribuidos

3. EL MODELO LÓGICO RELACIONAL Este modelo fue presentado por Codd en el año 1970. Está basado en la representación del universo del discurso mediante los convencionalismos del álgebra relacional. Sus características principales son:






Al estar basado en un modelo matemático con reglas y algoritmos algebraicos bien establecidos, permite el desarrollo de lenguajes de acceso y manipulación potentes.

Estructura los datos en tablas bidimensionales. Estas tablas sirven tanto para representar las entidades del universo del discurso como las relaciones existentes entre ellas.

Posibilita la incorporación de aspectos semánticos del universo del discurso mediante el establecimiento de reglas de integridad. Estas reglas permiten trasladar al esquema conceptual restricciones o comportamientos de datos presentes en el universo del discurso que no se podrían modelar exclusivamente con tablas.

3.1.

CONCEPTOS Y ESTRUCTURA DEL MODELO RELACIONAL

El esquema de una Base de Datos Relacional se compone de uno o más esquemas de relación y de un conjunto de restricciones de integridad. Un Esquema de Relación consiste en el nombre de relación, seguido de los nombres de los atributos: NOMBRE RELACIÓN (ATRIBUTO1, ATRIBUTO2,..... ATRIBUTO n). Se define una Relación: 'Dados los dominios D1, D2 Dn (no necesariamente distintos), R es una relación entre estos n-conjuntos si es un conjunto de n-tuplas (d1,d2,…dn) tal que d1 pertenece a D1... dn pertenece a Dn ". Un Dominio es un conjunto de valores aceptables para un atributo dado. Cada Atributo, o propiedad con interés informacional de una relación está asociado a un dominio del que toma sus posibles valores. El número de atributos de una relación define su Grado, y el número de tuplas de la relación define su Cardinalidad. La extensión u Ocurrencia de una relación es una Tabla donde las filas corresponden a las tuplas y las columnas a los atributos. De estas definiciones se deducen las características de una tabla de estructura relacional:

Cada tabla debe contener un solo tipo de filas. El formato de cada fila queda definido por el esquema de la relación. Es decir todas las filas tienen las mismas columnas y formato.

Cada fila tiene que ser única, no puede haber filas duplicadas.

El orden de las filas dentro de una tabla es indiferente.

Cada columna debe estar identificada por un nombre específico.

El orden de las columnas dentro de una tabla es indiferente.

Cada columna debe extraer sus valores de un dominio.

Un mismo dominio podrá servir para definir los valores de varias columnas diferentes.

El valor individual de la intersección de cualquier fila y columna será un único dato.

3.2 RESTRICCIONES Hay propiedades de los datos que no pueden ser capturadas basándose en conjuntos y relaciones. Estas propiedades pueden ser expresadas como restricciones tanto en los valores de los datos como en el modo en que los datos se relacionan. Las razones para que un modelo requiera restricciones son:






Una razón semántica: permitir a los esquemas reflejar más exactamente la información a modelar.

Una razón de integridad: comunicar al SGBD qué estados de la Base de Datos están permitidos.

Se definen dos tipos básicos de restricciones:

Restricciones inherentes o estructurales, que forman parte integral de las estructuras del modelo.

Restricciones explícitas, definidas por el diseñador del esquema.

3.2.1

RESTRICCIONES INHERENTES

En una relación no hay tuplas repetidas, ésta es una restricción derivada de la definición de relación matemática. Esta inexistencia de tuplas duplicadas en una relación, implica que al menos todos los atributos de una fila sirven para identificarla. Una clave será un atributo o conjunto de atributos que identifican, por su valor, a cada tupla de una relación, de forma única y no redundante. Clave simple es la formada por un sólo atributo y clave compuesta la que consta de dos o más atributos. Hay relaciones en que se pueden encontrar varias claves posibles. De entre las claves candidatas se elige una para que sea la clave primaria de esa relación, las restantes serán las claves alternativas. La diferencia entre la clave primaria y las alternativas radica en las operaciones que pueden hacerse con ellas. El valor de la clave primaria en una tupla no puede ser modificado y el valor de una clave alternativa sí. Otro tipo de restricciones inherentes al modelo relacional son las Reglas de Integridad. Son las siguientes:

Integridad de Identidad: “Ningún atributo que pertenezca a la clave primaria de una relación puede aceptar valores nulos”. En este contexto, nulo, no significa un valor cero o espacio en blanco sino una indicación de que es valor desconocido, inaplicable, etc. Si se permitieran estos valores tendríamos entidades (filas) indistinguibles.

Integridad de asociaciones o de referencias cruzadas: “Todo valor de una clave externa o es nulo, o debe existir en alguna tupla de alguna relación donde la clave primaria esté definida sobre el mismo dominio que el de aquella clave externa".

Esta última regla de integridad tiene que ver con la inclusión de referencias a una relación desde otra relación. Supongamos que A es una clave primaria simple (con un solo atributo) de una relación R1 y que el atributo B de una clave primaria compuesta (con varios atributos) de una relación R2 está definida en el mismo dominio que A. En este caso, en cualquier instante, para cada valor de B en R2 debe existir un valor de A en R1 igual al valor de B. Adicionalmente, si B no forma parte de la clave primaria de R2, debería cumplir la condición anterior o bien tomar un valor nulo. En ambos casos, el atributo B sería una clave de referencia.

3.2.2

RESTRICCIONES EXPLÍCITAS

El modelo de datos relacional contiene pocas restricciones inherentes si lo comparamos con otros modelos de datos. Por el contrario, en los sistemas relacionales, existen mecanismos (materializados en un lenguaje de definición de restricciones) para añadir al esquema relacional restricciones explícitas. Algunos tipos de restricciones explícitas podrían ser:

Restricciones que limitan el rango de valores posibles de un atributo en una relación.






Restricciones que ligan valores de atributos de una relación con valores de atributos de otra o de la misma relación.

Restricciones que limitan los atributos que pueden ser comparados (para realizar un JOIN por ejemplo).

Restricciones que determinan condiciones que deben verificarse después de un cambio en la BD.

Restricciones que indican las condiciones necesarias para que una operación pueda llevarse a cabo.

3.3 LENGUAJES RELACIONALES El álgebra relacional es un lenguaje procedimental, ya que cuando se escribe una expresión en álgebra relacional, se proporciona una secuencia de operaciones que genera la respuesta a la consulta. Por otro lado, el cálculo relacional es un lenguaje no procedimental donde se da una descripción formal de la información deseada sin especificar cómo obtenerla.

3.3.1

ALGEBRA RELACIONAL

El álgebra relacional es un sistema cerrado de operaciones definidas sobre relaciones. Consta de unos operadores y unos operandos. Los operandos son relaciones y los resultados son, asimismo, relaciones que pueden tomarse como operandos en sucesivas operaciones. Existen cinco operadores fundamentales del álgebra relacional y otros que pueden ser definidos en términos de éstos. Los operadores fundamentales son: SELECCIÓN: Actúa sobre una relación para producir otra. La nueva relación es un subconjunto de la vieja determinado por un filtro (un criterio aplicado a las tuplas anteriores que determina cuales tuplas pasan a la nueva relación). El filtro es una función de comparación entre atributos del mismo dominio o entre atributos y constantes. PROYECCIÓN: También actúa sobre una relación, para producir otra. La nueva relación es un subconjunto de la vieja determinado por una lista de proyección que específica qué atributos de la relación antigua van a pasar a formar parte de la nueva. UNIÓN: Actúa sobre dos relaciones compatibles y de igual grado para producir una tercera en la que aparecen todas las tuplas que estén en cualquiera de las relaciones operandos. La unión permite la inserción de nuevas tuplas dentro de una relación existente donde, estas tuplas, formarían uno de los operandos de la relación. DIFERENCIA: La diferencia entre dos relaciones, R1 y R2, compatibles y de igual grado, es el conjunto de tuplas presentes en la relación R1 y ausentes en la relación R2. Esta operación permite el borrado de tuplas de una relación. PRODUCTO CARTESIANO: Produce una relación de salida desde dos relaciones de entrada de grados cualesquiera. La salida tiene un grado igual a la suma de los grados de las entradas y las tuplas resultantes se obtienen yuxtaponiendo a cada tupla de la primera relación de entrada, todas y cada una de las tuplas de la segunda relación. Estos cinco operadores forman un conjunto relacionalmente completo, es decir, permite obtener cualquier subconjunto de los datos contenidos en una BD. Los operadores adicionales que pueden ser definidos en términos de los fundamentales son: intersección, join y cociente. La INTERSECCIÓN de dos relaciones compatibles es otra relación constituida por todas las tuplas presentes en las dos relaciones. La potencia del JOIN, operador compuesto de selección, proyección y producto cartesiano y, dentro de él, el operador JOIN NATURAL, produce una operación resultado a partir de dos de entrada, en las que se busca la coincidencia de valores entre atributos de igual nombre que se derivan del mismo dominio.






El COCIENTE de dos relaciones R1 y R2 es otra relación constituida por las tuplas que al completarse con las tuplas de R2 permiten obtener la relación R1. Además de los operadores citados, existen una serie de operadores cuyo objetivo es aumentar el poder expresivo y de manipulación del álgebra relacional. Entre los operadores de consulta se encuentran la agrupación ("group by") y el cierre transitivo, ambos no derivables de los operadores fundamentales. Entre los operadores de manipulación, el de inserción y el de borrado de tuplas. Un lenguaje es relacionalmente completo cuando tiene la misma capacidad de obtención de datos que el álgebra relacional.

3.3.2

CALCULO RELACIONAL

El concepto de cálculo relacional fue propuesto por Codd (1972), como alternativo al Álgebra Relacional. A diferencia de ésta última, en que han de especificarse los operadores que son necesarios para obtener el resultado deseado (lenguaje descriptivo o procedimental), con los lenguajes basados en el cálculo relacional se indica cual es el resultado deseado, expresándolo mediante cálculo de predicados de primer orden (lenguaje descriptivo o predicativo). Existen dos formas de Cálculo Relacional :

Cálculo relacional de tuplas. Las variables representan tuplas de una relación. Un "query" se especifica mediante el conjunto de tuplas que satisfacen una fórmula bien formada {t 1 F(t)}. Una fórmula bien formada se construye combinando condiciones a cumplir por determinados elementos de las tuplas, operadores booleanos (AND,OR,NOT) y cuantificadores (para todo, existe). Las condiciones son de la forma: R1.A*R2.B ó R1,.A*cte, donde * es un operador aritmético de comparación (=,-,=,<,<=,>,>=), R1.A representa el atributo A de la relación R1, etc.

Cálculo relacional de dominios. Las variables representan valores de dominios sobre los que está definida la relación.

El éxito del cálculo relacional de dominios es debido al QBE (Query By Example) que es una aplicación visual del cálculo de dominios, diseñada para uso interactivo. El usuario hace consultas dando un ejemplo de la respuesta, teclea el nombre de la relación, dando lugar a la impresión en pantalla de sus esquemas. A continuación, con palabras clave en las columnas (dominios), el usuario especifica la consulta ( por ej. P para imprimir, U para actualizar, ' ' para recuperar).

3.4

BASES DE DATOS RELACIONALES

Las bases de datos relacionales se han ido imponiendo desde la década de los 80 debido a la universal aceptación de la superioridad que ofrece el modelo de datos en el que se basan, el modelo relacional, frente a sus antecesores: modelo jerárquico (estructuras en árbol) y modelo Codasyl (estructuras en red). Un sistema de base de datos relacional se caracteriza por presentar sus datos externamente como tablas, aunque internamente se sigan manejando éstos de forma convencional, por medio de índices, páginas, etc. Otra de sus características es la disponibilidad de un lenguaje para operar con estas tablas, con funciones, al menos de recuperación y modificación. Adicionalmente debe proporcionar funciones para seleccionar subconjuntos de tablas sin predefinición de caminos de acceso. El lenguaje también incluye en determinados gestores, las funciones necesarias para definición de datos, obtención de estadísticas básicas (mínimos, máximos, medias ... ), ordenación en determinada secuencia,






agrupamiento, etc. Igualmente debe proporcionar medios para controlar la integridad, seguridad y consistencia de los datos. Por último, un sistema relacional, debe disponer de interfaces que permitan el acceso concurrente desde terminales interactivos y programas de aplicación, así como herramientas estándar para controlar la operación y facilitar, además, los procesos de respaldo y recuperación. Codd estableció en 1985 doce principios, de los cuales al menos seis deben satisfacerse para que una base de datos pueda considerarse totalmente relacional. Estos fueron precedidos de una regla general global, llamada "Regla Cero". Estos principios pueden resumirse de la siguiente forma: REGLA 0: Gestión de una Base de Datos Relacional. Un sistema de gestión de una base de datos relacional (SGBDR), debe ser capaz de manejar las Bases de Datos exclusivamente con sus capacidades relacionales. REGLA 1: Representación de la información. Toda la información en una base de datos relacional se representa explícitamente a nivel lógico y de una manera única, por medio de valores en tablas. REGLA 2: Acceso garantizado. Todos y cada uno de los datos elementales en una base de datos relacional, deben ser accesibles lógicamente mediante el recurso a una combinación de: nombre de tabla, valor de clave primaria y nombre de columna. REGLA 3: Representación sistemática de la información que falta. Los valores nulos deben ser soportados por un sistema de gestión de Bases de Datos (SGBD) completamente relacional para representar, de modo sistemático, la información desconocida o inaplicable. REGLA 4: Catálogo dinámico. La descripción de la Base de Datos se representa, a nivel lógico, en la misma forma que los datos ordinarios de modo que los usuarios autorizados puedan aplicar el mismo lenguaje relacional para consultarlo. REGLA 5: Sublenguaje global de datos. Debe existir, al menos, un lenguaje cuyas sentencias sean expresabas por medio de una sintaxis bien definida, como cadena de caracteres, y capaz de soportar definición de datos, definición de vistas, manipulación de datos, restricciones de integridad, autorizaciones y manejo de transacciones. REGLA 6: Actualización de vistas. Todas las vistas teóricamente actualizables deberán ser también actualizables por el sistema. REGLA 7: Inserciones, actualizaciones y eliminaciones de alto nivel. La capacidad para manejar, como un solo operando, la relación base o una relación derivada se aplica, no sólo a las recuperaciones de datos, sino también, a sus inserciones, actualizaciones y eliminaciones. REGLA 8: Independencia física de los datos. Los programas de aplicaciones y las actividades terminales permanecerán lógicamente inalterados siempre que se realicen cambios en las representaciones de almacenamiento o en los métodos de acceso. REGLA 9: Independencia lógica de los datos. Cuando se efectúe en las tablas cualquier tipo de cambio que preserve la información, los programas de aplicación permanecerán intactos. REGLA 10: Independencia de la integridad. Las reglas de integridad de una Base de Datos particular deben ser definibles por medio del sublenguaje de datos relacional y almacenadas en el catálogo, no en los programas de aplicaciones. REGLA 11: Independencia de la distribución. Un sistema relacional debe tener un sublenguaje de datos que pueda soportar bases de datos distribuidas sin alterar los programas de aplicaciones o actividades finales. REGLA 12: Regla de la no inversión. Si un sistema relacional tiene un lenguaje de bajo nivel, éste no puede ser utilizado para pasar por alto las reglas de integridad y las restricciones expresadas por medio del lenguaje relacional de más alto nivel.






4. NORMALIZACIÓN

4.1

INTRODUCCIÓN

La teoría de la normalización tiene por objetivo la eliminación de dependencias entre atributos que originen anomalías en la actualización de los datos, y proporcionar una estructura más regular para la representación de las tablas, constituyendo el soporte para el diseño de bases de datos relacionales.

4.2

DESCRIPCIÓN

La teoría de la normalización, como técnica formal para organizar los datos, ayuda a encontrar fallos y a corregirlos, evitando así introducir anomalías en las operaciones de manipulación de datos. Se dice que una relación está en una determinada forma normal si satisface un cierto conjunto de restricciones sobre los atributos. Cuanto más restricciones existan, menor será el número de relaciones que las satisfagan, así, por ejemplo, una relación en tercera forma normal estará también en segunda y en primera forma normal. Antes de definir las distintas formas normales se explican, muy brevemente, algunos conceptos necesarios para su comprensión. Dependencia funcional Un atributo Y se dice que depende funcionalmente de otro X si, y sólo si, a cada valor de X le corresponde un único valor de Y, lo que se expresa de la siguiente forma: X → Y (también se dice que X determina o implica a Y). X se denomina implicante o determinante e Y es el implicado. Dependencia funcional completa Un atributo Y tiene dependencia funcional completa respecto de otro X, si depende funcionalmente de él en su totalidad, es decir, no depende de ninguno de los posibles atributos que formen parte de X. Dependencia transitiva Un atributo depende transitivamente de otro si, y sólo si, depende de él a través de otro atributo. Así, Z depende transitivamente de X, si: X→Y Y→Z X -/→ Z Se dice que X implica a Z a través de Y. Una vez definidas las anteriores dependencias, se pueden enunciar las siguientes formas normales:

4.2.1

PRIMERA FORMA NORMAL (1FN)

Una entidad está en 1FN si no tiene grupos repetitivos, es decir, un atributo sólo puede tomar un único valor de un dominio simple. Una vez identificados los atributos que no dependen funcionalmente de la clave principal, se formará con ellos una nueva entidad y se eliminarán de la antigua. La clave principal de la nueva entidad estará formada por la concatenación de uno o varios de sus atributos más la clave principal de la antigua entidad.






4.2.2

SEGUNDA FORMA NORMAL (2FN)

Una entidad está en 2FN si está en 1FN y todos los atributos que no forman parte de las claves candidatas (atributos no principales) tienen dependencia funcional completa respecto de éstas, es decir, no hay dependencias funcionales de atributos no principales respecto de una parte de las claves. Cada uno de los atributos de una entidad depende de toda la clave. Una vez identificados los atributos que no dependen funcionalmente de toda la clave, sino sólo de parte de la misma, se formará con ellos una nueva entidad y se eliminarán de la antigua. La clave principal de la nueva entidad estará formada por la parte de la antigua de la que dependen funcionalmente.

4.2.3

TERCERA FORMA NORMAL (3FN)

Una entidad está en 3FN si está en 2FN y todos sus atributos no principales dependen directamente de la clave primaria, es decir, no hay dependencias funcionales transitivas de atributos no principales respecto de las claves. Una vez identificados los atributos que dependen de otro atributo distinto de la clave, se formará con ellos una nueva entidad y se eliminarán de la antigua. La clave principal de la nueva entidad será el atributo del cual dependen. Este atributo en la entidad antigua, pasará a ser una clave ajena.

4.3

NOTACIÓN

Una herramienta muy útil para visualizar las dependencias funcionales es el grafo o diagrama de dependencias funcionales, mediante el cual se representa un conjunto de atributos y las dependencias funcionales existentes entre ellos. En el grafo aparecen los nombres de los atributos unidos por flechas, las cuales indican las dependencias funcionales completas que existen entre ellos, partiendo del implicante hacia el implicado. Cuando el implicante de una dependencia no es un único atributo, es decir, se trata de un implicante compuesto, los atributos que lo componen se encierran en un recuadro y la flecha parte de éste, no de cada atributo.

En la figura se presenta un ejemplo de cómo se visualizan las dependencias. Se puede observar que cod_libro determina funcionalmente el título del libro y la editorial, como indica la correspondiente flecha; de forma análoga, num_socio determina el nombre, domicilio y el tel. del socio (suponiendo que sólo se proporciona un teléfono); mientras que ambos atributos en conjunto cod_libro y num_socio (lo que se indica mediante el recuadro que los incluye) determinan fecha_préstamo y fecha_dev. Ejemplo: Sea una entidad TÉCNICOS de un grupo de empresas, con los siguientes atributos: − cod_empresa − cod_técnico − nombre_técnico − cod_categoría − categoría − nombre_empresa − fecha_alta − fecha_baja






− cod_conoc − título_conoc − área_conoc − grado − cod_proyecto − nombre_proyecto − f_inicio − f_fin − f_asignación − f_cese − cod_cliente − nombre_cliente La entidad TÉCNICOS tiene la clave principal compuesta por cod_empresa y cod_técnico, ya que, al ser varias empresas, el código de técnico no será único, sino que puede coincidir con otros de otras empresas. Primera forma normal (1FN): Evidentemente no se cumple la primera forma normal, ya que un técnico tendrá más de un conocimiento (lenguajes, sistemas operativos, bases de datos, etc.), es decir habrá varios valores de cod_conoc, por lo que este atributo y los asociados a conocimientos no dependen funcionalmente de la clave principal. Los atributos cod_conoc, título_conoc, área_conoc y grado identificados como no dependientes, formarán la nueva entidad CONOCIMIENTOS y desaparecerán de la entidad TÉCNICOS. La clave de la nueva entidad será cod_conoc concatenada con cod_empresa y cod_técnico. Por otro lado, en este sistema un técnico puede trabajar en más de un proyecto a tiempo parcial, por lo que cod_proyecto tampoco depende funcionalmente de la clave principal de TÉCNICOS. Se obtiene entonces la entidad PROYECTOS con los atributos de los proyectos, y su clave compuesta de cod_proyecto concatenada con cod_empresa y cod_técnico de la antigua entidad. Esta situación se completará con dos tipos de relaciones: Poseen, cuyo tipo de correspondencia es 1:N entre TÉCNICOS y CONOCIMIENTOS y Están asignados, también del tipo M:N entre TÉCNICOS y PROYECTOS, tal y como muestra el diagrama siguiente:






Como se aprecia en la figura, se ha trasladado el atributo grado de la entidad CONOCIMIENTOS a la relación Poseen, pues es un atributo que determina la relación entre las dos entidades. También han sido trasladado los atributos que caracterizan la relación Están asignados, como son f_asignación y f_cese, ya que un técnico no siempre estará trabajando en un proyecto, sino en determinado periodo. Segunda forma normal (2FN): En la entidad TÉCNICOS se observa que el atributo nombre_empresa no tiene una dependencia funcional completa de la clave, sino que la tiene sólo de una parte de la misma: cod_empresa. El atributo identificado formará parte de una nueva entidad, EMPRESAS, siendo eliminado de la antigua. La clave principal de la nueva entidad será cod_empresa. Para representar la segunda forma normal en el modelo de datos, deberá añadirse un tipo de relación, Se componen, y el tipo de correspondencia 1:N.

Tercera forma normal (3FN): En la entidad TÉCNICOS de la figura se puede observar que para un cod_técnico hay un único cod_categoría, es decir, el segundo depende funcionalmente del primero; para un cod_categoría hay una única categoría, es decir, que este atributo depende funcionalmente del cod_categoría; y por último, para un cod_categoría hay varios valores de cod_técnico. Así pues, la categoría depende transitivamente del cod_técnico, por lo que la entidad TÉCNICOS no está en 3FN.






Una vez identificado el atributo categoría que depende de otro atributo distinto de la clave, cod_categoría, se formará con él una nueva entidad y se quitará de la antigua. La clave principal de la nueva entidad será el atributo del cual depende cod_categoría y en la entidad antigua pasará a ser una clave ajena. Del mismo modo, puede observarse que la entidad PROYECTOS tampoco está en 3FN, pues el nombre_cliente depende de cod_cliente, que no forma parte de la clave de la entidad.

Así pues, aparecen dos entidades nuevas en el modelo: CATEGORÍAS y CLIENTES, y sus respectivas relaciones y tipos de correspondencias: Están clasificados 1:N y Tiene contratados 1:N.






4.4

OTRAS FORMAS NORMALES

Además de las tres formas normales antedichas existen otras más avanzadas aunque no son de uso tan habitual como las anteriores, por lo que las vamos a definir brevemente:

4.4.1

FORMA NORMAL DE BOYCE-CODD (FNBC)

Una relación se encuentra en forma normal de Boyce-Codd si y sólo si está en 3FN y además todo determinante es una clave candidata.

4.4.2

CUARTA FORMA NORMAL (4FN)

Una relación está en cuarta forma normal si y sólo si está en FNBC y además en todas las dependencias múltiplemente valoradas el implicante es clave candidata.

4.4.3

QUINTA FORMA NORMAL (5FN)

Una relación está en quinta forma normal si y sólo si está en 4FN y además toda dependencia de combinación está implicada por una clave candidata. Una dependencia de combinación aparece en relaciones que no pueden descomponerse en otras dos sin perder información. Para evitar esta pérdida de información hay que descomponerla, al menos, en otras tres relaciones.

5.

CONCLUSIÓN

Los sistemas informáticos tradicionales se denominaban sistemas “orientados al proceso”, debido a que el énfasis se ponía en el tratamiento que recibían los datos., los cuales se almacenaban en ficheros diseñados para una determinada aplicación. Este planteamiento provocaba una serie de problemas: ocupación inútil de memoria secundaria, inconsistencias, dependencia de los datos respecto al soporte físico, etc. Para resolver estos problemas surgió un nuevo enfoque que se apoyaba sobre las “Bases de Datos” en las cuales los datos son recogidos y almacenados una sola vez con independencia de los tratamientos. Las Bases de Datos no son únicamente una nueva tecnología, sino que nacen de una concepción distinta del Sistema de Información. Por eso tienen una influencia decisiva en las estructuras y organizaciones de su entorno.

6.

BIBLIOGRAFÍA

Métrica versión 3. Ministerio de Administraciones Públicas. Consejo Superior de Informática.

Análisis y diseño detallado de Aplicaciones Informáticas de Gestión. Mario G. Piattini y otros. Editorial RA-MA. Año 1996.






7.

ESQUEMA – RESUMEN

HISTORIA

Los datos figuraban en los programas como constantes.

Aparecen Ficheros: Dependencia de los programas respecto de los datos y viceversa.

Años 60: Nacen los primeros Sistemas de Gestión de Bases de Datos SGBD.

ARQUITECTURA ANSI/SPARC 1975: Se propone una arquitectura de tres niveles:

Nivel Físico o Interno: Se engrana con el Sistema Operativo y el Sistema de Gestión de Ficheros. Especifica qué y cómo son almacenados los datos.

Nivel Conceptual: Capta y almacena el “universo del discurso” que describe a la organización o empresa y que es necesaria para su funcionamiento.

Nivel Lógico o Externo: Permite “ver” a cada tipo de usuario de la BD sólo aquella parte del esquema que sea de su interés.

MODELO LÓGICO RELACIONAL Codd 1970: Basado en el álgebra relacional. Estructura los datos en forma de tablas bidimensionales. Incorpora aspectos semánticos del universo del discurso a través de reglas de integridad.

Base de Datos Relacional: Uno o más esquemas de relación y un conjunto de relaciones de integridad.

Esquema de Relación: Nombre de relación, seguido de los nombres d elos atributos.

Relación: Dados los dominios D1,D2,..,Dn, R es una relación entre estos n-conjuntos si es un conjunto de n-tuplas (d1, d2, ..., dn) tal que d1 pertenece a D1,.... dn pertenece a Dn.

Dominio: Conjunto de valores para un atributo dado.

Atributo: Propiedad con interés informacional de una relación asociado a un dominio del que toma sus posibles valores.

Grado: Número de atributos de una relación.

Cardinalidad: Número de tuplas de una relación.

Una tabla de estructura relacional:

Tiene un solo tipo de filas.

Cada fila tiene que ser única.

El orden de las filas es indiferente.

Cada columna debe extraer sus valores de un dominio.

Un mismo dominio podrá servir para definir los valores de varias columnas diferentes.

El valor individual de la intersección de cualquier fila y columna será un único dato.






RESTRICCIONES Hay propiedades de los datos que tienen que ser expresadas mediante restricciones tanto en los valores de los datos como en el modo en que los datos se relacionan.

Restricciones inherentes o estructurales: Forman parte integral de las estructuras del modelo.

Restricciones explícitas: Definidas por el diseñador del sistema.

Una clave será un atributo o conjunto de atributos que identifican, por su valor, a cada tupla de una relación, de forma única y no redundante. Clave simple es la formada por un único atributo. Clave compuesta la que consta de dos o más atributos. Integridad de identidad: Ningún atributo que pertenezca a la clave primaria de una relación puede aceptar valores nulos. Integridad de referencias cruzadas: Todo valor de una clave externa o es nulo o debe existir alguna tupla de alguna relación donde la clave primaria esté definida sobre el mismo dominio que el de aquella clave externa.

ÁLGEBRA RELACIONAL

SELECCIÓN: Actúa sobre una relación para producir otra. La nueva relación es un subconjunto de la vieja determinado por un filtro). El filtro es una función de comparación entre atributos del mismo dominio o entre atributos y constantes.

PROYECCIÓN: También actúa sobre una relación, para producir otra. La nueva relación es un subconjunto de la vieja determinado por una lista de proyección que específica qué atributos de la relación antigua van a pasar a formar parte de la nueva.

UNIÓN: Actúa sobre dos relaciones compatibles y de igual grado para producir una tercera en la que aparecen todas las tuplas que estén en cualquiera de las relaciones operandos. La unión permite la inserción de nuevas tuplas dentro de una relación existente donde, estas tuplas, formarían uno de los operandos de la relación.

DIFERENCIA: La diferencia entre dos relaciones, R1 y R2, compatibles y de igual grado, es el conjunto de tuplas presentes en la relación R1 y ausentes en la relación R2.

PRODUCTO CARTESIANO: Produce una relación de salida desde dos relaciones de entrada de grados cualesquiera. La salida tiene un grado igual a la suma de los grados de las entradas y las tuplas resultantes se obtienen yuxtaponiendo a cada tupla de la primera relación de entrada, todas y cada una de las tuplas de la segunda relación.

NORMALIZACIÓN Dependencia funcional: Un atributo Y se dice que depende funcionalmente de otro X si, y sólo si, a cada valor de X le corresponde un único valor de Y, lo que se expresa de la siguiente forma: X → Y (también se dice que X determina o implica a Y). X se denomina implicante o determinante e Y es el implicado. Dependencia funcional completa: Un atributo Y tiene dependencia funcional completa respecto de otro X, si depende funcionalmente de él en su totalidad, es decir, no depende de ninguno de los posibles atributos que formen parte de X. Dependencia transitiva: Un atributo depende transitivamente de otro si, y sólo si, depende de él a través de otro atributo. Así, Z depende transitivamente de X, si: X→Y Y→Z X -/→ Z






Se dice que X implica a Z a través de Y. Primera forma normal (1FN): Una entidad está en 1FN si no tiene grupos repetitivos, es decir, un atributo sólo puede tomar un único valor de un dominio simple. Segunda forma normal (2FN): Una entidad está en 2FN si está en 1FN y todos los atributos que no forman parte de las claves candidatas (atributos no principales) tienen dependencia funcional completa respecto de éstas, es decir, no hay dependencias funcionales de atributos no principales respecto de una parte de las claves. Cada uno de los atributos de una entidad depende de toda la clave. Tercera forma normal (3FN): Una entidad está en 3FN si está en 2FN y todos sus atributos no principales dependen directamente de la clave primaria, es decir, no hay dependencias funcionales transitivas de atributos no principales respecto de las claves.



Ticb2 - Diseño de Bbdd i

Recommend Documents