UNIVERSIDAD SALESIANA DE BOLIVIA

CARRERA INGENIERÍA DE SISTEMAS

Î

DOSSIER

BASE DE DATOS I

Cuarto Semestre

Lic. Katya Maricela Pérez Martínez

2012

ÍNDICE

Î

PRESENTACIÓN.................................................................................................................i

TEMA 1 FUNDAMENTOS DE BASE DE DATOS

1.1 Introducción1

1.2 Características del enfoque de base de datos2

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

1.2.2 Separación entre los programas y los datos, y abstracción de datos4

1.2.3 Soporte de múltiples 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 Clasificación de los sistemas de gestión 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 móviles26

1.10.4 Sistemas de Información Geográfico26

1.10.5 Gestión de datos del genoma28

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

REFERENCIAS BIBLIOGRÁFICAS..................................................................................29

TEMA 2 MODELO DE DATOS

2.1 Introducción30

2.2 La importancia de los modelos de datos30

2.3 Clasificación de los modelos31

2.3.1   Modelos lógicos basados en objetos31

2.3.2   Modelos lógicos basados en registros33

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

REFERENCIAS BIBLIOGRÁFICAS..................................................................................41

TEMA 3 MODELO ENTIDAD RELACION

3.1 Modelo Conceptual42

3.2 Definición del Modelo E/R42

3.3 Objetivos del Modelo42

3.4 Terminología utilizada en el Modelo43

3.4.1 Entidad43

3.4.2 Entidad Débil44

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 relación47

3.6 Cardinalidad de relaciones y participaciones49

3.6.1 Cardinalidad Mínima y Máxima50

3.6.2 Tipos de relaciones51

3.7 Generalización53

3.8 Agregación Y Entidades Asociativas54

Ejercicios propuestos56

REFERENCIAS BIBLIOGRÁFICAS..................................................................................57

TEMA 4 MODELO RELACIONAL

4.1 ¿Por qué crear un diseño de base de datos?58

4.2 Presentación y Orígenes del Modelo Relacional59

4.3 Estructura de datos relacional59

4.4 Términos Básicos en el Modelo Relacional60

4.5 Definiciones Formales61

4.5.1 Dominio61

4.5.2 Relación61

4.5.2.1 Propiedades de una relación62

4.5.2.2 Relación vs. Tabla62

4.5.3 Base de Datos Relacional63

4.6 Características Generales de Integridad64

4.6.1 Reglas de Integridad64

4.6.1.1 Superclave y clave de una relación65

4.6.1.2 Clave candidata, primaria y alternativa65

4.6.1.3 clave ajena (externa o foránea)66

4.6.1.4 Mantenimiento de la Integridad Referencial68

4.6.1.5 Valores Nulos70

4.7 Proceso de Transformación72

4.7.1 Mapeo Básico73

4.7.2 Obtención de las relaciones a partir del diagrama E/R74

4.7.3 Representación de conjuntos de entidades débiles79

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

REFERENCIAS BIBLIOGRÁFICAS..................................................................................81

TEMA 5 NORMALIZACIÓN

5.1 Definición de Normalización82

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 Definición 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 BIBLIOGRÁFICAS................................................................................ 97

TEMA 6 OPERACIONES DEL MODELO RELACIONAL

6.1 Introducción98

6.2 Álgebra Relacional98

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

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

6.3 Cálculo Relacional103

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

REFERENCIAS BIBLIOGRÁFICAS............................................................................. 105

TEMA 7 INTRODUCCIÓN AL LENGUAJE DE CONSULTA (SQL)

7.1 Definición de dn lenguaje de consulta106

7.2 Definición de datos107

7.3 Manipulación de datos109

7.4 Operaciones sobre una relación110

7.5 Operaciones sobre más de una relación112

7.6 Ejercicios sobre operaciones114

7.7 Expresiones con bloques anidados115

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

REFERENCIAS BIBLIOGRÁFICAS............................................................................. 119

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

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

BIBLIOGRAFÍA ..............................................................................................................127

PRESENTACIÓN

Î

Las Bases de Datos han evolucionado a partir de los años 60 como una necesidad de mejorar el procesamiento de los datos y en respuesta a las limitaciones del procesamiento orientado a proceso. Hoy en día las Bases de Datos se ha convertido en la parte esencial de la currícula de la informática.

Este dossier está orientado a los estudiantes de la carrera de Ingeniería de Sistemas tanto para el nivel técnico como superior. Es un material básico 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, organización de archivos y un lenguaje de programación. Su contenido es didáctico con muchos ejemplos y algunos ejercicios que se deben desarrollar en clases por parte de los estudiantes con la guía 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 raíz de este concepto se explica que un dato para luego estudiar las propiedades implícitas 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 desempeña una función prioritaria en el proceso de abstracción que conduce a la base de datos.

· Modelo Entidad Relación.- Este modelo proporciona una visión de alto nivel de los resultados de un diseño de base de datos, Se basa en los conceptos de entidad, atributo y relación.

· Modelo Relacional.- Es un modelo basado en registros y en teoría matemática, cuenta con tablas como estructura principal. Puede obtener ser este modelo a partir de la transformación del modelo Entidad Relación.

· Normalización.- Es el proceso por el cual se depuran las tablas para evitar tener redundancia de datos y anomalías.

· 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 proyección y selección, por otra parte el cálculo relacional es un lenguaje formal basado en la lógica de predicados, o cálculo de predicados de primer orden.

· Introducción al lenguaje de consulta SQL.- Permite interaccionar con la base de datos para obtener datos y definir datos a través de órdenes. El lenguaje SQL tiene varios componentes como ser el lenguaje de definición de datos, lenguaje interactivo de manipulación de datos, definición de vistas, control de transacciones, integridad transacción.

Î

Î

Î

2.1.Arquitectura de un SGBD e independencia de datos

Hay tres características importantes inherentes al enfoque de las bases de datos: 1) la separación entre los programas y los datos (independencia entre programas y datos) ; 2) el soporte de múltiples vistas de usuario, y 3) el empleo de un catálogo para almacenar la descripción (esquema) de la base de datos. La arquitectura de tres esquemas ayuda alcanzar y visualizar estas características.

2.2.Arquitectura de tres esquemas

El Comité de planificación y requerimientos del Instituto Nacional de Estados Unidos de Estándares en Computación y Procesamiento de Información que en su división X3 establece que la arquitectura de una BD debe poseer tres niveles:

· Nivel interno

· Nivel conceptual

· Nivel Externo

Nivel Interno

Este es nivel más bajo de abstracción de información.

El nivel interno es la representación inferior de una BD, por ello es el más cercano al almacenamiento físico. Permite describir los datos tal como están almacenados en la computadora; Por ejemplo:

· Los archivos que los contienen ( nombre, organización, ubicación,….)

· 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 transformación de un registro a partir de su estructura lógica hasta su almacenamiento físico. La operación de transformar registros lógicos en físicos y viceversa se llama Transformación de Datos o mapeo.

Figura 1.7 Arquitectura de tres esquemas

Nivel Conceptual

Es el siguiente nivel más alto de abstracción. El DBA define el nivel conceptual por medio de un esquema o vista conceptual, al decir que información 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 organización física ni las vías 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, Artículos, Vehículos, etc.

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

· Algunas veces las reglas que deberían seguir los datos en la empresa. Ejemplo: Que el stock mínimo esté comprendido entre unos márgenes, que cada artículo posea su proveedor, etc.

· Relaciones entre los datos para conectar o relacionar registros en el procesamiento de archivos múltiples.

En este nivel la base de datos aparece como una colección de registros lógicos sin especificar su almacenamiento. En realidad, los archivos conceptuales no existen físicamente.

Nivel Externo

Es el nivel más alto de abstracción y por ello el más cercano a los usuarios. El nivel externo representa la percepción individual de cada usuario o programador de la BD, describe únicamente la parte de los datos de interés 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 físicamente.

El DBMS es el encargado de extraer los datos requeridos por los registros lógicos externos de uno o más registros físicos, de la BD, cada vez que se ejecuta una operación de E/S en un programa específico.

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 podrán acceder a más 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 más tipos de registros pueden omitirse en el esquema.

· Uno o más campos pueden omitirse en el registro conceptual.

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

· Una o más 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 lógica de los datos, es la capacidad de modificar el esquema conceptual sin tener que alterar lo esquemas externos ni los programas de aplicación. Podemos modificar el esquema conceptual para ampliar la base de datos (añadiendo 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 modificación no deberá afectar a los esquemas externos que sólo se refieran a los datos restantes. Si en el SGBD se cuenta con independencia lógica de datos, sólo será preciso modificar la definición de la vista y las correspondencias. Después de una reorganización lógica del esquema conceptual los programas de aplicación que hagan referencia a los elementos del esquema externo deberán funcionar igual que antes. Además, las restricciones podrán modificarse en el esquema conceptual sin afectar a los esquemas externos ni a los programas de aplicación.

2. Independencia física 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 físicos (por ejemplo, al crear estructuras de acceso adicionales) con el fin de mejorar el rendimiento de las operaciones de recuperación y actualización. Si la base de datos aún contiene los mismos datos, no será necesario modificar el esquema conceptual.

En todo SGBD de múltiples niveles es preciso ampliar el catálogo de modo que incluya información sobre cómo 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 información de correspondencia que se encuentra en el catálogo.

La arquitectura de tres esquemas puede facilitar la consecución de la verdadera independencia de datos, tanto física como lógica. Sin embargo, los dos niveles de correspondencias implican un gasto extra durante la compilación y la ejecución 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 Introducción

Una característica fundamental del enfoque de base de datos es que proporciona cierto nivel de abstracción de los datos, al ocultar detalles de almacenamiento que la mayoría de los usuarios no necesitan conocer. Un modelo de datos proporciona los medios necesarios para conseguir dicha abstracción.

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

Modelo

Es una representación de la realidad que contiene las características generales de algo que se va a realizar. En base de datos, esta representación la elaboramos de forma gráfica.

Modelo de datos

Es una colección de herramientas conceptuales para describir los datos, las relaciones que existen entre ellos, semántica asociada a los datos y restricciones de consistencia, además de ser un dispositivo de abstracción que nos permite ver el bosque (esto es, la información contenida en los datos) en oposición de los árboles (valores individuales de los datos).

Abstracción

Es la acción y el efecto de abstraer, separar por medio de una operación intelectual las cualidades de un objeto para considerarlas asiladamente o para considerar el mismo objeto en su pura esencia o noción. Por tanto, la abstracción, 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 comprensión 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 través de los "Sistemas de Archivos"; donde cada uno de los archivos que se creaban solo obedecía a una necesidad de almacenamiento más que a la utilización funcional del dato. Por este motivo surgen los esquemas conceptuales que son elaborados a través del análisis de procesos de las áreas del negocio, los conceptuales involucran al "dato" como una consecuencia lógica 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 símbolos que permiten estandarizar traducir dicho análisis a un lenguaje semántico y sistemático que dispone de reglas de control y evaluación del comportamiento del dato en el transcurso del tiempo, tanto en su almacenamiento como en su utilización.

Estos modelos de datos, hacen posible que la lógica de un negocio pueda ser estructurada de forma tangible a través de un esquema físico 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 través del tiempo.

2.3 Clasificación de los modelos

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

Modelos lógicos basados en objetos.

  Modelos lógicos basados en registros.

  Modelos físicos de datos.

2.3.1   Modelos lógicos basados en objetos

Se usan para describir datos en los niveles conceptual y de visión, es decir, con este modelo representamos los datos de tal forma como nosotros los captamos en el mundo real, tienen una capacidad de estructuración bastante flexible y permiten especificar restricciones de datos explícitamente. Existen diferentes modelos de este tipo, pero el más utilizado por su sencillez y eficiencia es el modelo Entidad-Relación.

· Modelo Entidad-Relación

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

Tangibles

Son todos aquellos objetos físicos 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 características de las entidades en base de datos se llaman atributos, por ejemplo el nombre, dirección teléfono, grado, grupo, etc. son atributos de la entidad alumno; Clave, número de seguro social, departamento, etc., son atributos de la entidad empleado. A su vez una entidad se puede asociar o relacionar con más entidades a través 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 artículo (que es el producto en venta), y las características que los identifican son:

                  Empleado:       Artículo:

                  Nombre            Descripción                  Puesto              Costo                  Salario              Clave                  R.F.C.

La relación entre ambas entidades la podemos establecer como Venta.

Bueno, ahora nos falta describir como se representa un modelo E-R gráficamente, la representación es muy sencilla, se emplean símbolos, los cuales son:

    Símbolo                                               Representa

Así nuestro ejemplo anterior quedaría representado de la siguiente forma:

Existen más aspectos a considerar con respecto a los modelos entidad relación, estos serán considerados en el tema Modelo Entidad Relación.

2.3.2   Modelos lógicos basados en registros

Se utilizan para describir datos en los niveles  conceptual y físico. 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 lógica global de la base de datos y para proporcionar una descripción a nivel más alto de la implementación.

Los tres modelos de datos más ampliamente aceptados son:

         Modelo Relacional           Modelo de Red           Modelo Jerárquico

· Modelo relacional

En este modelo se representan los datos y las relaciones entre estos, a través de una colección 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 características(atributos) de cada registro localizado en la tupla;

Considerando nuestro ejemplo del empleado y el artículo:

 Tabla del empleado

Ahora te preguntaras ¿cómo 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 relación.

   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 básicas 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 información. Damos un nombre a cada tipo de registro, y también damos un nombre y un formato (tipo de datos) a cada elemento de dato (o atributo) del tipo de registro.

Ejemplo

ALUMNO

NOMBRE

RU

DIRECCIÓN

DPTO_ESPC

FECHA_NAC

Elemento dato

Nombre y Formato

NOMBRE

Carácter 15

RU

Numérico

DIRECCIÓN

Carácter 20

DPTO_ESPC

Carácter 15

FECHA_NAC

Fecha

Tipo de conjunto y sus propiedades básicas

Un tipo de conjunto es una descripción 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 vínculos de M:N

Un tipo de conjunto representa un vínculo 1:N entre dos tipos de registros. Esto significa que un registro del tipo de registro miembro sólo puede aparecer en una ocurrencia del conjunto. El SGBD garantiza automáticamente esta restricción en le modelo red. Si queremos representar un vínculo 1:1, el programa de aplicación debe imponer la restricción 1:1 adicional.

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

Así por ejemplo:

Consideremos el vínculo 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 representación incorrecta es:

EMPLEADO

NUMERO_EMP

...

EMPLEADO

NUMERO_EMP

PROYECTO

NUMEROP

...

PROYECTO

NUMEROP

...

Representaciones incorrectas

El método para representar un vínculo 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 Jerárquico

Relaciones Padre-Hijo y esquema jerárquicos

Un modelo jerárquico utiliza dos conceptos principales de estructuración de datos: registros y relaciones padres – hijos.

Registro es la colección de valores de campo que proporcionan información sobre una entidad o una instancia de una relación. Los registros del mismo tipo se agrupan en tipos de registros cada tipo de registro recibe un nombre y su estructura se define en términos de una colección 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 relación padre –hijo (tipo RPH) es una colección 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 jerárquico se visualiza como un diagrama jerárquico, en el cual los nombres de los tipos de registros aparecen en cuadros rectangulares y los tipos de RPH se dibujan como líneas 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 jerárquicos

1. Un tipo de registro, denominado raíz del esquema jerárquico, no participa como tipo de registro hijo en ningún tipo de RPH.

2. Todo tipo de registro, con excepción de la raíz, 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 más) tipos de RPH.

4. Un tipo de registro que no participa como tipo de registro padre en ningún tipo de RPH se denomina hoja del esquema jerárquico.

5. Un tipo de registro participa como padre en más de un tipo de RPH, entonces sus tipos de registro hijo están ordenados. El orden se visualiza por convención, de izquierda a derecha en los diagramas jerárquicos.

La definición de esquema jerárquico define una estructura de datos de árbol. En la terminación 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 más relaciones padre-hijo distintas.

Árbol de ocurrencia jerárquico

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

Ejemplo

Esquema Jerárquico

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 Administración de DEPARTAMENTO con los respectivos empleados y proyectos con los respectivos trabajadores es:

Administración

Cuellar Ramirez Sosa Automatización Nuevos Beneficios

López Galarza Angulo Pérez Aguilar

Forma lineal izada de un árbol de ocurrencias jerárquicas

Un árbol de ocurrencias jerárquicas puede representarse en almacenamiento empleando una estructura de datos de entre la variedad de estructuras existentes. Sin embargo una de las estructuras de almacenamiento más simples que podemos usar es el registro jerárquico, 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 jerárquico 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 más de un tipo de RPH.

3. Relaciones n-arias con más de dos tipos de registros participantes.

En una representación 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 jerárquico de esta relación muchos a muchos en cualquiera de las dos formas, como sigue:

a)

(b)

· Modelos físicos de datos

Se usan para describir a los datos en el nivel más bajo, aunque existen muy pocos modelos de este tipo,   básicamente capturan aspectos de la implementación de los sistemas de base de datos. Existen dos clasificaciones de este tipo que son:

        Modelo unificador       Memoria de elementos.

Preguntas de repaso

1. ¿Cuál es la característica fundamental del enfoque de las bases de datos?

2. ¿Qué se entiende por modelar?

3. Contraste los términos modelo, modelo de datos y abstracción.

4. ¿Cuál la importancia de los modelos de datos?

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

Ejercicios

1. Para la base de datos de un banco, organice los archivos siguientes en modelo jerarquía: PAGO, CUENTA DE AHORROS, DEPÓSITO, CLIENTE, CUENTA DE PRÉSTAMO, RETIRO DE DEPÓSITOS

2. Para la base de datos para una BIBLIOTECA organice los archivos en un modelo jerárquico: LIBRO, SOCIO, PRÉSTAMO, DEVOLUCIÓN

REFERENCIAS BIBLIOGRÁFICAS

(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 semánticamente a través de representaciones gráficas. Podemos describir muchos de las reglas de negocio con elementos gráficos tales como subtipos (generalización – especialización) y relaciones.

3.2 Definición del Modelo E/R

El modelo Entidad Relación es un modelo conceptual acerca de un negocio. Para ser más 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 Relación es una técnica usada para describir la información necesaria de un negocio. Esta es una técnica bien establecida a través de diagramas que permiten la facilidad de lectura y también fácil verificación.

3.3 Objetivos del Modelo

Los objetivos del modelo son para asegurar que:

· Todas las piezas de información 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 información requerida se muestra una sola vez en el modelo. Este es un objetivo importante. Tan pronto se almacena una información particular, dos veces en un sistema, usted ve la posibilidad de que la información no este al mismo tiempo en dos lugares. Si usted fuera un usuario de un sistema de información y descubre inconsistencia en el dato, ¿cuál información podría ser de confianza? Este objetivo implica que un sistema ideal no contenga información derivable.

· Un modelo entidad relación correcto, conduce a un conjunto de tablas lógicamente coherentes.

3.4 Terminología utilizada en el Modelo

3.4.1 Entidad

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

Algunos ejemplos de entidades son:

· Personas: MÉDICOS, EMPLEADO, ESTUDIANTES, PACIENTES

· Lugares: ESTADO, REGIÓN, SUCURSAL, SECCIÓN, MUNICIPIO

· Objeto: MAQUINA, EDIFICIO, AUTOMÓVIL, PRODUCTO

· Eventos: VENTAS, REGISTRO, COMPRA, ELECCIÓN, 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

Máximo dirigente

RESERVACIÓN DE PASAJE

Noche: La Paz – Santa Cruz

PLANILLA

350.3 Bs.

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

3.4.2 Entidad Débil

El modelo E-R define un tipo especial de entidad débil. 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 característica de una entidad que es de interés para la organización.

Cada entidad tiene un conjunto de atributos asociados con éste.

ENTIDADES

ATRIBUTO

EMPLEADO

Nombre, Edad, Dirección

AUTO

Modelo, Precio, Placa

PEDIDO

Fecha de Pedido, Total

CARGO

Titulo, Descripción

TRANSACCIÓN

Cantidad, Fecha de Transacción

CONTRATO DE EMPLEADO

Fecha de Inicio, Salario

3.4.5 Claves candidatas e identificadores

Llaves candidatas

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

MUNICIPIO: ID_Municipio, Nombre, Departamento, Características

Su llave candidata será:

ID_Municipio

Algunas veces más 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 más de una llave candidata.

Una llave candidata para:

MUNICIPIO: ID_Municipio, Nombre, Departamento, Características

es:

ID_Municipio

Nombre

Si hay más de una llave candidata, como en este caso, entonces el diseñador puede elegir una de las llaves candidatas como identificador.

Identificador

Un identificador es una llave candidata que es seleccionada para ser usada como característica única de una entidad.

( Consideraciones para seleccionar un identificador

a) Elegir una llave candidata que no cambiaría 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 válidos y que no sean nulos.

c) Evitar el uso de las tan llamadas llaves inteligentes, cuya estructura indica clasificación, localización, etc. Por ejemplo, los dos primeros dígitos de la llave de una entidad PARTE puede indicar la localización del almacén.

d) Si tiene llaves compuestas, es decir formado por dos o más atributos, puede sustituir por un atributo simple. Por ejemplo, un atributo llamado ID_Juego en ves de la combinación 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 relación es una asociación entre las instancias de una o más entidades que es de interés para la organización. Una asociación usualmente significa un evento ocurre o que existe algún enlace natural entre las instancias de entidad. Por esta razón, las relaciones son etiquetadas con verbos. Por ejemplo,

TÉCNICO revisa PROYECTO

PERSONA consulta DOCTOR

Notación Entidad Relación

3.5 Grados de una relación

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

(Relaciones Unarias

Notación

Llamadas también relaciones recursivas, una relación unaria es una relación entre las instancias de una entidad.

Por ejemplo

(Relaciones Binarias

Notación

Una relación binaria es una relación entre instancias de dos entidades y es el más común de las relaciones en el modelo de datos.

Por ejemplo

· Relación ternaria

Notación

Una relación ternaria es una relación simultánea entre las instancias de tres entidades.

Por ejemplo

Note que una relación ternaria no es lo mismo que una relación binaria. Por ejemplo, Cantidad es un atributo de la relación Envío. Cantidad pude ser atributo propio de la asociación 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 están conectadas por una relación. La cardinalidad de una relación es el número 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 Mínima y Máxima

Cardinalidad Mínima

La cardinalidad mínima de una relación es el número mínimo de instancias de una entidad B que puede estar asociada con cada instancia de la entidad A.

En el ejemplo, el número mínimo de CELULAR que pertenece a un ESTUDIANTE es CERO, es el caso en que decimos que un CELULAR es una PARTICIPACIÓN OPCIONAL en la relación TIENE. Luego, el número mínimo de ESTUDIANTE que tiene cero o mas celulares es UNO, es el caso en que decimos que un ESTUDIANTE es una PARTICIPACIÓN OBLIGATORIA en la relación tiene.

,O

Cardinalidad Máxima

La cardinalidad máxima es el número máximo de instancias. Es decir el máximo es “muchos”, no se especifica cuantos.

· Entonces en el ejemplo anterior, la cardinalidad máxima 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

RELACIÓN

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 máxima y mínima, y participación.

Casos de participación de las entidades

Opcional – opcional: Cada empleado puede tener exactamente un único trabajo. Un trabajo puede estar ocupado por uno o más 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 más empleados

Obligatorio – obligatorio: Cada empleado debe tener exactamente un trabajo. Un trabajo debe estar ocupado por uno o más 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 Generalización

La generalización se usa para hacer resaltar los parecidos entre tipos de entidades de nivel más bajo y ocultar sus diferencias. La distinción se hace a través de un proceso llamado herencia de atributos. Los atributos de los conjuntos de entidades de nivel más alto se dice que son heredados por los conjuntos de nivel mas bajo.

Notación grafica

Ejemplo

3.8 Agregación Y Entidades Asociativas

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

Claramente se nota que la relación vende tiene sus propios atributos.

Sea una relación ternaria, como se muestra a continuación:

La relación ternaria tiene características 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 relación VENDEDORES a ALMACEN es muchos a uno y la relación 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 diseñadores pueden crear de manera inadvertida, relaciones con atributos que dependan de un subconjunto de las entidades en la relación. Esta situación puede ser la causa de representaciones no – FNBC. Por ejemplo, en la figura, la inclusión del atributo Cantidad (ENVIO – TOTAL – PARTES – POR – VENDEDOR) en ENVIO, hace que la relación correspondiente sea no FBNC. La clave de la relación 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 más se permitan relaciones binarias en el modelo de la empresa. De esta manera cada conjunto de relación binaria se transforma en una relación cuyas claves son los identificadores de las entidades que interactúan. Para lograrlo, las relaciones con más de una entidad se deben reducir a relaciones binarias, lo cual conduce al concepto de agregación. 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 ALMACÉN.

   

Ejercicios propuestos

1. Libro

Meta

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

Ambiente de Aplicación

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

2. Nosotros tenemos publicado este libro. La edición 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 traducción de este libro en español. Uso el inglés 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 impresión 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 María.

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 compañía de publicación. Pruebe para distinguir varias, todas referidas al libro. Dé los nombres más adecuados para estas entidades y dé uno o dos atributos para distinguirlos.

2. Cree un modelo ER basado en el texto. Ponga la entidad más general arriba de su página y el más específico 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 aquéllos que son clave.

3. Suponga que estamos modelando los datos de una COMPAÑIA. La base de datos COMPAÑIA debe mantener información sobre los empleados de la compañía, los departamentos y los proyectos. La descripción del mini-mundo (la parte de la compañía a ser representada en la base de datos) es la siguiente:

1. La compañía 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 número 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 realizándose en el mismo local). Puede haber localizaciones en la empresa en las que todavía no se esté realizando ningún proyecto.

3. Para cada empleado se desea tener su nombre completo (compuesto por nombre, primer apellido y segundo apellido), d.n.i., dirección, 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 número de horas semanales que un empleado trabaja en cada proyecto. Se quiere además saber cuál 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 propósitos de seguros. De cada persona dependiente se desea conocer el nombre, sexo, fecha de nacimiento y relación con el empleado. Por ejemplo, un empleado puede cubrir con su seguro al resto de miembros de su familia (sus personas dependientes).

REFERENCIAS BIBLIOGRÁFICAS

(1) Hawryszkiewcz (1994). México, ANÁLISIS Y DISEÑO DE BASE DE DATOS, De. Megabyte, p. : 3 – 49

(2) Gary, Hansen– James, Hansen (1997 ). Madrid, DISEÑO Y ADMINISTRACIÓN DE BASE DE DATOS, De. Pretince Hall, p. : 84

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

(4) Kroenke, México, PROCESAMIENTO DE BASE DE DATOS FUNDAMENTOS Y DISEÑO, De. Pretince may, 1985, p.: 55

4.1 ¿Por qué crear un diseño de base de datos?

El modelo ER describe los datos requeridos para los negocios. Este modelo debería ser totalmente independiente de algunas consideraciones que se realizan para la implementación. Este mismo modelo ER podría también ser usado como una base para la implementación de algún tipo de DBMS o incluso un sistema de archivos.

Un modelo ER es una representación 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 físico y las necesidades de la base de datos, pero ellos tendrán que proporcionar una solución conceptual “laborable”. Esto es, por que es importante tener un modelo ER de acuerdo a la realidad y validado antes de ir al diseño de la base de datos física.

Transformando el modelo ER, se crea un “primer corte” del diseño de la base de datos. Este diseño del primer corte es pensado para servir como una nueva base para definir la implementación física de la base de datos.

Este nuevo modelo puede ser fácilmente usado para las discusiones futuras entre diseñadores y desarrolladores, y administradores de bases de datos.

4.2 Presentación y Orígenes del Modelo Relacional

· El modelo Relacional fue introducido por Codd en el año 1970.

· Es un Modelo de Datos Lógico - de Representación (basado en registros).

· El modelo más usado en las aplicaciones comerciales de procesamiento de datos convencional. Esta dividido en 3 partes:

1. Estructura de Datos

2. Integridad de Datos (características generales)

3. Manipulación de Datos

4.3 Estructura de datos relacional

En el Modelo Relacional es una:

Base de Datos = Conjunto de RELACIONES

• Relación está representada mediante una Tabla con filas y columnas

· Estructura de datos fundamental del modelo

· Representa una entidad genérica

· 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 Teoría matemática

· Analogía entre Relación (concepto matemático) y Tabla

· Teoría de Conjuntos y Lógica de Predicados de 1er orden

· Tiene una sólida Base Formal

Ejemplo

EMPLEADO

Id

Nombre

Dirección

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.4Términos Básicos en el Modelo Relacional

Relación (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 información acerca de los empleados.

Tupla (Fila). Si la tupla t está en la relación 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 relación. Cada columna almacena información de una tipo específico como ID, Nombre, Dirección, Fecha_nacimiento y el ID del departamento asignado al empleado.

Cardinalidad. Numero de tuplas en una relación. Ejemplo en la relación empleado la cardinalidad es de 3.

Grado. Numero de atributos en una relación.

Ejemplo

La relación Empleado es de grado 5.

Dominio. Colección de valores permitidos para ciertos atributos.

4.5 Definiciones Formales

4.5.1 Dominio

Conjunto de valores atómicos del mismo tipo, donde toman su valor los atributos.

· La definición de dominios forma parte de la definición 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 ningún atributo

{valores de A}

Í

Dominio(A)

· “Comparaciones Restringidas a Dominio”

· La comparación de dos atributos sólo tiene sentido si ambos toman valores del mismo dominio

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

4.5.2 Relación

Una relación 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 sólo 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 relación será:

EMPLEADO (Id:Ids, Nombre:Nombres, Dirección:Direcciones, Fecha_Nacimiento:Fechas, Id_Dpto:Ids )

Un estado de la relación será:

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

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

· El estado de una relación es variable en el tiempo

· nuevas tuplas, modificación 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á más adelante)

4.5.2.1 Propiedades de una relación

1. No existen tuplas repetidas

2. Las tuplas no están ordenadas

3. Los atributos no están ordenados

esquema = conjunto de pares Atributo:Dominio

4. Los valores de atributos son Atómicos

Pq Dominio = Conjunto de valores atómicos

· Intersección fila/columna = un solo valor (no lista de valores)

· Si R cumple esta propiedad, R está en 1FN

4.5.2.2 Relación vs. Tabla

· Relación: Representación abstracta de elemento o entidad de datos

· Tabla: Representación concreta de tal elemento abstracto

· Ventajas

· Representación muy sencilla (tabla) del elemento abstracto

· básico (relación) del Modelo Relacional

· Fácil 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 colección de relaciones.

· De diversos grados (numero de atributos)

· Que varían con el tiempo (numero de tuplas, estado)

· Las relaciones (tablas) son la estructura lógica de la BD

· Niveles externo y conceptual ANSI/X3/SPARC

· Toda BDR cumple el Principio de Información: Todo contenido de información de la BD está representado de una y sólo una forma: como valores explícitos dentro de posiciones de columnas dentro de filas dentro de tablas.

· Conexión lógica entre Relaciones (vínculo o interrelación)

· Representada mediante valores

· No existen punteros (visibles al usuario)

· En una BDR distinguimos...

· Esquema de base de datos

· Descripción de la base de datos

· Conjunto de esquemas de relación

EMPLEADO (Id: Ids, Nombre: Nombres, Dirección: direcciones, Fecha_nacimiento: fechas, Id_dpto:Ids)

DEPARTAMENTO (Id_dpto: Ids, Nombre_dpto:Nombres)

· Estado o instancia de base de datos

· Visión del contenido de la base de datos en cierto instante

· Conjunto de estados de relación

4.6 Características Generales de Integridad

Todo estado de BD refleja la realidad:

· Es un MODELO de una PORCIÓN del mundo real (minimundo)

· Algunas configuraciones de valores NO tienen SENTIDO

· pues NO REPRESENTAN ningún estado posible del minimundo

Ejemplos

Dos personas distintas con el mismo CI

Un empleado sin Id

Un alumno con -29 años

Una película sin director

· La definición 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 información 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 lógico. 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 específicas de cada BD particular, pero el Modelo Relacional incluye...

· Características generales de integridad importantes y necesarias en toda BD

· Claves Candidatas y Primarias

· Claves Ajenas (o foráneas o externas)

4.6.1. 1 Superclave y clave de una relación

Sea R una relación R(A1:D1 , A2:D2 ,... An:Dn )

· Una superclave de R es un subconjunto SK de atributos tal que cumple la restricción de Unicidad es decir: No existen dos tuplas distintas con la misma combinación de valores para SK

· Una clave de R es una superclave tal que cumple la restricción de Irreductibilidad esto significa que: Ningún subconjunto de CK cumple la restricción de Unicidad

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

· Cada clave es una restricción de integridad

Ejemplos

· Claves como restricción de integridad:

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

¿Qué implicaciones tiene establecer como clave...

a) CK = {codCliente, ciudad}

b) CK = {codCliente}

· Varias claves en una relación

«Relación para registrar las visitas de pacientes a sus médicos de familia. Un mismo

paciente puede visitar a su médico varias veces en un mismo día»

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 foránea)

· Conjunto de atributos FK de una relación R2, tal que:

1. Existe otra relación R1 con clave primaria PK , y

2. Cada valor de FK en R2 es idéntico al de PK en alguna tupla de R1

“Una clave foránea es un conjunto de atributos de una relación que hace referencia a la clave primaria de otra relación (o la misma).”

· PELICULA (título, género, duración, director, ...)

DIRECTOR (nombre, nacionalidad, ...)

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

· LIBRO (título, isbn, autor, editorial, edición, año, ...)

ESCRITOR (dni, nombre, ...)

ARTICULO (título, tema, autor, revista, página, ...)

· 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, dirección, ...)

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

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

· La clave Ajena puede ser Simple o Compuesta

· El uso de Claves Ajenas facilita a:

· Eliminación de la Redundancia: Integridad entre ficheros

· Mecanismo del Modelo Relacional de datos para establecer VÍNCULOS ENTRE RELACIONES

EJEMPLO

En las siguientes relaciones:

CUENTA

NUMERO

SALDO

…

200

35000

505

45000

821

30000

…

CLIENTE

NOMBRE

DIRECCION

CIUDAD

CUENTA

García

San Pedro

La Paz

200

Lopez

Santa Rosa

El Alto

821

Blanco

Villa Fátima

La Paz

505

…

Cada cliente sólo puede tener una cuenta a su nombre. Una cuenta puede tener más de un cliente como titular.

· La Restricción 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 relación hace referencia a otra relación, debe referirse a una tupla existente en esa relación

EJEMPLO

ARTICULO ESCRITOR

· Puede existir algún valor de PK al que NO haga referencia ningún valor de la FK

· ESCRITOR que no haya escrito artículos: ninguna tupla de ARTICULOhará referencia a la tupla correspondiente a dicho escritor

· Diagrama Referencial

· Expresión 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 relación. 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 aplicación Hotel

· ¿Qué pasaría si se eliminara la tupla (501, D, ...) en HABITACIÓN?

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

· ¿Y si se anotara la ocupación de la habitación 900?

¿Cómo evita el SGBD esos estados incorrectos?

El SGBD puede...

· Rechazar toda operación que pueda provocar un estado ilegal,

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

Diseñador 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

Operación: Eliminar una tupla t de R1 que es referenciada por otras de R2

Ejemplo

Eliminar la tupla (100, D, ...) de HABITACIÓN

Acciones posibles:

1. Rechazar la operación (acción por defecto). Sólo permite borrar t si ninguna otra tupla hace referencia a t

2. Cascada. Propagar la eliminación

1º Borrar todas las tuplas de R2 que referencian a t

2º Eliminar t

3. Establecer nulos

Operación: Modificar el valor de una FK a un valor no existente en la PK de R1

Ejemplo

Modificar (CLI02, 420,...) a (CLI02, 900,...) en OCUPACIÓN

Acción:

1. Rechazar la operación (SIEMPRE). Intento de violación de la restricción de Integridad Referencial

Operación: Inserción de una tupla t en R2 cuyo valor de FK no se corresponde con ningún valor de la PK en ninguna tupla de R1

Ejemplo

Insertar una tupla (CLI03, 555, ...) en OCUPACIÓN

Acciones posibles:

- Rechazar la operación (SIEMPRE). Intento de violación de la restricción de Integridad Referencial

Encadenamiento de eliminaciones (análogo para Modificación)

R2(R1, Acción de Eliminación en Cascada R3(R2(R1

R3 (R2, Acción de Eliminación X

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

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

¿cómo afecta la Acción de Eliminación X en esta operación?

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

· Si X = RECHAZAR ( La operación completa fallará

· Las operaciones de actualización en una BD son siempre atómicas: se realiza “TODO o NADA”

PROFESOR ( ÁREA (DEPARTAMENTO

ASIGNATURA (TITULACIÓN (UNIVERSIDAD

4.6.1.5 Valores Nulos

En el mundo real existe...

· Información perdida fechaNacimiento desconocida

· Ausencia de información ¿tiene teléfono?

· 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 información.

· No hay dos nulos iguales (num_telefono NULL <> edad NULL)

Implicaciones de los Nulos en la Integridad

· NULO y Claves Primarias:

Restricción de Integridad de Entidad: Ningún atributo componente de una clave primaria puede contener nulo.

Ejemplos

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

¿Qué pasaría 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 ningún departamento

jefe = null ( empleados sin jefe

Hemos de extender la definición de clave ajena:

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

1. Existe otra relación R1 con clave primaria PK y

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

a) es NULO, o

b) es idéntico a un valor de PK en alguna tupla de R1

Restricción 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

Operación: Eliminar una tupla t de R1 que es referenciada por otras de R2

Acciones posibles:

1. Rechazar la operación (acción por defecto)

2. Cascada. Propagar la eliminación

3. Establecer nulos Sólo 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

Operación: 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 operación (acción por defecto)

2. Cascada. Propagar la modificación

3. Establecer nulos

Sólo 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 Transformación

Usando las reglas de transformación podemos crear un nuevo modelo basado en el modelo conceptual.

Terminología de Mapeo

ANÁLISIS

DISEÑO

Modelo ER

Diseño físico

Entidad

Tabla

Atributo

Columna

Relación

Llave foránea

identificador único primario Llave primaria

identificador único secundario Llave única

Cambiando de una palabra a otra (????), también cambiando los significados de la terminología.

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 relación es transformada en una llave foránea o columnas de llave foránea

4.7.1 Mapeo Básico

Mapeo de entidades

Transformar entidades en tablas usando su propia convención de la denominación 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 Leaño

Académico

50.000

190

Evo Morales

Adepcoca

700.000

Usted puede expresar la estructura de una relación por una notación mas corta en la cual el nombre de la relación es seguida por braquetas para el nombre de los atributos en la relación. 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 relación correspondiente.

Mapeo de relaciones

El procedimiento para mapear relaciones depende del grado de la relación y la cardinalidad.

4.7.2 Obtención de las relaciones a partir del diagrama E/R

A continuación 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 participación de ambas, sólo es necesario una relación. Como clave primaria de la relación 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 anomalías es necesario definir una nueva regla.

Diagrama

Transformación

PROVEEDOR

Anomalías cuando una de las entidades deja de ser obligatoria y es opcional

Num

Nom

Cod_ar

Desc

11

Perez

A1

Computadoras

22

Hernández

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 participación de una entidad es obligatoria y el de la otra es opcional, son necesarias dos relaciones. Cada una contendrá la información concerniente a una entidad y su clave primaria será la clave de la entidad correspondiente. La clave de la entidad opcional se añadirá como un atributo más en la relación cuyo tipo de participación sea obligatoria.”

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

Diagrama

Transformación

Anomalías cuando ambas entidades son opcionales

Regla 3

“Si la correspondencia es binaria y la cardinalidad es 1:1 y el tipo de participación 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 relación con la correspondencia deberá contener las claves de las entidades.”

Con tres relaciones es la única manera de que no se produzca ningún tipo de anomalías.

Diagrama

Transformación

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 relación de la entidad «n» contiene la clave de la entidad «1»”.

Diagrama

Transformación

Anomalías 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 relación con la correspondencia contendrá las claves de las entidades.”

Diagrama

Transformación

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 relación con la correspondencia deberá contener las claves de las entidades.”

Diagrama

Transformación

Relaciones preliminares para las correspondencias ternarias

Regla 7

“Si existe una correspondencia ternaria se necesitan cuatro relaciones, una para cada entidad, y una más para la correspondencia. La clave de las relaciones de las entidades es la clave primaria de la entidad correspondiente. La relación que contenga los datos de la correspondencia contendrá entre sus atributos las claves de las entidades.”

Diagrama

Transformación

Relaciones para la agregación

La transformación de un diagrama ER que incluye agregación a una forma tabular es directa. Por ejemplo, sea:

Para el diagrama creamos las siguientes tablas:

· EMPLEADO

· PROYECTO

· TRABAJO

· MAQUINARIA

· USA

Relaciones para la generalización

Sea el siguiente ejemplo de generalización – especialización.

Existen dos métodos diferentes para transformar un diagrama ER que incluye generalización en una forma tabular:

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

· cuenta, con atributos número_cuenta y saldo

· cuenta_ahorro, con atributos número_cuenta y tasa_interés

· cuenta_cheques, con atributos número_cuenta y saldo_deudor

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

· cuenta_ahorros, con atributos número_cuenta y tasa_interés

· cuenta_cheques con atributos número_cuenta y saldo_deudor

4.7.3 Representación de conjuntos de entidades débiles

Sea A un conjunto de entidades débiles 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

TRANSACCIÓN

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 BIBLIOGRÁFICAS

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

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

(3) Gary, Hansen – James, Hansen, Madrid, DISEÑO Y ADMINISTRACIÓN DE BASE DE DATOS, De. Pretince Hall, 1997, p. : 84

5.1 Definición de Normalización

Se entiende por normalización la descomposición o subdivisión de una relación en dos o más relaciones para evitar la redundancia; en definitiva, “que cada hecho esté en su lugar”.

El proceso de normalización generalmente se utiliza en el enfoque relacional; sin embargo, un modelo relacional se puede modificar para su implementación en un DBMS, jerárquico o de red.

Normalización es un concepto de base de datos relacional. Sin embargo, si usted crea un modelo de entidad relación correcto, entonces las tablas creadas durante el diseño conformarán las reglas de normalización. Cada regla de las formas normales del diseño de la base de datos relacional tiene una interpretación en el modelo de datos correspondiente.

Reglas de Normalización

Reglas de la Forma Normal

Descripción

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)

Ningún atributo no clave debe ser dependiente de otro atributo no clave

“Un modelo de datos entidad relación normalizado, automáticamente traslada en un diseño de base de datos relacional normalizado”

“La tercera forma normal es la meta generalmente aceptada para un diseño de base de datos que eliminó la redundancia”

La relacional universal

Supongamos que se desea implementar en una base de datos el TIPO DE INFORMACIÓN que proviene de alguna AGENCIA (fuente de información) en un medio de comunicación escrita.

Los datos correspondientes se muestran en la siguiente relación (tabla).

INFORMACIÓN

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

Teléfono

A010

CNN

...

...

...

...

...

...

...

5.2 Relaciones bien Estructuradas

Es una relación que contiene una cantidad mínima 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 relación. Cada fila de la tabla contiene datos que describen a un empleado y cualquier modificación a los datos (tales como el cambio en el salario) de un empleado se realiza en una fila de la tabla.

Redundancia, Anomalías

La redundancia en una tabla puede producir errores o inconsistencias (llamado anomalías) cuando el usuario actualiza algún dato en la tabla. Tres tipos de anomalías son posibles:

1. Anomalía de inserción. Suponga que usted necesita adicionar un nuevo empleado a EMPLEADO1. La llave primaria para esta relación es la combinación 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 anomalía, el usuario puede introducir los datos del empleado sin los datos del curso correspondientes.

2. Anomalías de eliminación. Supongamos que los datos del empleado 140 es eliminado en la tabla. Esto producirá perdida de información, por que este empleado completó un curso.

3. Anomalías 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 podría ser inconsistente.

5.3 Dependencia Funcional (DF)

La normalización se basa en la dependencia funcional.

El concepto de dependencia funcional se tomó de las matemáticas.

[

]

)

(

X

f

Y

=

, Y es función 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 relación y deducir cómo están relacionados los atributos entre sí.

La dependencia funcional está íntimamente ligada con el concepto de clave. Para el diseño, las claves aparecen subrayadas.

5.4 Primera Forma Normal (1FN)

Todo atributo debe ser valor – simple (indivisible, atómico). Valor atómico 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 relación R es completo dependiente funcionalmente del atributo X de la relación R, si depende funcionalmente de X y no depende funcionalmente de ningún 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 relación 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 sólo de una parte, es decir, debe tener dependencia funcional completa.

Ejemplo

Sea un ambiente de aplicación de una Importadora de productos cuyos datos de factura se registran en:

NumFac

Fecha

Cliente

Descripción

Cantidad

Precio

Total

Origen

26009

26/07/94

Sambrana

Palanca

1

49

81

Japonés

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

Japonés

75002

29/08/94

Cevallos

Cable

6

50

50

Chino

Ahora encontremos la clave primaria:

Consideremos los atributos NumFac y Descripción, para este conjunto de atributos los demás dependen funcionalmente.

Como se puede observar en el gráfico Fecha, Total y Cliente dependen del total de la clave pero también 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 anomalías:

· La Fecha, Cliente y Total se repiten para cada Descripción del producto

· Si el nombre del Cliente cambia, cada fila que se refiere a su número de facturación cambia.

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

Entonces dividimos la tabla de acuerdo al gráfico, como muestra las líneas punteadas

De aquí tenemos dos tablas:

Factura < NumFac, Fecha, Total, Cliente >

Linea_Factura < NumFac, Descripción, 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 proyección del último eslabón de la forma:

R1

R1

5.8 Tercera Forma Normal (3FN)

Una relación 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 aplicación de proyectos que realiza cierto Ministerio de Gobierno, que son desarrollados por una Institución.

Cod_P

Proyecto

Institución

Dirección

PC-01

Riego

CIPE

Z. San Pedro #324

PC-02

Electrificación

CIPE

Z. San Pedro #324

PC-03

Posta Sanitaria

CIPE

Z. San Pedro #324

PC-04

Alfabetización

UNICEF

Z. San Jorge #121

PC-05

Forestación

PAC

Z. Miraflores #34

PC-06

Agua Potable

PAC

Z. Miraflores #34

La clave primaria de esta relación será Cod_P ya que cada uno de los demás atributos depende de esta.

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

· Para cada institución se repite su domicilio.

· Si la dirección de una institución cambia todas las tuplas que contengan esa institución cambia. Si se borra un proyecto, se pierde los datos correspondientes a la institución. Por tanto existen anomalías de actualización y borrado.

· Si se desea registrar a una nueva institución, necesariamente tiene que estar asignado a un proyecto.

Por tanto dividimos la relación en otras dos de acuerdo al gráfico:

Proyecto

Institución

5.9 Definición 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 relación R está en forma normal de Boyce Codd si, y solo sí, cada determinante de la relación es una clave candidata, es decir