UNIVERSIDAD SALESIANA DE BOLIVIA

CARRERA INGENIERA DE SISTEMAS

DOSSIER

BASE DE DATOS I

Cuarto Semestre

Lic. Katya Maricela Prez Martnez

2011

NDICE

PRESENTACIN.................................................................................................................i

TEMA 1 FUNDAMENTOS DE BASE DE DATOS

1.1 Introduccin1

1.2 Caractersticas del enfoque de base de datos2

1.2.1 Naturaleza autodescriptiva de los sistemas de base de base de datos3

1.2.2 Separacin entre los programas y los datos, y abstraccin de datos4

1.2.3 Soporte de mltiples vistas de los datos5

1.2.4 Compartimiento de datos y procesamiento de transacciones multiusuario6

1.3 Usuarios y administradores de la base de datos6

1.4 Ventajas de utilizar un SGBD8

1.5 Arquitectura de un SGBD e independencia de datos10

1.5.1 Arquitectura de tres esquemas10

1.5.2 Independencia de datos12

1.6 Lenguajes e interfaces de base de datos13

1.6.1 Lenguajes del SGBD13

1.6.2 Interfaces del SGBD15

1.7 El entorno del sistema de base de datos16

1.8 Estructuras operacionales de los SGBD20

1.9 Clasificacin de los sistemas de gestin de base de datos22

1.10 Aplicaciones de los sistemas de base de datos23

1.10.1 Bases de datos en la World Wide Web23

1.10.2 Bases de datos multimedia25

1.10.3 Bases de datos mviles26

1.10.4 Sistemas de Informacin Geogrfico26

1.10.5 Gestin de datos del genoma28

Preguntas de repaso...............................................................................................................28

REFERENCIAS BIBLIOGRFICAS..................................................................................29

TEMA 2 MODELO DE DATOS

2.1 Introduccin30

2.2 La importancia de los modelos de datos30

2.3 Clasificacin de los modelos31

2.3.1 Modelos lgicos basados en objetos31

2.3.2 Modelos lgicos basados en registros33

Preguntas de repaso...............................................................................................................40

REFERENCIAS BIBLIOGRFICAS..................................................................................41

TEMA 3 MODELO ENTIDAD RELACION

3.1 Modelo Conceptual42

3.2 Definicin del Modelo E/R42

3.3 Objetivos del Modelo42

3.4 Terminologa utilizada en el Modelo43

3.4.1 Entidad43

3.4.2 Entidad Dbil44

3.4.3 Atributo44

3.4.5 Claves candidatas e identificadores45

3.4.6 Atributos Multivaluados46

3.4.7 Relaciones46

3.5 Grados de una relacin47

3.6 Cardinalidad de relaciones y participaciones49

3.6.1 Cardinalidad Mnima y Mxima50

3.6.2 Tipos de relaciones51

3.7 Generalizacin53

3.8 Agregacin Y Entidades Asociativas54

Ejercicios propuestos56

REFERENCIAS BIBLIOGRFICAS..................................................................................57

TEMA 4 MODELO RELACIONAL

4.1 Por qu crear un diseo de base de datos?58

4.2 Presentacin y Orgenes del Modelo Relacional59

4.3 Estructura de datos relacional59

4.4 Trminos Bsicos en el Modelo Relacional60

4.5 Definiciones Formales61

4.5.1 Dominio61

4.5.2 Relacin61

4.5.2.1 Propiedades de una relacin62

4.5.2.2 Relacin vs. Tabla62

4.5.3 Base de Datos Relacional63

4.6 Caractersticas Generales de Integridad64

4.6.1 Reglas de Integridad64

4.6.1.1 Superclave y clave de una relacin65

4.6.1.2 Clave candidata, primaria y alternativa65

4.6.1.3 clave ajena (externa o fornea)66

4.6.1.4 Mantenimiento de la Integridad Referencial68

4.6.1.5 Valores Nulos70

4.7 Proceso de Transformacin72

4.7.1 Mapeo Bsico73

4.7.2 Obtencin de las relaciones a partir del diagrama E/R74

4.7.3 Representacin de conjuntos de entidades dbiles79

Ejercicios propuestos.............................................................................................................80

REFERENCIAS BIBLIOGRFICAS..................................................................................81

TEMA 5 NORMALIZACIN

5.1 Definicin de Normalizacin82

5.2 Relaciones bien Estructuradas83

5.3 Dependencia Funcional (DF)84

5.4 Primera Forma Normal (1FN)86

5.5 Dependencia Funcional Completa86

5.6 Segunda Forma Normal (2FN)89

5.7 Dependencia Transitiva90

5.8 Tercera Forma Normal (3FN)91

5.9 Definicin de Determinante92

5.10 Forma Normal de Boyce Codd (BCFN)92

5.11 Dependencia de Valores Multivaluados (DMV)94

5.12 Cuarta Forma Normal (4FN)95

Ejercicios propuestos ............................................................................................................95

REFERENCIAS BIBLIOGRFICAS................................................................................ 97

TEMA 6 OPERACIONES DEL MODELO RELACIONAL

6.1 Introduccin98

6.2 lgebra Relacional98

6.2.1 Operadores de conjuntos................................................................................. .99

6.2.2 Operadores relacionales ................................................................................ 100

6.3 Clculo Relacional103

Ejercicios propuestos ..........................................................................................................104

REFERENCIAS BIBLIOGRFICAS............................................................................. 105

TEMA 7 INTRODUCCIN AL LENGUAJE DE CONSULTA (SQL)

7.1 Definicin de dn lenguaje de consulta106

7.2 Definicin de datos107

7.3 Manipulacin de datos109

7.4 Operaciones sobre una relacin110

7.5 Operaciones sobre ms de una relacin112

7.6 Ejercicios sobre operaciones114

7.7 Expresiones con bloques anidados115

Ejercicios propuestos .........................................................................................................117

REFERENCIAS BIBLIOGRFICAS............................................................................. 119

LECTURAS COMPLEMENTARIAS............................................................................120

GLOSARIO ......................................................................................................................121

BIBLIOGRAFA ..............................................................................................................127

PRESENTACIN

Las Bases de Datos han evolucionado a partir de los aos 60 como una necesidad de mejorar el procesamiento de los datos y en respuesta a las limitaciones del procesamiento orientado a proceso. Hoy en da las Bases de Datos se ha convertido en la parte esencial de la currcula de la informtica.

Este dossier est orientado a los estudiantes de la carrera de Ingeniera de Sistemas tanto para el nivel tcnico como superior. Es un material bsico que contiene temas que pueden usarse como material de este primer curso y cursos avanzados.

En este dossier se asumen que se dispone de los conocimientos previos sobre estructura de datos, organizacin de archivos y un lenguaje de programacin. Su contenido es didctico con muchos ejemplos y algunos ejercicios que se deben desarrollar en clases por parte de los estudiantes con la gua del docente. Al final de cada tema se proponen ejercicios como practicas.

El dossier est organizado en ocho temas:

Fundamentos de Base de Datos.- Se desarrollan las definiciones de bases de datos a raz de este concepto se explica que un dato para luego estudiar las propiedades implcitas de una base de datos. Se da el concepto de sistema gestor de base de datos y se explica sus ventajas. Finalmente se explica las aplicaciones de las bases de datos en las diferentes reas.

Arquitectura de una Base de Datos.- Describe los tres niveles de la arquitectura de una base de datos.

Modelo de datos.- Un modelo de datos desempea una funcin prioritaria en el proceso de abstraccin que conduce a la base de datos.

Modelo Entidad Relacin.- Este modelo proporciona una visin de alto nivel de los resultados de un diseo de base de datos, Se basa en los conceptos de entidad, atributo y relacin.

Modelo Relacional.- Es un modelo basado en registros y en teora matemtica, cuenta con tablas como estructura principal. Puede obtener ser este modelo a partir de la transformacin del modelo Entidad Relacin.

Normalizacin.- Es el proceso por el cual se depuran las tablas para evitar tener redundancia de datos y anomalas.

Operaciones del modelo relacional.- Basadas en el lgebra relacional y calculo relacional. El lgebra relacional se constituye de operadores de conjunto y operadores especiales de proyeccin y seleccin, por otra parte el clculo relacional es un lenguaje formal basado en la lgica de predicados, o clculo de predicados de primer orden.

Introduccin al lenguaje de consulta SQL.- Permite interaccionar con la base de datos para obtener datos y definir datos a travs de rdenes. El lenguaje SQL tiene varios componentes como ser el lenguaje de definicin de datos, lenguaje interactivo de manipulacin de datos, definicin de vistas, control de transacciones, integridad transaccin.

2.1.Arquitectura de un SGBD e independencia de datos

Hay tres caractersticas importantes inherentes al enfoque de las bases de datos: 1) la separacin entre los programas y los datos (independencia entre programas y datos) ; 2) el soporte de mltiples vistas de usuario, y 3) el empleo de un catlogo para almacenar la descripcin (esquema) de la base de datos. La arquitectura de tres esquemas ayuda alcanzar y visualizar estas caractersticas.

2.2.Arquitectura de tres esquemas

El Comit de planificacin y requerimientos del Instituto Nacional de Estados Unidos de Estndares en Computacin y Procesamiento de Informacin que en su divisin X3 establece que la arquitectura de una BD debe poseer tres niveles:

Nivel interno

Nivel conceptual

Nivel Externo

Nivel Interno

Este es nivel ms bajo de abstraccin de informacin.

El nivel interno es la representacin inferior de una BD, por ello es el ms cercano al almacenamiento fsico. Permite describir los datos tal como estn almacenados en la computadora; Por ejemplo:

Los archivos que los contienen ( nombre, organizacin, ubicacin,.)

Los registros de estos archivos (longitud, campos, )

Las rutas de acceso a esos registros (ndices, encadenamientos, archivos invertidos)

El nivel interno es descrito por el DBMS por medio de un esquema interno o vista interna.

El Sistema operativo y el DBMS permiten la transformacin de un registro a partir de su estructura lgica hasta su almacenamiento fsico. La operacin de transformar registros lgicos en fsicos y viceversa se llama Transformacin de Datos o mapeo.

Figura 1.7 Arquitectura de tres esquemas

Nivel Conceptual

Es el siguiente nivel ms alto de abstraccin. El DBA define el nivel conceptual por medio de un esquema o vista conceptual, al decir que informacin se guarda en la BD.

Este nivel corresponde a la estructura organizacional de la Base obtenida al reunir los requerimientos de todos los usuarios de una empresa, sin preocuparse de la organizacin fsica ni las vas de acceso.

El esquema conceptual podr contener:

Los datos elementales que definen los campos, atributos, de los objetos de una empresa. Ejemplo Nombre, concepto, nro de hijos, zona, etc.

Los datos compuestos que permiten reagrupar los campos para describir los registros, las entidades del mundo real. Ejemplo: Personas, Artculos, Vehculos, etc.

Los datos compuestos que permiten reagrupar los campos para describir las asociaciones del mundo real. Ejemplo: Compras de artculo, propietarios de los coches, etc.

Algunas veces las reglas que deberan seguir los datos en la empresa. Ejemplo: Que el stock mnimo est comprendido entre unos mrgenes, que cada artculo posea su proveedor, etc.

Relaciones entre los datos para conectar o relacionar registros en el procesamiento de archivos mltiples.

En este nivel la base de datos aparece como una coleccin de registros lgicos sin especificar su almacenamiento. En realidad, los archivos conceptuales no existen fsicamente.

Nivel Externo

Es el nivel ms alto de abstraccin y por ello el ms cercano a los usuarios. El nivel externo representa la percepcin individual de cada usuario o programador de la BD, describe nicamente la parte de los datos de inters para un usuario o grupo de usuarios. Los usuarios pueden imaginar que los archivos externos utilizados en sus programas existen tal como ellos lo perciben. Pero los archivos externos tampoco existen fsicamente.

El DBMS es el encargado de extraer los datos requeridos por los registros lgicos externos de uno o ms registros fsicos, de la BD, cada vez que se ejecuta una operacin de E/S en un programa especfico.

Por cada programa es necesario especificar un esquema externo o subesquema o vista externa para poder acceder de forma selectiva a un subconjunto de datos de la base integrada. Habr usuarios que podrn acceder a ms de un esquema externo, y un esquema externo puede ser compartido por varios usuarios; se protege de esta forma el acceso a los datos de usuarios no autorizados o mal intencionados.

A la hora de construir el subesquema hay que tener presente que:

Uno o ms tipos de registros pueden omitirse en el esquema.

Uno o ms campos pueden omitirse en el registro conceptual.

En el registro conceptual puede cambiarse el orden relativo de los campos del registro.

Una o ms relaciones entre los datos pueden omitirse en el esquema conceptual.

2.3.Independencia de datos

La arquitectura de tres esquemas puede servir para explicar el concepto de independencia de datos, que se define como la capacidad para modificar el esquema en un nivel del sistema de base de datos sin tener que modificar el esquema del nivel inmediato superior.

Se definen dos tipos de independencia de datos:

1. Independencia lgica de los datos, es la capacidad de modificar el esquema conceptual sin tener que alterar lo esquemas externos ni los programas de aplicacin. Podemos modificar el esquema conceptual para ampliar la base de datos (aadiendo un nuevo tipo de registro o un elemento de datos) o para reducir la base de datos (eliminando un tipo de registro o un elemento de datos). En el segundo caso, la modificacin no deber afectar a los esquemas externos que slo se refieran a los datos restantes. Si en el SGBD se cuenta con independencia lgica de datos, slo ser preciso modificar la definicin de la vista y las correspondencias. Despus de una reorganizacin lgica del esquema conceptual los programas de aplicacin que hagan referencia a los elementos del esquema externo debern funcionar igual que antes. Adems, las restricciones podrn modificarse en el esquema conceptual sin afectar a los esquemas externos ni a los programas de aplicacin.

2. Independencia fsica de los datos, es la capacidad de modificar el esquema interno sin tener que alterar el esquema conceptual (o los externos). Tal vez sea preciso modificar el esquema interno por la necesidad de reorganizar ciertos ficheros fsicos (por ejemplo, al crear estructuras de acceso adicionales) con el fin de mejorar el rendimiento de las operaciones de recuperacin y actualizacin. Si la base de datos an contiene los mismos datos, no ser necesario modificar el esquema conceptual.

En todo SGBD de mltiples niveles es preciso ampliar el catlogo de modo que incluya informacin sobre cmo establecer la correspondencia entre las solicitudes y los datos entre los diversos niveles. El SGBD utiliza software adicional para realizar estas correspondencias haciendo referencia a la informacin de correspondencia que se encuentra en el catlogo.

La arquitectura de tres esquemas puede facilitar la consecucin de la verdadera independencia de datos, tanto fsica como lgica. Sin embargo, los dos niveles de correspondencias implican un gasto extra durante la compilacin y la ejecucin de una consulta o de un programa, lo cual reduce la eficiencia del SGBD. Por ello, son pocos los SGBD que han implementado la arquitectura de tres esquemas completa.

Por ejemplo

2.1 Introduccin

Una caracterstica fundamental del enfoque de base de datos es que proporciona cierto nivel de abstraccin de los datos, al ocultar detalles de almacenamiento que la mayora de los usuarios no necesitan conocer. Un modelo de datos proporciona los medios necesarios para conseguir dicha abstraccin.

En este entendido modelar consiste en definir un mundo abstracto y terico tal que las conclusiones que se pueden sacar de l coinciden con las manifestaciones aparentes del mundo real.

Modelo

Es una representacin de la realidad que contiene las caractersticas generales de algo que se va a realizar. En base de datos, esta representacin la elaboramos de forma grfica.

Modelo de datos

Es una coleccin de herramientas conceptuales para describir los datos, las relaciones que existen entre ellos, semntica asociada a los datos y restricciones de consistencia, adems de ser un dispositivo de abstraccin que nos permite ver el bosque (esto es, la informacin contenida en los datos) en oposicin de los rboles (valores individuales de los datos).

Abstraccin

Es la accin y el efecto de abstraer, separar por medio de una operacin intelectual las cualidades de un objeto para considerarlas asiladamente o para considerar el mismo objeto en su pura esencia o nocin. Por tanto, la abstraccin, como proceso mental capaz de ocultar detalles y fijarse en lo esencial, busca las propiedades comunes de un conjunto de objetos, reduciendo as la complejidad y ayudando a la comprensin del mundo real.

2.2 La importancia de los modelos de datos

Inicialmente el "dato" fue trabajado desde la ptica pura de su almacenamiento a travs de los "Sistemas de Archivos"; donde cada uno de los archivos que se creaban solo obedeca a una necesidad de almacenamiento ms que a la utilizacin funcional del dato. Por este motivo surgen los esquemas conceptuales que son elaborados a travs del anlisis de procesos de las reas del negocio, los conceptuales involucran al "dato" como una consecuencia lgica funcional de ellos. Pero para poder estandarizar este tratamiento se crea el concepto del "Modelo de Datos", por medio del cual se definen un conjunto de elementos y smbolos que permiten estandarizar traducir dicho anlisis a un lenguaje semntico y sistemtico que dispone de reglas de control y evaluacin del comportamiento del dato en el transcurso del tiempo, tanto en su almacenamiento como en su utilizacin.

Estos modelos de datos, hacen posible que la lgica de un negocio pueda ser estructurada de forma tangible a travs de un esquema fsico que representa el almacenamiento de los datos bajo las reglas del negocio y de un sistema gestor de base de datos que permitir la persistencia de estos a travs del tiempo.

2.3 Clasificacin de los modelos

Los diferentes modelos de datos se clasifican en tres grupos diferentes:

Modelos lgicos basados en objetos.

Modelos lgicos basados en registros.

Modelos fsicos de datos.

2.3.1 Modelos lgicos basados en objetos

Se usan para describir datos en los niveles conceptual y de visin, es decir, con este modelo representamos los datos de tal forma como nosotros los captamos en el mundo real, tienen una capacidad de estructuracin bastante flexible y permiten especificar restricciones de datos explcitamente. Existen diferentes modelos de este tipo, pero el ms utilizado por su sencillez y eficiencia es el modelo Entidad-Relacin.

Modelo Entidad-Relacin

Denominado por sus siglas como: E-R; Este modelo representa a la realidad a travs de entidades, que son objetos que existen y que se distinguen de otros por sus caractersticas, por ejemplo: un alumno se distingue de otro por sus caractersticas particulares como lo es el nombre, o el numero de control asignado al entrar a una institucin educativa, as mismo, un empleado, una materia, etc. Las entidades pueden ser de dos tipos:

Tangibles

Son todos aquellos objetos fsicos que podemos ver,tocar o sentir.

Intangibles

Todos aquellos eventos u objetos conceptuales que no podemos ver, aun sabiendo que existen, por ejemplo: la entidad materia, sabemos que existe, sin embargo, no la podemos visualizar o tocar.

Las caractersticas de las entidades en base de datos se llaman atributos, por ejemplo el nombre, direccin telfono, grado, grupo, etc. son atributos de la entidad alumno; Clave, nmero de seguro social, departamento, etc., son atributos de la entidad empleado. A su vez una entidad se puede asociar o relacionar con ms entidades a travs de relaciones.

Pero para entender mejor esto, veamos un ejemplo:

Consideremos una empresa que requiere controlar a los vendedores y las ventas que ellos realizan; de este problema determinamos que los objetos o entidades principales a estudiar son el empleado (vendedor) y el artculo (que es el producto en venta), y las caractersticas que los identifican son:

Empleado: Artculo:

Nombre Descripcin Puesto Costo Salario Clave R.F.C.

La relacin entre ambas entidades la podemos establecer como Venta.

Bueno, ahora nos falta describir como se representa un modelo E-R grficamente, la representacin es muy sencilla, se emplean smbolos, los cuales son:

Smbolo Representa

As nuestro ejemplo anterior quedara representado de la siguiente forma:

Existen ms aspectos a considerar con respecto a los modelos entidad relacin, estos sern considerados en el tema Modelo Entidad Relacin.

2.3.2 Modelos lgicos basados en registros

Se utilizan para describir datos en los niveles conceptual y fsico. Estos modelos utilizan registros e instancias para representar la realidad, as como las relaciones que existen entre estos registros (ligas) o apuntadores. A diferencia de los modelos de datos basados en objetos, se usan para especificar la estructura lgica global de la base de datos y para proporcionar una descripcin a nivel ms alto de la implementacin.

Los tres modelos de datos ms ampliamente aceptados son:

Modelo Relacional Modelo de Red Modelo Jerrquico

Modelo relacional

En este modelo se representan los datos y las relaciones entre estos, a travs de una coleccin de tablas, en las cuales los renglones (tuplas) equivalen a los cada uno de los registros que contendr la base de datos y las columnas corresponden a las caractersticas(atributos) de cada registro localizado en la tupla;

Considerando nuestro ejemplo del empleado y el artculo:

Tabla del empleado

Ahora te preguntaras cmo se representan las relaciones entre las entidades en este modelo?

Existen dos formas de representarla; pero para ello necesitamos definir que es una llave primaria: Es un atributo el cual definimos como atributo principal, es una forma nica de identificar a una entidad. Por ejemplo, el CI de un empleado se distingue de otro por que los CI no pueden ser iguales.

Ahora si, las formas de representar las relaciones en este modelo son:

1. Haciendo una tabla que contenga cada una de las llaves primarias de las entidades involucradas en la relacin.

Tomando en cuenta que la llave primaria del empleado es su CI , y la llave primaria del articulo es la Clave.

2. Incluyendo en alguna de las tablas de las entidades involucradas, la llave de la otra tabla.

Modelo de datos Red

Existen dos estructuras de datos bsicas en el modelo red: Registro y tipo de conjunto.

Registro, tipo de registro y elementos de datos

Los datos se almacenan en registros, cada registro consiste en un grupo de valores de datos relacionados entre s. Los registros se clasifican en tipos de registros, cada uno de los cuales describe la estructura de un grupo de registros que almacena el mismo tipo de informacin. Damos un nombre a cada tipo de registro, y tambin damos un nombre y un formato (tipo de datos) a cada elemento de dato (o atributo) del tipo de registro.

Ejemplo

ALUMNO

NOMBRE

RU

DIRECCIN

DPTO_ESPC

FECHA_NAC

Elemento dato

Nombre y Formato

NOMBRE

Carcter 15

RU

Numrico

DIRECCIN

Carcter 20

DPTO_ESPC

Carcter 15

FECHA_NAC

Fecha

Tipo de conjunto y sus propiedades bsicas

Un tipo de conjunto es una descripcin de un vinculo 1:N entre dos tipos de registros. As en el siguiente ejemplo se muestra que:

DEPARTAMENTO

NOMBRE

...

ALUMNO

NOMBRE

...

Donde:

DEPTO_ALU es un tipo de conjunto, que tiene ocurrencias de conjunto o instancias

Representar vnculos de M:N

Un tipo de conjunto representa un vnculo 1:N entre dos tipos de registros. Esto significa que un registro del tipo de registro miembro slo puede aparecer en una ocurrencia del conjunto. El SGBD garantiza automticamente esta restriccin en le modelo red. Si queremos representar un vnculo 1:1, el programa de aplicacin debe imponer la restriccin 1:1 adicional.

Un vnculo M:N entre dos tipos de registro no puede representarse con un solo tipo de conjunto.

As por ejemplo:

Consideremos el vnculo TRBAJA_EN entre EMPLEADO y PROYECTOS. Supongamos que un empleado puede trabajar en varios proyectos al mismo tiempo y que un proyecto casi siempre tiene varios empleados que trabajan en l.

Una representacin incorrecta es:

EMPLEADO

NUMERO_EMP

...

EMPLEADO

NUMERO_EMP

PROYECTO

NUMEROP

...

PROYECTO

NUMEROP

...

Representaciones incorrectas

El mtodo para representar un vnculo M:N en el modelo red es utilizar dos tipos de conjunto y un tipo de registro adicional. As por ejemplo para el caso anterior:

PROYECTO

NUMEROP

...

EMPLEADO

NUMERO_EMP

...

EMPLEADO

NUMERO_EMP

...

PROYECTO

NUMEROP

Por ejemplo

TRABAJA_EN

HORAS

...

Representaciones correctas

- Modelo de datos Jerrquico

Relaciones Padre-Hijo y esquema jerrquicos

Un modelo jerrquico utiliza dos conceptos principales de estructuracin de datos: registros y relaciones padres hijos.

Registro es la coleccin de valores de campo que proporcionan informacin sobre una entidad o una instancia de una relacin. Los registros del mismo tipo se agrupan en tipos de registros cada tipo de registro recibe un nombre y su estructura se define en trminos de una coleccin de campos con nombre o elementos de datos. Cada campo tiene un cierto tipo de datos, como entero, real o cadena de caracteres.

Un tipo de relacin padre hijo (tipo RPH) es una coleccin 1:N entre dos tipos de registro. El tipo de registro del lado 1 se denomina tipo de registro padre, y del lado N se llama tipo de registro hijo del tipo RPH.

Una ocurrencia (o instancia) padre- hijo del tipo de RPH consiste en un registro de tipo de registro padre y varios registros /cero o mas) del tipo registro hijo.

Un esquema jerrquico se visualiza como un diagrama jerrquico, en el cual los nombres de los tipos de registros aparecen en cuadros rectangulares y los tipos de RPH se dibujan como lneas que conectan el tipo de registro padre y el tipo de registro hijo.

Ejemplo

DEPARTAMENTO

NOMBRE

NUMEROD

NOMB_JEFE

FECHA_INIC_JEFE

EMPLEADO

NOMBRE

CI

FECHA_NCTO

DIRECC

PROYECTO

NOMBREP

NUMEROP

LOCALIZACION

Propiedades de los esquemas jerrquicos

1. Un tipo de registro, denominado raz del esquema jerrquico, no participa como tipo de registro hijo en ningn tipo de RPH.

2. Todo tipo de registro, con excepcin de la raz, participa como tipo de registro hijo en uno y solo en un tipo de RPH.

3. Un tipo de registro puede participar como tipo de registro padre en cualquier cantidad (cero o ms) tipos de RPH.

4. Un tipo de registro que no participa como tipo de registro padre en ningn tipo de RPH se denomina hoja del esquema jerrquico.

5. Un tipo de registro participa como padre en ms de un tipo de RPH, entonces sus tipos de registro hijo estn ordenados. El orden se visualiza por convencin, de izquierda a derecha en los diagramas jerrquicos.

La definicin de esquema jerrquico define una estructura de datos de rbol. En la terminacin de estas estructuras un tipo de registro corresponde a un nodo de rbol, y un tipo de RPH corresponde a una arista (o arco) del rbol.

Ejemplo

Las relaciones M:N entre tipos de registros no pueden representarse directamente porque las relaciones padre-hijo son 1:N, y un tipo de registro no puede participar como hijo en dos o ms relaciones padre-hijo distintas.

rbol de ocurrencia jerrquico

Las ocurrencias de los diferentes tipos de registros son graficadas manteniendo el orden del esquema jerrquico inicial.

Ejemplo

Esquema Jerrquico

DEPARTAMENTO

NOMBRE

NUMEROD

NOMB_JEFE

FECHA_INIC_JEFE

EMPLEADO

NOMBRE

CI

FECHA_NCTO

DIRECC

PROYECTO

NOMBREP

NUMEROP

LOCALIZACION

TRABAJADOR

NOMBRE

CI

HORAS

El esquema de ocurrencias para la ocurrencia Administracin de DEPARTAMENTO con los respectivos empleados y proyectos con los respectivos trabajadores es:

Administracin

Cuellar Ramirez Sosa Automatizacin Nuevos Beneficios

Lpez Galarza Angulo Prez Aguilar

Forma lineal izada de un rbol de ocurrencias jerrquicas

Un rbol de ocurrencias jerrquicas puede representarse en almacenamiento empleando una estructura de datos de entre la variedad de estructuras existentes. Sin embargo una de las estructuras de almacenamiento ms simples que podemos usar es el registro jerrquico, que es un ordenamiento lineal de los registros en un rbol de ocurrencias en el recorrido en pre orden del rbol (izquierda a derecha y en profundidad).

Relaciones padre hijo virtuales

El modelo jerrquico tiene problemas cuando se modelan ciertos tipos de relaciones. Entre ellos:

1. Relaciones M:N.

2. El caso en que un tipo de registros participa como hijo en ms de un tipo de RPH.

3. Relaciones n-arias con ms de dos tipos de registros participantes.

En una representacin M:N se usan relaciones Padre-Hijo Virtuales. As por ejemplo si en un proyecto trabajan varios empleados y un empleado trabaja en varios proyectos, el modelo jerrquico de esta relacin muchos a muchos en cualquiera de las dos formas, como sigue:

a)

(b)

Modelos fsicos de datos

Se usan para describir a los datos en el nivel ms bajo, aunque existen muy pocos modelos de este tipo, bsicamente capturan aspectos de la implementacin de los sistemas de base de datos. Existen dos clasificaciones de este tipo que son:

Modelo unificador Memoria de elementos.

Preguntas de repaso

1. Cul es la caracterstica fundamental del enfoque de las bases de datos?

2. Qu se entiende por modelar?

3. Contraste los trminos modelo, modelo de datos y abstraccin.

4. Cul la importancia de los modelos de datos?

5. Realice un cuadro en el cual seale las diferencia entre los tres grupos de modelos.

Ejercicios

1. Para la base de datos de un banco, organice los archivos siguientes en modelo jerarqua: PAGO, CUENTA DE AHORROS, DEPSITO, CLIENTE, CUENTA DE PRSTAMO, RETIRO DE DEPSITOS

2. Para la base de datos para una BIBLIOTECA organice los archivos en un modelo jerrquico: LIBRO, SOCIO, PRSTAMO, DEVOLUCIN

REFERENCIAS BIBLIOGRFICAS

(1) Rames A. Elmasri & Sahamkant B. Navathe, FUNDMENTOS DE SISTEMAS DE BASE DE DATOS, Madrid, De. Addison Wesley, 2000

(2) Silberschatz & Korth & Sudarshan, FUNDMENTOS DE BASE DE DATOS, Madrid, Mc Graw Hill, 2002

3.1 Modelo Conceptual

Un modelo conceptual es la forma en la que podemos describir los requerimientos para los datos de los negocios usando una sintaxis rica semnticamente a travs de representaciones grficas. Podemos describir muchos de las reglas de negocio con elementos grficos tales como subtipos (generalizacin especializacin) y relaciones.

3.2 Definicin del Modelo E/R

El modelo Entidad Relacin es un modelo conceptual acerca de un negocio. Para ser ms precisos: este es un modelo de los requerimientos de un negocio basado en la funcionalidad de un futuro sistema que se desea.

Para modelar un negocio usted tiene que comprender los detalles acerca del negocio.

El Modelo Entidad Relacin es una tcnica usada para describir la informacin necesaria de un negocio. Esta es una tcnica bien establecida a travs de diagramas que permiten la facilidad de lectura y tambin fcil verificacin.

3.3 Objetivos del Modelo

Los objetivos del modelo son para asegurar que:

Todas las piezas de informacin que son requeridos para que marche un negocio correctamente, son reconocidas. Los modelos deben ser completos. Los requerimientos deben ser reconocidos antes que usted empiece a implementar. Las dependencias deben ser claras.

Cada pieza de informacin requerida se muestra una sola vez en el modelo. Este es un objetivo importante. Tan pronto se almacena una informacin particular, dos veces en un sistema, usted ve la posibilidad de que la informacin no este al mismo tiempo en dos lugares. Si usted fuera un usuario de un sistema de informacin y descubre inconsistencia en el dato, cul informacin podra ser de confianza? Este objetivo implica que un sistema ideal no contenga informacin derivable.

Un modelo entidad relacin correcto, conduce a un conjunto de tablas lgicamente coherentes.

3.4 Terminologa utilizada en el Modelo

3.4.1 Entidad

Una entidad es un objeto que existe y es distinguible entre otros objetos, a travs de un identificador.

Algunos ejemplos de entidades son:

Personas: MDICOS, EMPLEADO, ESTUDIANTES, PACIENTES

Lugares: ESTADO, REGIN, SUCURSAL, SECCIN, MUNICIPIO

Objeto: MAQUINA, EDIFICIO, AUTOMVIL, PRODUCTO

Eventos: VENTAS, REGISTRO, COMPRA, ELECCIN, PEDIDO, RETIRO

Conceptos: CURSO, CARGO

Instancia de entidad es una ocurrencia simple de una entidad. Por ejemplo:

ENTIDADES

INSTANCIAS

PERSONA

Felipe Quispe

PRODUCTO

Papel Oficio

CARGO

Mximo dirigente

RESERVACIN DE PASAJE

Noche: La Paz Santa Cruz

PLANILLA

350.3 Bs.

Entonces decimos, que una entidad representa un conjunto de instancias que son de inters para un negocio en particular.

3.4.2 Entidad Dbil

El modelo E-R define un tipo especial de entidad dbil. Tales entidades son aquellas cuya presencia en la base de datos depende de la presencia de otra entidad.

3.4.3 Atributo

Un atributo es una propiedad o caracterstica de una entidad que es de inters para la organizacin.

Cada entidad tiene un conjunto de atributos asociados con ste.

ENTIDADES

ATRIBUTO

EMPLEADO

Nombre, Edad, Direccin

AUTO

Modelo, Precio, Placa

PEDIDO

Fecha de Pedido, Total

CARGO

Titulo, Descripcin

TRANSACCIN

Cantidad, Fecha de Transaccin

CONTRATO DE EMPLEADO

Fecha de Inicio, Salario

3.4.5 Claves candidatas e identificadores

Llaves candidatas

Una llave candidata es un atributo (o combinacin de atributos) que identifica de manera nica a cada instancia de una entidad. Por ejemplo, para la entidad:

MUNICIPIO: ID_Municipio, Nombre, Departamento, Caractersticas

Su llave candidata ser:

ID_Municipio

Algunas veces ms de un atributo es requerido para identificar las instancias una entidad.

Por ejemplo,

JUEGO: Equipo_Local, Equipo_Visitante

Claramente se observa que la llave candidata es: Equipo_Local, Equipo_Visitante

Algunas veces las entidades pueden tener ms de una llave candidata.

Una llave candidata para:

MUNICIPIO: ID_Municipio, Nombre, Departamento, Caractersticas

es:

ID_Municipio

Nombre

Si hay ms de una llave candidata, como en este caso, entonces el diseador puede elegir una de las llaves candidatas como identificador.

Identificador

Un identificador es una llave candidata que es seleccionada para ser usada como caracterstica nica de una entidad.

( Consideraciones para seleccionar un identificador

a) Elegir una llave candidata que no cambiara los valores de las instancias de la entidad durante su existencia.

b) Elegir una llave candidata, tales que, para cada instancia de la entidad, el atributo garantiza valores vlidos y que no sean nulos.

c) Evitar el uso de las tan llamadas llaves inteligentes, cuya estructura indica clasificacin, localizacin, etc. Por ejemplo, los dos primeros dgitos de la llave de una entidad PARTE puede indicar la localizacin del almacn.

d) Si tiene llaves compuestas, es decir formado por dos o ms atributos, puede sustituir por un atributo simple. Por ejemplo, un atributo llamado ID_Juego en ves de la combinacin de atributos Equipo_Local, Equipo_Visitante del ejemplo anterior.

3.4.6 Atributos Multivaluados

Un atributo multivaluado puede tomar mas de un valor para cada instancia de una entidad.

Tomemos como ejemplo el atributo Especialidad de una entidad llamada EMPLEADO. Si cada empleado tiene mas de una especialidad, entonces Especialidad es un atributo multivaluado.

3.4.7 Relaciones

Una relacin es una asociacin entre las instancias de una o ms entidades que es de inters para la organizacin. Una asociacin usualmente significa un evento ocurre o que existe algn enlace natural entre las instancias de entidad. Por esta razn, las relaciones son etiquetadas con verbos. Por ejemplo,

TCNICO revisa PROYECTO

PERSONA consulta DOCTOR

Notacin Entidad Relacin

3.5 Grados de una relacin

El grado de una relacin es el nmero de entidades que participan en la relacin. Las tres relaciones mas comunes en el modelo E-R son unaria (grado uno), binaria (grado dos) y ternaria (grado tres).

(Relaciones Unarias

Notacin

Llamadas tambin relaciones recursivas, una relacin unaria es una relacin entre las instancias de una entidad.

Por ejemplo

(Relaciones Binarias

Notacin

Una relacin binaria es una relacin entre instancias de dos entidades y es el ms comn de las relaciones en el modelo de datos.

Por ejemplo

Relacin ternaria

Notacin

Una relacin ternaria es una relacin simultnea entre las instancias de tres entidades.

Por ejemplo

Note que una relacin ternaria no es lo mismo que una relacin binaria. Por ejemplo, Cantidad es un atributo de la relacin Envo. Cantidad pude ser atributo propio de la asociacin binaria que pueda existir entre dos de las tres entidades

3.6 Cardinalidad de relaciones y participaciones

Supongamos que hay dos tipos de entidades, A y B, que estn conectadas por una relacin. La cardinalidad de una relacin es el nmero de instancias de la entidad B que puede o debe estar asociada con cada instancia de la entidad A.

Por ejemplo

3.6.1 Cardinalidad Mnima y Mxima

Cardinalidad Mnima

La cardinalidad mnima de una relacin es el nmero mnimo de instancias de una entidad B que puede estar asociada con cada instancia de la entidad A.

En el ejemplo, el nmero mnimo de CELULAR que pertenece a un ESTUDIANTE es CERO, es el caso en que decimos que un CELULAR es una PARTICIPACIN OPCIONAL en la relacin TIENE. Luego, el nmero mnimo de ESTUDIANTE que tiene cero o mas celulares es UNO, es el caso en que decimos que un ESTUDIANTE es una PARTICIPACIN OBLIGATORIA en la relacin tiene.

,O

Cardinalidad Mxima

La cardinalidad mxima es el nmero mximo de instancias. Es decir el mximo es muchos, no se especifica cuantos.

Entonces en el ejemplo anterior, la cardinalidad mxima de la entidad ESTUDIANTE es UNO, y en la entidad CELULAR es de muchos.

3.6.2 Tipos de relaciones

Existen tres grupos principales de relaciones.

Uno a uno

Muchos a muchos

Uno a muchos

RELACIN

DIAGRA E-R

Uno a uno

Muchos a Muchos

Uno a Muchos

Sea el siguiente ejemplo:

Para este caso se pueden dar diferentes combinaciones de cardinalidad mxima y mnima, y participacin.

Casos de participacin de las entidades

Opcional opcional: Cada empleado puede tener exactamente un nico trabajo. Un trabajo puede estar ocupado por uno o ms empleados

Obligatorio opcional: Cada empleado debe tener exactamente un trabajo. Un trabajo puede estar ocupado por uno o varios empleados

Opcional Obligatorio: Cada empleado puede tener exactamente un trabajo. Un trabajo debe estar ocupado por uno o ms empleados

Obligatorio obligatorio: Cada empleado debe tener exactamente un trabajo. Un trabajo debe estar ocupado por uno o ms empleados

Busque entidades para cada caso, que cumpla con las participaciones e indique las cardinalidades.

Opcional opcional

Obligatorio opcional

Opcional Obligatorio

Obligatorio obligatorio

3.7 Generalizacin

La generalizacin se usa para hacer resaltar los parecidos entre tipos de entidades de nivel ms bajo y ocultar sus diferencias. La distincin se hace a travs de un proceso llamado herencia de atributos. Los atributos de los conjuntos de entidades de nivel ms alto se dice que son heredados por los conjuntos de nivel mas bajo.

Notacin grafica

Ejemplo

3.8 Agregacin Y Entidades Asociativas

Se llama entidades asociadas cuando dos entidades se asocian en una sola as por ejemplo:

Claramente se nota que la relacin vende tiene sus propios atributos.

Sea una relacin ternaria, como se muestra a continuacin:

La relacin ternaria tiene caractersticas indeseables, tales como:

No es significativa para etiquetar el diagrama E-R con las relaciones, uno a muchos, muchos a muchos, o muchos a uno. Si la relacin VENDEDORES a ALMACEN es muchos a uno y la relacin VENDEDORES a PARTES es uno a muchos, la etiqueta entre VENDEDORES y ENVIO debe contener uno y muchos.

Las relaciones ternarias se maneja con dificultad. Al interactuar muchas entidades, aumenta la posibilidad de equivalencia relacional no normal, por que los diseadores pueden crear de manera inadvertida, relaciones con atributos que dependan de un subconjunto de las entidades en la relacin. Esta situacin puede ser la causa de representaciones no FNBC. Por ejemplo, en la figura, la inclusin del atributo Cantidad (ENVIO TOTAL PARTES POR VENDEDOR) en ENVIO, hace que la relacin correspondiente sea no FBNC. La clave de la relacin que corresponde a ENVIO es (V#, P#, NumAlm); Cantidad solo depende de parte de esta clave, es decir, de (V#, P#).

Algunos autores proponen que nada ms se permitan relaciones binarias en el modelo de la empresa. De esta manera cada conjunto de relacin binaria se transforma en una relacin cuyas claves son los identificadores de las entidades que interactan. Para lograrlo, las relaciones con ms de una entidad se deben reducir a relaciones binarias, lo cual conduce al concepto de agregacin. Por ejemplo las relaciones ENVIO en la figura anterior se divide primero en relaciones binarias entre VENDEDOR y ALMACEN como se muestra en la figura.

Aqu la entidad VENDEDOR se asocia con la entidad PARTES, y a la entidad asociada se le agrega la entidad ALMACN.

Ejercicios propuestos

1. Libro

Meta

La meta de esta prctica es para diferenciar entre varios significados de una palabra usado en el texto.

Ambiente de Aplicacin

1. He finalizado de escribir un libro. Este es una novela acerca de justicia y poder.

2. Nosotros tenemos publicado este libro. La edicin de la tapa dura est disponible ahora.

3. Usted ley el nuevo libro sobre Picazo? Es bueno

4. Si usted gusta puede pedir prestado mi libro.

5. Tengo empezado la traduccin de este libro en espaol. Uso el ingls moderno en el texto como una base y no el original, el cual es del siglo XVI

6. Pedir el libro para mis parientes.

7. Si nosotros tenemos el libro disponible usted debe buscarlo en los libros de Arte.

8. La segunda impresin del libro Paz y Guerra es muy raro.

9. Pienso que Mi nombre es Asher Leo es uno de los mejores libros que he escrito en mi vida. Es dedicado a Mara.

10. Quiero escribir un libro sobre el modelo ER cuando me retire.

Su Tarea

1. En este texto la palabra libro es usado con muchos significados. Estos significados son diferentes entidades en el contexto de una compaa de publicacin. Pruebe para distinguir varias, todas referidas al libro. D los nombres ms adecuados para estas entidades y d uno o dos atributos para distinguirlos.

2. Cree un modelo ER basado en el texto. Ponga la entidad ms general arriba de su pgina y el ms especfico en abajo. Y las otras entidades entre estas.

3. Una construido el modelo conceptual bajar a tablas.

2. Un centro comercial est organizado por departamentos, cuyos empleados puede ser jefes o vendedores, cada uno de ellos perteneciente a un nico departamento. Cada departamento tiene un nico jefe y un departamento puede tener varios jefes. Cada departamento tiene sus propios productos que son suministrados por distintos proveedores a un determinado precio. Una venta la realiza un vendedor a un cliente y puede incluir varios productos.

Construir el modelo E/R con los atributos pertinentes indicando aqullos que son clave.

3. Suponga que estamos modelando los datos de una COMPAIA. La base de datos COMPAIA debe mantener informacin sobre los empleados de la compaa, los departamentos y los proyectos. La descripcin del mini-mundo (la parte de la compaa a ser representada en la base de datos) es la siguiente:

1. La compaa est organizada en departamentos. Cada departamento tiene un nombre nico, y un empleado particular que lo administra. Se quiere saber la fecha en la que el empleado administrador empez a hacerse cargo del departamento. Un departamento puede tener varios locales (localizaciones), cada uno con un nombre nico.

2. Cada departamento controla un cierto nmero de proyectos. Cada proyecto tiene un nombre nico, y un local donde se realiza dicho proyecto, que es exclusivo para ese proyecto (no puede haber 2 proyectos realizndose en el mismo local). Puede haber localizaciones en la empresa en las que todava no se est realizando ningn proyecto.

3. Para cada empleado se desea tener su nombre completo (compuesto por nombre, primer apellido y segundo apellido), d.n.i., direccin, salario, sexo y fecha de nacimiento. Un empleado es asignado a un departamento, pero puede trabajar en varios proyectos, aunque estos proyectos no son necesariamente controlados por el mismo departamento. Se quiere saber el nmero de horas semanales que un empleado trabaja en cada proyecto. Se quiere adems saber cul es el empleado supervisor que supervisa a cada empleado. En un proyecto pueden trabajar varios empleados.

4. Se desea conocer las personas dependientes de cada empleado, para propsitos de seguros. De cada persona dependiente se desea conocer el nombre, sexo, fecha de nacimiento y relacin con el empleado. Por ejemplo, un empleado puede cubrir con su seguro al resto de miembros de su familia (sus personas dependientes).

REFERENCIAS BIBLIOGRFICAS

(1) Hawryszkiewcz (1994). Mxico, ANLISIS Y DISEO DE BASE DE DATOS, De. Megabyte, p. : 3 49

(2) Gary, Hansen James, Hansen (1997 ). Madrid, DISEO Y ADMINISTRACIN DE BASE DE DATOS, De. Pretince Hall, p. : 84

(3) Hoffer, George (1999). Valacich,E.E.U.U. ,MODERN SYSTEMS ANLISYS & DESIGN, De. Adison, p.: 319

(4) Kroenke, Mxico, PROCESAMIENTO DE BASE DE DATOS FUNDAMENTOS Y DISEO, De. Pretince may, 1985, p.: 55

4.1 Por qu crear un diseo de base de datos?

El modelo ER describe los datos requeridos para los negocios. Este modelo debera ser totalmente independiente de algunas consideraciones que se realizan para la implementacin. Este mismo modelo ER podra tambin ser usado como una base para la implementacin de algn tipo de DBMS o incluso un sistema de archivos.

Un modelo ER es una representacin de muy alto nivel el cual no puede ser implementado tal y como est.

Las personas que crean estos modelos no pueden estar conscientes de lo fsico y las necesidades de la base de datos, pero ellos tendrn que proporcionar una solucin conceptual laborable. Esto es, por que es importante tener un modelo ER de acuerdo a la realidad y validado antes de ir al diseo de la base de datos fsica.

Transformando el modelo ER, se crea un primer corte del diseo de la base de datos. Este diseo del primer corte es pensado para servir como una nueva base para definir la implementacin fsica de la base de datos.

Este nuevo modelo puede ser fcilmente usado para las discusiones futuras entre diseadores y desarrolladores, y administradores de bases de datos.

4.2 Presentacin y Orgenes del Modelo Relacional

El modelo Relacional fue introducido por Codd en el ao 1970.

Es un Modelo de Datos Lgico - de Representacin (basado en registros).

El modelo ms usado en las aplicaciones comerciales de procesamiento de datos convencional. Esta dividido en 3 partes:

1. Estructura de Datos

2. Integridad de Datos (caractersticas generales)

3. Manipulacin de Datos

4.3 Estructura de datos relacional

En el Modelo Relacional es una:

Base de Datos = Conjunto de RELACIONES

Relacin est representada mediante una Tabla con filas y columnas

Estructura de datos fundamental del modelo

Representa una entidad genrica

Tiene un nombre

Conjunto de FILAS

Cada fila representa una entidad concreta

Compuesta de COLUMNAS, con nombre

Cada columna representa un atributo de la entidad

Modelo basado en Teora matemtica

Analoga entre Relacin (concepto matemtico) y Tabla

Teora de Conjuntos y Lgica de Predicados de 1er orden

Tiene una slida Base Formal

Ejemplo

EMPLEADO

Id

Nombre

Direccin

Fecha_nacimiento

Id_Dpto

126

Flores

2, Munaypata

03-03-66|

10

349

Leon

53, El Alto

10-08-77

20

785

Condori

08-12-55

10

4.4Trminos Bsicos en el Modelo Relacional

Relacin (Tabla):. Una tabla es una estructura muy simple en el cual los datos son organizados y almacenado. Las tablas tienen columnas y filas. Cada columna es usada para almacenar un tipo de valor. En el ejemplo, la tabla EMPLEADO es la estructura para almacenar informacin acerca de los empleados.

Tupla (Fila). Si la tupla t est en la relacin R entonces t R. Cada fila describe una ocurrencia de un empleado. En el ejemplo, cada fila describe todas las propiedades requeridas para el sistema.

(Atributo)(columna). Debe tener un nombre nico dentro de cada relacin. Cada columna almacena informacin de una tipo especfico como ID, Nombre, Direccin, Fecha_nacimiento y el ID del departamento asignado al empleado.

Cardinalidad. Numero de tuplas en una relacin. Ejemplo en la relacin empleado la cardinalidad es de 3.

Grado. Numero de atributos en una relacin.

Ejemplo

La relacin Empleado es de grado 5.

Dominio. Coleccin de valores permitidos para ciertos atributos.

4.5 Definiciones Formales

4.5.1 Dominio

Conjunto de valores atmicos del mismo tipo, donde toman su valor los atributos.

La definicin de dominios forma parte de la definicin de la BD

Cada atributo definido sobre un NICO dominio OBLIGATORIO

Si A, B representan un mismo concepto, A y B con mismo dominio

Dominio D puede contener valores no tomados por ningn atributo

{valores de A}

Dominio(A)

Comparaciones Restringidas a Dominio

La comparacin de dos atributos slo tiene sentido si ambos toman valores del mismo dominio

Si el SGBD soporta dominios, podr detectar este tipo de errores

4.5.2 Relacin

Una relacin R, sobre conjunto de dominios D1, D2 ... Dn se compone de dos partes:

Esquema o Cabecera: Conjunto de pares Atributo:Dominio

{ (A1:D1), (A2:D2) ... (An:Dn) }

Cada Aj tiene asociado slo un Dj

Los Di no tienen por qu ser distintos entre s

Estado, Cuerpo o Instancia

Conjunto de tuplas que contiene en un instante concreto

tupla = conjunto de pares Atributo:Valor

{ { (A1:vi1), (A2:vi2) ... (An:vin) } }, donde i=1..m

Ejemplo

Un esquema de relacin ser:

EMPLEADO (Id:Ids, Nombre:Nombres, Direccin:Direcciones, Fecha_Nacimiento:Fechas, Id_Dpto:Ids )

Un estado de la relacin ser:

{ { (Id:126), (Nombre:Flores), (Direccin: 2,Munaypata), (Fecha_nacimiento:03-03-66) (Id_dpto: 10) }

{ { (Id:349), (Nombre:Leon), (Direccin: 53,El Alto), (Fecha_nacimiento:10-08-77) (Id_dpto: 20) }

El estado de una relacin es variable en el tiempo

nuevas tuplas, modificacin o borrado de existentes

El esquema no suele variar, porque puede ser costoso debido a que implica:

Reescritura de miles de tuplas

valores de nuevos atributos para tuplas ya existentes?

Suele incluir un conjunto de Reglas de Integridad (se ver ms adelante)

4.5.2.1 Propiedades de una relacin

1. No existen tuplas repetidas

2. Las tuplas no estn ordenadas

3. Los atributos no estn ordenados

esquema = conjunto de pares Atributo:Dominio

4. Los valores de atributos son Atmicos

Pq Dominio = Conjunto de valores atmicos

Interseccin fila/columna = un solo valor (no lista de valores)

Si R cumple esta propiedad, R est en 1FN

4.5.2.2 Relacin vs. Tabla

Relacin: Representacin abstracta de elemento o entidad de datos

Tabla: Representacin concreta de tal elemento abstracto

Ventajas

Representacin muy sencilla (tabla) del elemento abstracto

bsico (relacin) del Modelo Relacional

Fcil de utilizar, entender, razonar...

Inconveniente

Aparente orden entre filas y entre columnas de la tabla

4.5.3 Base de Datos Relacional

Una base de datos relacional es percibida por el usuario como una coleccin de relaciones.

De diversos grados (numero de atributos)

Que varan con el tiempo (numero de tuplas, estado)

Las relaciones (tablas) son la estructura lgica de la BD

Niveles externo y conceptual ANSI/X3/SPARC

Toda BDR cumple el Principio de Informacin: Todo contenido de informacin de la BD est representado de una y slo una forma: como valores explcitos dentro de posiciones de columnas dentro de filas dentro de tablas.

Conexin lgica entre Relaciones (vnculo o interrelacin)

Representada mediante valores

No existen punteros (visibles al usuario)

En una BDR distinguimos...

Esquema de base de datos

Descripcin de la base de datos

Conjunto de esquemas de relacin

EMPLEADO (Id: Ids, Nombre: Nombres, Direccin: direcciones, Fecha_nacimiento: fechas, Id_dpto:Ids)

DEPARTAMENTO (Id_dpto: Ids, Nombre_dpto:Nombres)

Estado o instancia de base de datos

Visin del contenido de la base de datos en cierto instante

Conjunto de estados de relacin

4.6 Caractersticas Generales de Integridad

Todo estado de BD refleja la realidad:

Es un MODELO de una PORCIN del mundo real (minimundo)

Algunas configuraciones de valores NO tienen SENTIDO

pues NO REPRESENTAN ningn estado posible del minimundo

Ejemplos

Dos personas distintas con el mismo CI

Un empleado sin Id

Un alumno con -29 aos

Una pelcula sin director

La definicin de la BD (esquema) necesita incluir: REGLAS DE INTEGRIDAD

4.6.1 Reglas de Integridad

El modelo de datos conceptual es un proceso paso a paso para documentar requerimientos de informacin que es concerniente a la estructura de datos y las reglas de integridad de los datos. Las reglas de negocio son especificaciones que preservan la integridad del modelo lgico. Hay cuatro tipos de reglas de negocio:

Integridad de Entidad

Integridad Referencial.

Dominio.

Operaciones Triggers

Las reglas de integridad informan al SGBD de restricciones del mundo real.

As, el SGBD evita configuraciones de datos imposibles

Aumentan la capacidad expresiva del modelo relacional

Son especficas de cada BD particular, pero el Modelo Relacional incluye...

Caractersticas generales de integridad importantes y necesarias en toda BD

Claves Candidatas y Primarias

Claves Ajenas (o forneas o externas)

4.6.1. 1 Superclave y clave de una relacin

Sea R una relacin R(A1:D1 , A2:D2 ,... An:Dn )

Una superclave de R es un subconjunto SK de atributos tal que cumple la restriccin de Unicidad es decir: No existen dos tuplas distintas con la misma combinacin de valores para SK

Una clave de R es una superclave tal que cumple la restriccin de Irreductibilidad esto significa que: Ningn subconjunto de CK cumple la restriccin de Unicidad

Clave Simple (1 atributo) o Compuesta (varios atributos)

Cada clave es una restriccin de integridad

Ejemplos

Claves como restriccin de integridad:

CLIENTE (codCliente, nombre, ciudad, telefono,...)

Qu implicaciones tiene establecer como clave...

a) CK = {codCliente, ciudad}

b) CK = {codCliente}

Varias claves en una relacin

Relacin para registrar las visitas de pacientes a sus mdicos de familia. Un mismo

paciente puede visitar a su mdico varias veces en un mismo da

VISITAMEDICA (nssPaciente, historial, fecha, hora, numVisita, medico, observ)

Claves (VISITAMEDICA)={ {nssPaciente, numVisita}, {nssPaciente, fecha,

hora}, {historial, numVisita}, {historial, fecha, hora} }

4.6.1.2 Clave candidata, primaria y alternativa

Si R tiene varias claves ( Claves Candidatas

Claves (ACTOR) = { {nombre}, {nombreArtistico} }

Claves (EMPLEADO) = { {Id}, {nombre, fecha_Nacimiento,},{nss} }

La Clave Primaria (Primary Key, PK ) es la clave candidata elegida para identificar las tuplas de R

Clave Primaria (ACTOR) = {nombreArtistico}

Clave Primaria (EMPLEADO) = {nss}

Las Claves Alternativas (AK) son el resto de claves candidatas

Claves Alternativas (ACTOR) = {nombre}

Claves Alternativas (EMPLEADO) = { {dni}, {nombre, fechaNac} }

4.6.1.3 clave ajena (externa o fornea)

Conjunto de atributos FK de una relacin R2, tal que:

1. Existe otra relacin R1 con clave primaria PK , y

2. Cada valor de FK en R2 es idntico al de PK en alguna tupla de R1

Una clave fornea es un conjunto de atributos de una relacin que hace referencia a la clave primaria de otra relacin (o la misma).

PELICULA (ttulo, gnero, duracin, director, ...)

DIRECTOR (nombre, nacionalidad, ...)

EMPLEADO (codEmp, nombre, jefe, nss, ...)

LIBRO (ttulo, isbn, autor, editorial, edicin, ao, ...)

ESCRITOR (dni, nombre, ...)

ARTICULO (ttulo, tema, autor, revista, pgina, ...)

Cada componente de una FK debe estar definido sobre el mismo dominio que el correspondiente atributo de la PK a la que referencia

PACIENTE (nss, nombre, direccin, ...)

HISTORIAL (nss, especialidad, fechaApert, ...)

VISITA (nss, especialidad, numVisita, fecha, ...)

La clave Ajena puede ser Simple o Compuesta

El uso de Claves Ajenas facilita a:

Eliminacin de la Redundancia: Integridad entre ficheros

Mecanismo del Modelo Relacional de datos para establecer VNCULOS ENTRE RELACIONES

EJEMPLO

En las siguientes relaciones:

CUENTA

NUMERO

SALDO

200

35000

505

45000

821

30000

CLIENTE

NOMBRE

DIRECCION

CIUDAD

CUENTA

Garca

San Pedro

La Paz

200

Lopez

Santa Rosa

El Alto

821

Blanco

Villa Ftima

La Paz

505

Cada cliente slo puede tener una cuenta a su nombre. Una cuenta puede tener ms de un cliente como titular.

La Restriccin de Integridad Referencial dice que: Todo valor de una FK debe coincidir con un valor en la correspondiente PK

La BD no debe contener claves ajenas sin correspondencia: Si una tupla en una relacin hace referencia a otra relacin, debe referirse a una tupla existente en esa relacin

EJEMPLO

ARTICULO ESCRITOR

Puede existir algn valor de PK al que NO haga referencia ningn valor de la FK

ESCRITOR que no haya escrito artculos: ninguna tupla de ARTICULOhar referencia a la tupla correspondiente a dicho escritor

Diagrama Referencial

Expresin de la existencia de Claves Ajenas

Camino Referencial

LIBRO

Cod

Titulo

Autor

Editorial

EDITORIAL

Nombre

Direccion

ESCRITOR

Cod_aut

Nombre

editorial

ARTICULO

Titulo

Tema

autor

revista

pag

Ciclo Referencial: es un camino que empieza y acaba en la misma relacin. Un caso especial es la Autorreferencia

EMPLEADO

Id

Nombre

Fecha_nac

Dep

DEPARTAMENTO

Id_dpto

Dire

EMPLEADO

Id

Jefe

4.6.1.4 Mantenimiento de la Integridad Referencial

Las operaciones que no satisfacen violan la Integridad Referencial, dejan la BD en un estado incorrecto

Ejemplo

Sea el ambiente de aplicacin Hotel

Qu pasara si se eliminara la tupla (501, D, ...) en HABITACIN?

Y si se eliminara la tupla (100, D, ...)?

Y si se anotara la ocupacin de la habitacin 900?

Cmo evita el SGBD esos estados incorrectos?

El SGBD puede...

Rechazar toda operacin que pueda provocar un estado ilegal,

Aceptar (y ejecutar) tales operaciones, pero realizar acciones que restauren la integridad de los datos

Diseador de la BD puede especificar al SGBD: Acciones de Mantenimiento de la Integridad Referencial para que la BD SIEMPRE alcance un estado final legal

R2 R1

Operacin: Eliminar una tupla t de R1 que es referenciada por otras de R2

Ejemplo

Eliminar la tupla (100, D, ...) de HABITACIN

Acciones posibles:

1. Rechazar la operacin (accin por defecto). Slo permite borrar t si ninguna otra tupla hace referencia a t

2. Cascada. Propagar la eliminacin

1 Borrar todas las tuplas de R2 que referencian a t

2 Eliminar t

3. Establecer nulos

Operacin: Modificar el valor de una FK a un valor no existente en la PK de R1

Ejemplo

Modificar (CLI02, 420,...) a (CLI02, 900,...) en OCUPACIN

Accin:

1. Rechazar la operacin (SIEMPRE). Intento de violacin de la restriccin de Integridad Referencial

Operacin: Insercin de una tupla t en R2 cuyo valor de FK no se corresponde con ningn valor de la PK en ninguna tupla de R1

Ejemplo

Insertar una tupla (CLI03, 555, ...) en OCUPACIN

Acciones posibles:

- Rechazar la operacin (SIEMPRE). Intento de violacin de la restriccin de Integridad Referencial

Encadenamiento de eliminaciones (anlogo para Modificacin)

R2(R1, Accin de Eliminacin en Cascada R3(R2(R1

R3 (R2, Accin de Eliminacin X

- Eliminar una tupla de R1 ( eliminar tuplas de R2 que la referencian

- Pero existen tuplas en R3 que referencian esas tuplas de R2...

cmo afecta la Accin de Eliminacin X en esta operacin?

Si X = en CASCADA, no-problemo! ( eliminar esas tuplas de R3

Si X = RECHAZAR ( La operacin completa fallar

Las operaciones de actualizacin en una BD son siempre atmicas: se realiza TODO o NADA

PROFESOR ( REA (DEPARTAMENTO

ASIGNATURA (TITULACIN (UNIVERSIDAD

4.6.1.5 Valores Nulos

En el mundo real existe...

Informacin perdida fechaNacimiento desconocida

Ausencia de informacin tiene telfono?

Valores no aplicables a ciertos atributos fechJubilac a empleado activo

Para representar estas situaciones en los sistemas de BD se utiliza el NULO (null)

Si una tupla tiene un atributo que contiene un nulo, significa que el valor real de tal atributo es desconocido

Es posible especificar si un atributo puede o no contener nulo. Nulo no es un valor en s mismo, sino un indicador de ausencia de informacin.

No hay dos nulos iguales (num_telefono NULL edad NULL)

Implicaciones de los Nulos en la Integridad

NULO y Claves Primarias:

Restriccin de Integridad de Entidad: Ningn atributo componente de una clave primaria puede contener nulo.

Ejemplos

EMPLEADO (codEmp, nss, nombre, telefono, depto, jefe...)

Qu pasara si codEmp pudiera contener NULO?

NULO y Claves Ajenas

El Modelo Relacional permite nulo como valor de clave ajena

depto = null (empleados no asignados a ningn departamento

jefe = null ( empleados sin jefe

Hemos de extender la definicin de clave ajena:

Sea R2 una relacin. FK es una clave ajena en R2 si es un subconjunto de sus atributos tal que:

1. Existe otra relacin R1 con clave primaria PK y

2. En todo momento, cada valor de FK en R2

a) es NULO, o

b) es idntico a un valor de PK en alguna tupla de R1

Restriccin de Integridad Referencial

La Base de Datos no debe contener valores no nulos de clave ajena sin correspondencia

Hay que extender algunas acciones de mantenimiento de la Integridad Referencial:

R2 (R1

Operacin: Eliminar una tupla t de R1 que es referenciada por otras de R2

Acciones posibles:

1. Rechazar la operacin (accin por defecto)

2. Cascada. Propagar la eliminacin

3. Establecer nulos Slo si la FK de R2 permite NULO

- Toda tupla de R2 que referencia a t pasa a contener NULL en FK

- Eliminar la tupla t

Operacin: Modificar el valor de la PK de una tupla t de R1 que es referenciada por otras tuplas de R2.

Acciones posibles:

1. Rechazar la operacin (accin por defecto)

2. Cascada. Propagar la modificacin

3. Establecer nulos

Slo si la FK de R2 permite NULO

Toda tupla de R2 que referencia a t pasa a contener NULL en FK

Modificar el valor de la PK de t

4.7 Proceso de Transformacin

Usando las reglas de transformacin podemos crear un nuevo modelo basado en el modelo conceptual.

Terminologa de Mapeo

ANLISIS

DISEO

Modelo ER

Diseo fsico

Entidad

Tabla

Atributo

Columna

Relacin

Llave fornea

identificador nico primario Llave primaria

identificador nico secundario Llave nica

Cambiando de una palabra a otra (????), tambin cambiando los significados de la terminologa.

Usando bases muy simples:

Una entidad se lleva a una tabla

Un atributo se vuelve una columna

Un identificador nico primario produce una llave primaria

Un identificador nico secundario produce una llave nica

Una relacin es transformada en una llave fornea o columnas de llave fornea

4.7.1 Mapeo Bsico

Mapeo de entidades

Transformar entidades en tablas usando su propia convencin de la denominacin o el nombre previamente escrito.

EMPLEADO

Cod_Emp

Nombre

Departamento

Salario

100

Maricela Perez

Marketing

42.000

140

Felipe Quispe

Conflictos

100.000

110

Eduardo Leao

Acadmico

50.000

190

Evo Morales

Adepcoca

700.000

Usted puede expresar la estructura de una relacin por una notacin mas corta en la cual el nombre de la relacin es seguida por braquetas para el nombre de los atributos en la relacin. El atributo de la clave primaria es subrayada.

Del ejemplo anterior tenemos:

EMPLEADO

o

EMP

La llave primaria de la entidad (o identificador) se transforma en la llave primaria de la relacin correspondiente.

Mapeo de relaciones

El procedimiento para mapear relaciones depende del grado de la relacin y la cardinalidad.

4.7.2 Obtencin de las relaciones a partir del diagrama E/R

A continuacin se estudia la forma de determinar las relaciones preliminares, empezando por las relaciones de cardinalidad 1:1 hasta las m:n, para terminar con las de grado superior.

Relaciones preliminares para la correspondencia binaria de cardinalidad 1:1

Regla 1.

Si la correspondencia es binaria y la cardinalidad es 1:1 y es obligado el tipo de participacin de ambas, slo es necesario una relacin. Como clave primaria de la relacin se puede tomar cualquiera de las claves de la entidad.

Cuando alguna de las relaciones deja de ser obligatoria para ser opcional, aparecen atributos en blanco. Para subsanar anomalas es necesario definir una nueva regla.

Diagrama

Transformacin

PROVEEDOR

Anomalas cuando una de las entidades deja de ser obligatoria y es opcional

Num

Nom

Cod_ar

Desc

11

Perez

A1

Computadoras

22

Hernndez

A2

Impresoras

33

Moreno

A3

Discos

44

Vargas

A4

Disco compacto

Reglas 2

Si la correspondencia es binaria y la cardinalidad es 1:1 y el tipo de participacin de una entidad es obligatoria y el de la otra es opcional, son necesarias dos relaciones. Cada una contendr la informacin concerniente a una entidad y su clave primaria ser la clave de la entidad correspondiente. La clave de la entidad opcional se aadir como un atributo ms en la relacin cuyo tipo de participacin sea obligatoria.

Cuando las dos relaciones son opcionales, vuelven a aparecer atributos en blanco. Para esta anomala es necesario definir una tercera regla.

Diagrama

Transformacin

Anomalas cuando ambas entidades son opcionales

Regla 3

Si la correspondencia es binaria y la cardinalidad es 1:1 y el tipo de participacin en ambas entidades es opcional son necesarias tres relaciones, una para cada entidad y otra para la correspondencia. La clave de las relaciones de las entidades es la clave primaria de la entidad correspondiente. La relacin con la correspondencia deber contener las claves de las entidades.

Con tres relaciones es la nica manera de que no se produzca ningn tipo de anomalas.

Diagrama

Transformacin

Relaciones preliminares para la correspondencia binaria de cardinalidad 1: N

Regla 4

Si la correspondencia es binaria y la cardinalidad es 1:n y la entidad del lado n es obligatoria, se necesitan dos relaciones, una para cada entidad. La clave de las relaciones de las entidades es la clave primaria de la entidad correspondiente. La relacin de la entidad n contiene la clave de la entidad 1.

Diagrama

Transformacin

Anomalas cuando la entidad del lado n es opcional

Regla 5

Si la correspondencia es binaria y la cardinalidad es 1:n y la entidad del lado n es opcional se necesitan tres relaciones, una para cada entidad y otra para la correspondencia. La clave de las relaciones de las entidades es la clave primaria de la entidad correspondiente; la relacin con la correspondencia contendr las claves de las entidades.

Diagrama

Transformacin

Relaciones preliminares para las correspondencias binarias de cardinalidad M:N

Regla 6

Si la correspondencia es binaria y la cardinalidad es m:n se necesitan tres relaciones una para cada entidad y la otra para la correspondencia. La clave de las relaciones de las entidades es la clave primaria de la entidad correspondiente. La relacin con la correspondencia deber contener las claves de las entidades.

Diagrama

Transformacin

Relaciones preliminares para las correspondencias ternarias

Regla 7

Si existe una correspondencia ternaria se necesitan cuatro relaciones, una para cada entidad, y una ms para la correspondencia. La clave de las relaciones de las entidades es la clave primaria de la entidad correspondiente. La relacin que contenga los datos de la correspondencia contendr entre sus atributos las claves de las entidades.

Diagrama

Transformacin

Relaciones para la agregacin

La transformacin de un diagrama ER que incluye agregacin a una forma tabular es directa. Por ejemplo, sea:

Para el diagrama creamos las siguientes tablas:

EMPLEADO

PROYECTO

TRABAJO

MAQUINARIA

USA

Relaciones para la generalizacin

Sea el siguiente ejemplo de generalizacin especializacin.

Existen dos mtodos diferentes para transformar un diagrama ER que incluye generalizacin en una forma tabular:

1. Para cada conjunto de entidades de nivel ms bajo, crear una tabla que incluye una columna para cada uno de los atributos de ese conjunto de entidades ms una columna para cada atributo de la clave primaria del conjunto de entidades del nivel ms alto. As, para el diagrama ER de la figura tenemos tres tablas:

cuenta, con atributos nmero_cuenta y saldo

cuenta_ahorro, con atributos nmero_cuenta y tasa_inters

cuenta_cheques, con atributos nmero_cuenta y saldo_deudor

2. No crear una tabla para el conjunto de entidades de nivel ms alto. En cambio, para cada conjunto de entidades de nivel ms bajo, crear una tabla que incluye una columna para cada uno de los atributos de ese conjunto de entidades ms una columna para cada atributo del conjunto de entidades de nivel ms alto. Entonces, para el diagrama ER de la figura, tenemos dos tablas.

cuenta_ahorros, con atributos nmero_cuenta y tasa_inters

cuenta_cheques con atributos nmero_cuenta y saldo_deudor

4.7.3 Representacin de conjuntos de entidades dbiles

Sea A un conjunto de entidades dbiles con atributos

r

a

a

a

,...,

,

2

1

. Sea B el conjunto de entidades fuertes del que depende A. La clave primaria de B consta de los atributos

s

b

b

b

,...,

,

2

1

. Representamos el conjunto de entidades A mediante una tabla llamada A con una columna para cada atributo del conjunto:

{

}

{

}

s

r

b

b

b

a

a

a

,...,

,

,...,

,

2

1

2

1

Por ejemplo:

Transformando a tablas:

CUENTA

TRANSACCIN

Ejercicios Propuestos

1. Dado el siguiente modelo conceptual

Considere los atributos y las participaciones que usted vea conveniente.

2. Dado el siguiente modelo conceptual, bajar a tablas

REFERENCIAS BIBLIOGRFICAS

(1) Almeida, BASE DE DATOS, Mxico, De. McGraw-Hill, 1992, p.: 221

(2) Hoffer, George, Valacich,E.E.U.U. ,MODERN SYSTEMS ANLISYS & DESIGN, De. Adison, 1999, p.: 319

(3) Gary, Hansen James, Hansen, Madrid, DISEO Y ADMINISTRACIN DE BASE DE DATOS, De. Pretince Hall, 1997, p. : 84

5.1 Definicin de Normalizacin

Se entiende por normalizacin la descomposicin o subdivisin de una relacin en dos o ms relaciones para evitar la redundancia; en definitiva, que cada hecho est en su lugar.

El proceso de normalizacin generalmente se utiliza en el enfoque relacional; sin embargo, un modelo relacional se puede modificar para su implementacin en un DBMS, jerrquico o de red.

Normalizacin es un concepto de base de datos relacional. Sin embargo, si usted crea un modelo de entidad relacin correcto, entonces las tablas creadas durante el diseo conformarn las reglas de normalizacin. Cada regla de las formas normales del diseo de la base de datos relacional tiene una interpretacin en el modelo de datos correspondiente.

Reglas de Normalizacin

Reglas de la Forma Normal

Descripcin

Primera Forma Normal (1FN)

Todo atributo es un valor simple

Segunda Forma Normal (2FN)

Un atributo debe ser dependiente de un nico identificador entero de entidad

Tercera Forma Normal (3FN)

Ningn atributo no clave debe ser dependiente de otro atributo no clave

Un modelo de datos entidad relacin normalizado, automticamente traslada en un diseo de base de datos relacional normalizado

La tercera forma normal es la meta generalmente aceptada para un diseo de base de datos que elimin la redundancia

La relacional universal

Supongamos que se desea implementar en una base de datos el TIPO DE INFORMACIN que proviene de alguna AGENCIA (fuente de informacin) en un medio de comunicacin escrita.

Los datos correspondientes se muestran en la siguiente relacin (tabla).

INFORMACIN

Id_Inf

Tipo_Inf

Fecha

Hora

Medio_Inf

Id_Agencia

Nombre

I5002

Social

12/08/01

8:30

Internet

A007

JATA

I6254

Deportivo

14/09/00

9:45

Fax

A009

AFP

I7890

Cultural

22/10/03

7:15

Telfono

A010

CNN

...

...

...

...

...

...

...

5.2 Relaciones bien Estructuradas

Es una relacin que contiene una cantidad mnima de redundancia y permite a los usuarios insertar, modificar y borrar las filas en una tabla sin errores o inconsistencia.

EMPLEADO del ejemplo anterior es una relacin. Cada fila de la tabla contiene datos que describen a un empleado y cualquier modificacin a los datos (tales como el cambio en el salario) de un empleado se realiza en una fila de la tabla.

Redundancia, Anomalas

La redundancia en una tabla puede producir errores o inconsistencias (llamado anomalas) cuando el usuario actualiza algn dato en la tabla. Tres tipos de anomalas son posibles:

1. Anomala de insercin. Suponga que usted necesita adicionar un nuevo empleado a EMPLEADO1. La llave primaria para esta relacin es la combinacin de Cod_emp y Curso usted debe introducir los valores para Cod_Emp y Curso (los valores de la clave primaria no pueden ser nulos). sta es una anomala, el usuario puede introducir los datos del empleado sin los datos del curso correspondientes.

2. Anomalas de eliminacin. Supongamos que los datos del empleado 140 es eliminado en la tabla. Esto producir perdida de informacin, por que este empleado complet un curso.

3. Anomalas de Modificaciones. Supongamos que empleado numero 100 consigue un aumento salarial. Usted debe registrar el aumento en cada una de las filas para el empleado (dos ocurrencias), sin embargo el dato podra ser inconsistente.

5.3 Dependencia Funcional (DF)

La normalizacin se basa en la dependencia funcional.

El concepto de dependencia funcional se tom de las matemticas.

[

]

)

(

X

f

Y

=

, Y es funcin de X si el valor de Y est siempre determinado por el valor de X.

La dependencia funcional se define:

Se simboliza por:

Y

X

La DF se determina al estudiar las propiedades de todos los atributos de la relacin y deducir cmo estn relacionados los atributos entre s.

La dependencia funcional est ntimamente ligada con el concepto de clave. Para el diseo, las claves aparecen subrayadas.

5.4 Primera Forma Normal (1FN)

Todo atributo debe ser valor simple (indivisible, atmico). Valor atmico es un valor que no es un conjunto de valores o grupo repetitivo.

Verificar que cada atributo tenga un valor simple para cada ocurrencia de la entidad. El atributo no debe tener valores repetidos.

5.5 Dependencia Funcional Completa

Se dice que el atributo Y de la relacin R es completo dependiente funcionalmente del atributo X de la relacin R, si depende funcionalmente de X y no depende funcionalmente de ningn subconjunto propio de X. ( Es decir, no existe un subconjunto propio Z de los atributos componentes de X tales que Y sea funcionalmente dependiente de Z).

Ahora sea el siguiente ejemplo:

5.6 Segunda Forma Normal (2FN)

Una relacin R est en segunda forma normal s y solo s:

Esta en primera forma normal

Todo atributo que no pertenece a la clave debe depender de la clave en su totalidad y no slo de una parte, es decir, debe tener dependencia funcional completa.

Ejemplo

Sea un ambiente de aplicacin de una Importadora de productos cuyos datos de factura se registran en:

NumFac

Fecha

Cliente

Descripcin

Cantidad

Precio

Total

Origen

26009

26/07/94

Sambrana

Palanca

1

49

81

Japons

26009

26/07/94

Sambrana

Cable

3

30

81

Chino

26009

26/07/94

Sambrana

Fusible

2

2

81

Chino

62003

26/07/94

Vargas

Fusible

4

8

8

Chino

75001

29/08/94

Cevallos

Palanca

3

20

20

Japons

75002

29/08/94

Cevallos

Cable

6

50

50

Chino

Ahora encontremos la clave primaria:

Consideremos los atributos NumFac y Descripcin, para este conjunto de atributos los dems dependen funcionalmente.

Como se puede observar en el grfico Fecha, Total y Cliente dependen del total de la clave pero tambin dependen de un subconjunto de la clave primaria, es decir, dependen de NumFac. Por tanto:

La tabla est en 1FN

Pero no tiene dependencia funcional completa

Por lo que se presenta las siguientes anomalas:

La Fecha, Cliente y Total se repiten para cada Descripcin del producto

Si el nombre del Cliente cambia, cada fila que se refiere a su nmero de facturacin cambia.

Debido a esta redundancia, los datos podran convertirse en inconsistentes, con distintas filas, mostrando diferentes nombres para el mismo cliente.

Entonces dividimos la tabla de acuerdo al grfico, como muestra las lneas punteadas

De aqu tenemos dos tablas:

Factura < NumFac, Fecha, Total, Cliente >

Linea_Factura < NumFac, Descripcin, Cantidad, Precio, Origen >

5.7 Dependencia Transitiva

Supongamos los tributos X, Y y Z.

Si X ( Y, y Y ( Z, entonces decimos que Z depende transitivamente de X y se puede formar la cadena X ( Y(Z.

En diagrama de dependencia funcional es:

Se puede descomponer en dos relaciones por la proyeccin del ltimo eslabn de la forma:

R1

R1

5.8 Tercera Forma Normal (3FN)

Una relacin est en tercera forma normal s, y solo s:

Est en 2FN

Todo atributo que no pertenece a la clave no depende de un atributo no clave.

(Dependencia Transitiva)

Sea el ambiente de aplicacin de proyectos que realiza cierto Ministerio de Gobierno, que son desarrollados por una Institucin.

Cod_P

Proyecto

Institucin

Direccin

PC-01

Riego

CIPE

Z. San Pedro #324

PC-02

Electrificacin

CIPE

Z. San Pedro #324

PC-03

Posta Sanitaria

CIPE

Z. San Pedro #324

PC-04

Alfabetizacin

UNICEF

Z. San Jorge #121

PC-05

Forestacin

PAC

Z. Miraflores #34

PC-06

Agua Potable

PAC

Z. Miraflores #34

La clave primaria de esta relacin ser Cod_P ya que cada uno de los dems atributos depende de esta.

Como se puede advertir en el diagrama el atributo Direccin depende del atributo Institucin y est depende de la clave primaria, entonces existe transitividad. Por tanto existen los siguientes problemas:

Para cada institucin se repite su domicilio.

Si la direccin de una institucin cambia todas las tuplas que contengan esa institucin cambia. Si se borra un proyecto, se pierde los datos correspondientes a la institucin. Por tanto existen anomalas de actualizacin y borrado.

Si se desea registrar a una nueva institucin, necesariamente tiene que estar asignado a un proyecto.

Por tanto dividimos la relacin en otras dos de acuerdo al grfico:

Proyecto

Institucin

5.9 Definicin de Determinante

Un determinante son todos los atributos situados en el lado izquierdo de una dependencia funcional.

5.10 Forma Normal de Boyce Codd (BCFN)

Una relacin R est en forma normal de Boyce Codd si, y solo s, cada determinante de la relacin es una clave candidata, es decir, un atributo clave en una clave compuesta es dependiente de un atributo no clave.

Una relacin que no est en BCFN debe descomponerse en otras dos.

Grficamente:

Relacin que no est en BCFN

Ejemplo

Se suponen las siguientes restricciones:

Un estudiante puede tener una o ms materias

Una materia puede tener varios miembros de la facultad como consejeros

Un miembro de la facultad solo imparte asesora a una materia

Estos datos se registran en la siguiente tabla:

ASIGNACIN

Cod_A

Materia

NombreF

100

Matemticas

Borda

150

Sicologa

Camacho

200

Matemticas

Cruz

250

Matemticas

Borda

300

Sicologa

Andrade

300

Matemtica

Cruz

Esta relacin se encuentra en 1FN, 2FN y 3FN pero no en la BCFN.

La clave primaria de esta relacin es Cod_A, Materia y el atributo Nombre_F depende de esta.

Claramente se ve que NombreF determina a Materia lo que significa que la relacin no est en BCFN, por esto dividimos la relacin en dos:

EST_ASIG

ASIG_MAT

5.11 Dependencia de Valores Multivaluados (DMV)

Se dice que existe dependencia de valores multivaluados si, un valor del atributo, A, determina un conjunto de valores mltiples, B.

A diferencia de las DF, las DMV no son propiedades de la informacin que se representan con relaciones. Ms bien, depende de la forma en que se estructuran los atributos en las relaciones.

Una DMV se define as: en la relacin R(X, Y, Z), X (( Y si cada valor de X se junta con un grupo de valores en Y, en una forma que no dependa de los valores de Z.

En una definicin normal de DMV, los valores de atributo Y slo dependen de los atributos en X pero son independientes de los atributos de Z. As, cuando se da un valor de X, el valor de Y es el mismo para cualquiera de los dos valores de, Z1 o Z2 de Z.

Cmo eliminamos la redundancia en las dependencias de valores mltiples?

La redundancia de los datos causados por la dependencia mltiple se puede eliminar mediante la creacin de una nueva relacin por cada atributo DMV.

En el ejemplo anterior se tiene:

Investigador

Aficin

5.12 Cuarta Forma Normal (4FN)

La 4FN es una generalizacin de la BCFN para descomponer las relaciones que poseen dependencias multivaluadas.

Una relacin R est en 4FN s, y solo s:

Es BCFN

No contiene dependencias multivaluadas

La relacin R con atributos A, B y C con las dependencias multivaluadas:

A((B

A((C

Se puede descomponer sin prdida en dos relaciones en 4FN:

R1

R2

Ejercicios Propuestos

1. Para cada una de las siguientes relaciones encontrar la clave primaria:

a) VENTAS

Cada vendedor tiene una lista de precios para cada categora y a cada vendedor se le asigna una direccin de ventas.

b) REPORTES

Cada autor est en un departamento y cada reporte lo produce un autor en una fecha de reporte.

c) VISTAS < FECHA, NUM_REG, VENDEDOR, CLIENTE >

A cada cliente lo visita un vendedor y se registra la fecha de cada entrevista. Se usa un vehculo para cada visita y slo un vendedor puede usar un vehculo dado en una fecha determinada.

2. Dada la siguiente relacin

PROYECTO_USO

PROYECTO_NUM

ITEM_NUM

CANTIDAD_USADA

FECHA_INICIO

FECHA_FINAL

COSTO

ROY1

X7

9

ENE90

MAR91

10.11

PROY1

X9

11

ENE90

MAR91

22.30

PROY1

X10

20

ENE90

MAR91

5.50

PROY2

X9

17

JUN90

JUL91

22.30