UNIVERSIDAD SALESIANA DE BOLIVIA

CARRERA INGENIERA DE SISTEMAS

DOSSIER

BASE DE DATOS I

Cuarto Semestre

Lic. Katya Maricela Prez Martnez

Lic. Carmen Rosa Mollinedo Laura

NDICE

5PRESENTACIN

6I.FUNDAMENTOS DE BASES DE DATOS

61.1.Introduccin a las bases de datos

61.1.1.Introduccin

61.2.Concepto y origen de las BD y de los SGBD

81.3.Evolucin de los SGBD

81.3.1.Los aos sesenta y setenta: sistemas centralizados

91.4.Los aos ochenta: SGBD relacionales

91.5.Los aos noventa: distribucin, C/S y 4GL

121.6.Tendencias actuales

121.6.1.Objetivos y servicios de los SGBD

141.7.Arquitectura de un SGBD e independencia de datos

141.8.Arquitectura de tres esquemas

15Nivel Interno

16Nivel Conceptual

16Nivel Externo

171.9.Independencia de datos

181.10.Lenguajes y usuarios

191.11.Administracin de BD

21II. MODEOS DE DATOS

212.1 Introduccin

212.2 La importancia de los modelos de datos

222.3 Clasificacin de los modelos

222.3.1 Modelos lgicos basados en objetos

242.3.2 Modelos lgicos basados en registros

32III.MODELO ENTIDAD RELACION

323.1 Modelo Conceptual

323.2Definicin del Modelo E/R

323.3Objetivos del Modelo

333.4Terminologa utilizada en el Modelo

333.4.1 Entidad

33INSTANCIAS

343.4.2 Entidad Dbil

343.4.3 Atributo

353.4.5 Claves candidatas e identificadores

363.4.6 Atributos Multivaluados

363.4.7 Relaciones

37Notacin Entidad Relacin

373.5 Grados de una relacin

38(Relaciones Unarias

38(Relaciones Binarias

393 Relacin ternaria

393.6 Cardinalidad de relaciones y participaciones

403.6.1 Cardinalidad Mnima y Mxima

40Cardinalidad Mnima

403.6.2 Tipos de relaciones

423.7 Generalizacin

433.8 Agregacin Y Entidades Asociativas

45Ejercicios propuestos

48IV.MODELO RELACIONAL

484.1 Por qu crear un diseo de base de datos?

494.2 Presentacin y Orgenes del Modelo Relacional

494.3 Estructura de datos relacional

504.4Trminos Bsicos en el Modelo Relacional

504.5Definiciones Formales

504.5.1.Dominio

514.5.2.Relacin

524.5.2.1Propiedades de una relacin

524.5.2.2Relacin vs. Tabla

524.5.3Base de Datos Relacional

534.6Caractersticas Generales de Integridad

544.6.1Reglas de Integridad

544.6.1.1 Superclave y clave de una relacin

554.6.1.2Clave candidata, primaria y alternativa

554.6.1.3clave ajena (externa o fornea)

574.6.1.4Mantenimiento de la Integridad Referencial

594.6.1.5Valores Nulos

614.7Proceso de Transformacin

624.7.1Mapeo Bsico

63Del ejemplo anterior tenemos:

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

67Relaciones para la agregacin

67Relaciones para la generalizacin

684.7.3 Representacin de conjuntos de entidades dbiles

70V.NORMALIZACION

705.1 Definicin de Normalizacin

70La relacional universal

715.2 Relaciones bien Estructuradas

725.3 Dependencia Funcional (DF)

735.4 Primera Forma Normal (1FN)

745.5 Dependencia Funcional Completa

775.6 Segunda Forma Normal (2FN)

785.7 Dependencia Transitiva

795.8 Tercera Forma Normal (3FN)

805.9 Definicin de Determinante

805.10 Forma Normal de Boyce Codd (BCFN)

815.11 Dependencia de Valores Multivaluados (DMV)

835.12 Cuarta Forma Normal (4FN)

85VI.OPERACIONES DEL MODELO RELACIONAL

856.1 Introduccin

856.2 lgebra Relacional

866.2.1 Operadores de conjuntos

886.2.2 Operadores Relacionales

916.3 Clculo Relacional

94VII.INTRODUCCION AL LENGUAJE DE CONSULTA SQL

947.1 DEFINICIN DE UN LENGUAJE DE CONSULTA

957.2 Definicin de datos

977.3 Manipulacin de datos

987.4 Operaciones sobre una relacin

1007.5 Operaciones sobre ms de una relacin

1027.6 Ejercicios sobre operaciones

1047.7 Expresiones con bloques anidados

109ALMACENAMIENTO SECUNDARIO

109API

109APLICACIN

109ARCHIVO

110BACKUP

110BASE DE DATOS

112INFORMACIN

113SISTEMA

114Lneas de evolucin de las Bases de Datos

114Diccionario de datos

114Bases de Datos Distribuidas

114Modelo Vista Controlador

114Las doce reglas de Codd

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.

I.

FUNDAMENTOS DE BASES DE DATOS

1.1. Introduccin a las bases de datos

1.1.1. Introduccin

Empezaremos esta unidad didctica viendo cules son los objetivos de los sistemas de gestin de las bases de datos (SGBD) y, a continuacin, daremos una visin general de la arquitectura, el Funcionamiento y el entorno de estos sistemas.

Objetivos

En esta unidad encontraras las herramientas para adquirir una visin global del mundo de las BD y de los SGBD, as como para alcanzar los siguientes objetivos:

1. Conocer a grandes rasgos la evolucin de los SGBD desde los aos sesenta hasta la actualidad.

2. Distinguir los principales objetivos de los SGBD actuales y contrastarlos con los sistemas de ficheros tradicionales.

3. Saber explicar mediante ejemplos los problemas que intenta resolver el concepto de transaccin.

4. Relacionar la idea de flexibilidad en los cambios con la independencia lgica y fsica de los datos, as como con la arquitectura de tres niveles.

5. Distinguir los principales modelos de BD.

6. Conocer a grandes rasgos el funcionamiento de un SGBD.

7. Saber relacionar los diferentes tipos de lenguajes con los diferentes tipos de usuarios.

1.2. Concepto y origen de las BD y de los SGBD

Las aplicaciones informticas de los aos sesenta acostumbraban a darse totalmente por lotes (batch) y estaban pensadas para una tarea muy especfica relacionada con muy pocas entidades tipo.

Cada aplicacin (una o varias cadenas de programas) utilizaba ficheros de movimientos para actualizar (creando una copia nueva) y/o para consultar uno o dos ficheros maestros o, excepcionalmente, ms de dos. Cada programa trataba como mximo un fichero maestro, que sola estar sobre cinta magntica y, en consecuencia, se trabajaba con acceso secuencial. Cada vez que se le quera aadir una aplicacin que requera el uso de algunos de los datos que ya existan y de otros nuevos, se diseaba un fichero nuevo con todos los datos necesarios (algo que provocaba redundancia) para evitar que los programas tuviesen que leer muchos ficheros.

A medida que se fueron introduciendo las lneas de comunicacin, los terminales y los discos, se fueron escribiendo programas que permitan a varios usuarios consultar los mismos ficheros on-line y de forma simultnea. Ms adelante fue surgiendo la necesidad de hacer las actualizaciones tambin on-line.

A medida que se integraban las aplicaciones, se tuvieron que interrelacionar sus ficheros y fue necesario eliminar la redundancia. El nuevo conjunto de ficheros se deba disear de modo que estuviesen interrelacionados; al mismo tiempo, las informaciones redundantes (como por ejemplo, el nombre y la direccin de los clientes o el nombre y el precio de los productos), que figuraban en los ficheros de ms de una de las aplicaciones, deban estar ahora en un solo lugar.

El acceso on-line y la utilizacin eficiente de las interrelaciones exigan estructuras fsicas que diesen un acceso rpido, como por ejemplo los ndices, las multilistas, las tcnicas de hashing, etc.

Estos conjuntos de ficheros interrelacionados, con estructuras complejas y compartidos por varios procesos de forma simultnea (unos on-line y otros po lotes), recibieron al principio el nombre de Data Banks, y despus, a inicios de los aos setenta, el de Data Bases. Aqu los denominamos bases de datos (BD).

El software de gestin de ficheros era demasiado elemental para dar satisfaccin a todas estas necesidades. Por ejemplo, el tratamiento de las interrelaciones no estaba previsto, no era posible que varios usuarios actualizaran datos simultneamente, etc. La utilizacin de estos conjuntos de ficheros por parte de los programas de aplicacin era excesivamente compleja, de modo que, especialmente durante la segunda mitad de los aos setenta, fue saliendo al mercado

software ms sofisticado: los Data Base Management Systems, que aqu denominamos sistemas de gestin de BD (SGBD).

Con todo lo que hemos dicho hasta ahora, podramos definir el trmino BD; una base de datos de un SI es la representacin integrada de los conjuntos de entidades instancia correspondientes a las diferentes entidades tipo del SI y de sus interrelaciones. Esta representacin informtica (o conjunto estructurado de datos) debe poder ser utilizada de forma compartida por muchos usuarios de distintos tipos.

En otras palabras, una base de datos es un conjunto estructurado de datos que representa entidades y sus interrelaciones. La representacin ser nica e integrada, a pesar de que debe permitir utilizaciones varias y simultneas.

Los ficheros tradicionales y las BD Aunque de forma muy simplificada, podramos enumerar las principales diferencias entre los ficheros tradicionales y las BD tal y como se indica a continuacin:

1) Entidades tipos:

Ficheros: tienen registros de una sola entidad tipo.

BD: tienen datos de varias entidades tipo.

2) Interrelaciones:

Ficheros: el sistema no interrelaciona ficheros.

BD: el sistema tiene previstas herramientas para interrelacionar entidades.

3) Redundancia:

Ficheros: se crean ficheros a la medida de cada aplicacin, con todos los datos necesarios aunque algunos sean redundantes respecto de otros ficheros.

BD: todas las aplicaciones trabajan con la misma BD y la integracin de los datos es bsica, de modo que se evita la redundancia.

4) Usuarios

Ficheros: sirven para un solo usuario o una sola aplicacin. Dan una sola visin del mundo real.

BD: es compartida por muchos usuarios de distintos tipos. Ofrece varias visiones del mundo real.

1.3. Evolucin de los SGBD

Para entender mejor qu son los SGBD, haremos un repaso de su evolucin desde los aos sesenta hasta nuestros das.

1.3.1. Los aos sesenta y setenta: sistemas centralizados

Los SGBD de los aos sesenta y setenta (IMS de IBM, IDS de Bull, DMS de Univac, etc.) eran sistemas totalmente centralizados, como corresponde a los sistemas operativos de aquellos aos, y al hardware para el que estaban hechos: un gran ordenador para toda la empresa y una red de terminales sin inteligencia ni memoria.

Los primeros SGBD en los aos sesenta todava no se les denominaba as estaban orientados a facilitar la utilizacin de grandes conjuntos de datos en los que las interrelaciones eran complejas. El arquetipo de aplicacin era el Bill of materials o Parts explosin, tpica en las industrias del automvil, en la construccin de naves espaciales y en campos similares. Estos sistemas trabajaban exclusivamente por lotes (batch).

Al aparecer los terminales de teclado, conectados al ordenador central mediante una lnea telefnica, se empiezan a construir grandes aplicaciones on-line transaccionales (OLTP). Los SGBD estaban ntimamente ligados al software de comunicaciones y de gestin de transacciones.

Aunque para escribir los programas de aplicacin se utilizaban lenguajes de alto nivel como Cobol o PL/I, se dispona tambin de instrucciones y de subrutinas especializadas para tratar las BD que requeran que el programador conociese muchos detalles del diseo fsico, y que hacan que la programacin fuese muy compleja.

Puesto que los programas estaban relacionados con el nivel fsico, se deban modificar continuamente cuando se hacan cambios en el diseo y la organizacin de la BD. La preocupacin bsica era maximizar el rendimiento: el tiempo de respuesta y las transacciones por segundo.

1.4. Los aos ochenta: SGBD relacionales

Los ordenadores minis, en primer lugar, y despus los ordenadores micros, extendieron la informtica a prcticamente todas las empresas e instituciones.

La aparicin de los SGBD relacionales* supone un avance importante para facilitar la programacin de aplicaciones con BD y para conseguir que los programas sean independientes de los aspectos fsicos de la BD.

1.5. Los aos noventa: distribucin, C/S y 4GL

La necesidad de tener una visin global de la empresa y de interrelacionar diferentes aplicaciones que utilizan BD diferentes, junto con la facilidad que dan las redes para la intercomunicacin entre ordenadores, ha conducido a los SGBD actuales, que permiten que un programa pueda trabajar con diferentes BD como si se tratase de una sola. Es lo que se conoce como base de datos distribuida.

Esta distribucin ideal se consigue cuando las diferentes BD son soportadas por una misma marca de SGBD, es decir, cuando hay homogeneidad. Sin embargo, esto no es tan sencillo si los SGBD son heterogneos. En la actualidad, gracias principalmente a la estandarizacin del lenguaje SQL, los SGBD de marcas diferentes pueden darse servicio unos a otros y colaborar para dar servicio a un programa de aplicacin. No obstante, en general, en los casos de heterogeneidad no se llega a poder dar en el programa que los utiliza la apariencia de que se trata de una nica BD.

Adems de esta distribucin impuesta, al querer tratar de forma integrada distintas BD preexistentes, tambin se puede hacer una distribucin deseada, diseando una BD distribuida fsicamente, y con ciertas partes replicadas en diferentes sistemas. Las razones bsicas por las que interesa esta distribucin son las siguientes:

1) Disponibilidad. La disponibilidad de un sistema con una BD distribuida puede ser ms alta, porque si queda fuera de servicio uno de los sistemas, los de ms seguirn funcionando. Si los datos residentes en el sistema no disponible estn replicados en otro sistema, continuarn estando disponibles. En caso contrario, slo estarn disponibles los datos de los dems sistemas.

2) Coste. Una BD distribuida puede reducir el coste. En el caso de un sistema centralizado, todos los equipos usuarios, que pueden estar distribuidos por distintas y lejanas reas geogrficas, estn conectados al sistema central por medio de lneas de comunicacin. El coste total de las comunicaciones se puede reducir haciendo que un usuario tenga ms cerca los datos que utiliza con mayor frecuencia; por ejemplo, en un ordenador de su propia oficina o, incluso, en su ordenador personal.

Por ejemplo, un programa de aplicacin que un usuario ejecuta en su PC (que est conectado a una red) pide ciertos datos de una BD que reside en un equipo UNIX donde, a su vez, se ejecuta el SGBD relacional que la gestiona. El programa de aplicacin es el cliente y el SGBD es el servidor.

Un proceso cliente puede pedir servicios a varios servidores. Un servidor puede recibir peticiones de muchos clientes. En general, un proceso A que hace decliente, pidiendo un servicio a otro proceso B puede hacer tambin de servidor de un servicio que le pida otro proceso C (o incluso el B, que en esta peticin sera el cliente). Incluso el cliente y el servidor pueden residir en un mismo sistema.

Figura 2

La facilidad para disponer de distribucin de datos no es la nica razn, ni siquiera la bsica, del gran xito de los entornos C/S en los aos noventa. Tal vez el motivo fundamental ha sido la flexibilidad para construir y hacer crecer la configuracin informtica global de la empresa, as como de hacer modificaciones en ella, mediante hardware y software muy estndar y barato.

El xito de las BD, incluso en sistemas personales, ha llevado a la aparicin de los Fourth Generation Languages (4GL), lenguajes muy fciles y potentes, especializados en el desarrollo de aplicaciones fundamentadas en BD. Proporcionan muchas facilidades en el momento de definir, generalmente de forma visual, dilogos para introducir, modificar y consultar datos en entornos C/S.

1.6. Tendencias actuales

Hoy da, los SGBD relacionales estn en plena transformacin para adaptarse a tres tecnologas de xito reciente, fuertemente relacionadas: la multimedia, la de orientacin a objetos (OO) e Internet y la web.

1.6.1. Objetivos y servicios de los SGBD

Los SGBD que actualmente estn en el mercado pretenden satisfacer un conjunto de objetivos directamente deducibles de lo que hemos explicado hasta ahora. A continuacin los comentaremos, pero sin entrar en

Consultas no predefinidas y complejas

El objetivo fundamental de los SGBD es permitir que se hagan consultas no predefinidas (ad hoc) y complejas.

Consultas que afectan a ms de una entidad tipo

Se quiere conocer el nmero de alumnos de ms de veinticinco aos y con nota media

superior a siete que estn matriculados actualmente en la asignatura Bases de datos I.

De cada alumno matriculado en menos de tres asignaturas, se quiere obtener el nombre,

el nmero de matrcula, el nombre de las asignaturas y el nombre de profesores de estas

asignaturas.

Flexibilidad e independencia

La complejidad de las BD y la necesidad de irlas adaptando a la evolucin del SI hacen que un objetivo bsico de los SGBD sea dar flexibilidad a los cambios.

Interesa obtener la mxima independencia posible entre los datos y los procesos usuarios para que se pueda llevar a cabo todo tipo de cambios tecnolgicos y variaciones en la descripcin de la BD, sin que se deban modificar los programas de aplicacin ya escritos ni cambiar la forma de escribir las consultas (o actualizaciones) directas.

Ejemplos de independencia lgica

1) El personal administrativo de secretara podra tener una visin de la entidad alumno sin

que fuese necesario que existiese el atributo nota. Sin embargo, los usuarios profesores (o los programas dirigidos a ellos) podran tener una visin en la que existiese el atributo nota pero no el atributo fecha de pago.

2) Decidimos ampliar la longitud del atributo nombre y lo aumentamos de treinta a cincuenta caracteres, pero no sera necesario modificar los programas que ya tenemos escritos si no nos importa que los valores obtenidos tengan slo los primeros treinta caracteres del nombre.

Problemas de la redundancia

En el mundo de los ficheros tradicionales, cada aplicacin utilizaba su fichero. Sin embargo, puesto que se daba mucha coincidencia de datos entre aplicaciones, se produca tambin mucha redundancia entre los ficheros. Ya hemos dicho que uno de los objetivos de los SGBD es facilitar la eliminacin de la redundancia.

La duplicacin de datos es el tipo de redundancia ms habitual, pero tambin tenemos redundancia cuando guardamos en la BD datos derivados (o calculados) a partir de otros datos de la misma BD. De este modo podemos responder rpidamente a consultas globales, ya que nos ahorramos la lectura de gran cantidad de registros

Integridad de los datos

Cuando el SGBD detecte que un programa quiere hacer una operacin que va contra las reglas establecidas al definir la BD, no se lo deber permitir, y le tendr que devolver un estado de error.

Al disear una BD para un SI concreto y escribir su esquema, no slo definiremos los datos, sino tambin las reglas de integridad que queremos que el SGBD haga cumplir.

Concurrencia de usuarios

Un objetivo fundamental de los SGBD es permitir que varios usuarios puedan acceder concurrentemente a la misma BD.

Cuando los accesos concurrentes son todos de lectura (es decir, cuando la BD slo se consulta), el problema que se produce es simplemente de rendimiento, causado por las limitaciones de los soportes de que se dispone: pocos mecanismos de acceso independientes, movimiento del brazo y del giro del disco demasiado lentos, buffers locales demasiado pequeos, etc

Ejemplos de transacciones

1) Imaginemos un programa pensado para llevar a cabo la operacin de transferencia de dinero de una cuenta X a otra Y. Supongamos que la transferencia efecta dos operaciones: en primer lugar, el cargo a X y despus, el abono a Y. Este programa se debe ejecutar de forma que se hagan las dos operaciones o ninguna, ya que si por cualquier razn (por ejemplo, por interrupcin del flujo elctrico) el programa ejecutase slo el cargo de dinero a X sin abonarlos a Y, la BD quedara en un estado incorrecto. Queremos que la ejecucin de este programa sea tratada por el SGBD como una transaccin de BD.

2) Otro ejemplo de programa que querramos que tuviera un comportamiento de transaccin podra ser el que aumentara el 30% de la nota de todos los alumnos. Si slo aumentara la nota a unos cuantos alumnos, la BD quedara incorrecta.

Seguridad

El trmino seguridad se ha utilizado en diferentes sentidos a lo largo de la historia de la informtica. Los SGBD permiten definir autorizaciones o derechos de acceso a diferentes niveles: al nivel global de toda la BD, al nivel entidad y al nivel atributo.

Estos mecanismos de seguridad requieren que el usuario se pueda identificar. Se acostumbra a utilizar cdigos de usuarios (y grupos de usuarios) acompaados de contraseas (passwords), pero tambin se utilizan tarjetas magnticas, identificacin por reconocimiento de la voz, etc.

Nos puede interesar almacenar la informacin con una codificacin secreta; es decir, con tcnicas de encriptacin (como mnimo se deberan encriptar las contraseas). Muchos de los SGBD actuales tienen prevista la encriptacin.

Otros objetivos de los SGBD

Acabamos de ver los objetivos fundamentales de los SGBD actuales. Sin embargo, a medida que los SGBD evolucionan, se imponen nuevos objetivos adaptados a las nuevas necesidades y las nuevas tecnologas. Como ya hemos visto, en estos momentos podramos citar como objetivos nuevos o recientes los siguientes:

1) Servir eficientemente los Data Warehouse.

2) Adaptarse al desarrollo orientado a objetos.

3) Incorporar el tiempo como un elemento de caracterizacin de la informacin.

4) Adaptarse al mundo de Internet.

1.7. 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.

1.8. 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.

1.9. 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.

1.10. Lenguajes y usuarios

Para comunicarse con el SGBD, el usuario, ya sea un programa de aplicacin o un usuario directo, se vale de un lenguaje. Hay muchos lenguajes diferentes, segn el tipo de usuarios para los que estn pensados y el tipo de cosas que los usuarios deben poder expresar con ellos:

a) Habr usuarios informticos muy expertos que querrn escribir procesos complejos y que necesitarn lenguajes complejos.

b) Sin embargo, habr usuarios finales no informticos, ocasionales (espordicos), que slo harn consultas. Estos usuarios necesitarn un lenguaje muy sencillo, aunque d un rendimiento bajo en tiempo de respuesta.

c) Tambin podr haber usuarios finales no informticos, dedicados o especializados.

Son usuarios cotidianos o, incluso, dedicados exclusivamente a trabajar con la BD. Estos usuarios necesitarn lenguajes muy eficientes y compactos, aunque no sea fcil aprenderlos. Tal vez sern lenguajes especializados en tipos concretos de tareas.

Hay lenguajes especializados en la escritura de esquemas; es decir, en la descripcin de la BD. Se conocen genricamente como DDL o data definition language. Incluso hay lenguajes especficos para esquemas internos, lenguajes para esquemas conceptuales y lenguajes para esquemas externos.

Otros lenguajes estn especializados en la utilizacin de la BD (consultas y mantenimiento). Se conocen como DML o data management language.

Sin embargo, lo ms frecuente es que el mismo lenguaje disponga de construcciones para las dos funciones, DDL y DML.

El lenguaje SQL, que es el ms utilizado en las BD relacionales, tiene verbos, instrucciones

de tres tipos diferentes:

1) Verbos del tipo DML; por ejemplo, SELECT para hacer consultas, e INSERT, UPDATE y DELETE para hacer el mantenimiento de los datos.

2) Verbos del tipo DDL; por ejemplo, CREATE TABLE para definir las tablas, sus columnas y las restricciones.

3) Adems, SQL tiene verbos de control del entorno, como por ejemplo COMMIT y ROLLBACK para delimitar transacciones.

En cuanto a los aspectos DML, podemos diferenciar dos tipos de lenguajes:

a) Lenguajes muy declarativos (o implcitos), con los que se especifica qu se quiere hacer sin explicar cmo se debe hacer.

b) Lenguajes ms explcitos o procedimentales, que nos exigen conocer ms cuestiones del funcionamiento del SGBD para detallar paso a paso cmo se deben realizar las operaciones (lo que se denomina navegar por la BD). Como es obvio, los aspectos DDL (las descripciones de los datos) son siempre declarativos por su propia naturaleza.

Los lenguajes utilizados en los SGBD prerrelacionales eran procedimentales. SQL es bsicamente declarativo, pero tiene posibilidades procedimentales

Tanto los 4GL como las herramientas visuales (con frecuencia unidas en una sola herramienta) traducen lo que hace el usuario a instrucciones SQL por distintas vas:

En el caso de los 4GL, la traduccin se suele hacer mediante la compilacin.

En el caso de las herramientas visuales, se efecta por medio del intrprete de SQL integrado en el SGBD.

Si queremos escribir un programa de aplicacin que trabaje con BD, seguramente queremos utilizar nuestro lenguaje habitual de programacin. Sin embargo, generalmente estos lenguajes no tienen instrucciones para realizar el acceso a las BD. Entonces tenemos las dos opciones siguientes:

1) Las llamadas a funciones: en el mercado hay libreras de funciones especializadas en BD (por ejemplo, las libreras ODBC). Slo es preciso incluir llamadas a las funciones deseadas dentro del programa escrito con el lenguaje habitual. Las funciones sern las que se encargarn de enviar las instrucciones (generalmente en SQL) en tiempo de ejecucin al SGBD.

2) El lenguaje hospedado: otra posibilidad consiste en incluir directamente las instrucciones del lenguaje de BD en nuestro programa. Sin embargo, esto exige utilizar un precompilador especializado que acepte en nuestro lenguaje de programacin habitual las instrucciones del lenguaje de BD. Entonces se dice que este lenguaje (casi siempre SQL) es el lenguaje hospedado o incorporado (embedded), y nuestro lenguaje de programacin (Pascal, C, Cobol, etc.) es el lenguaje anfitrin (host).

1.11. Administracin de BD

Los administradores de BD son los responsables del correcto funcionamiento de la BD y velan para que siempre se mantenga til. Intervienen en situaciones problemticas o de emergencia, pero su responsabilidad fundamental es velar para que no se produzcan incidentes.

A continuacin damos una lista de tareas tpicas del ABD:

1) Mantenimiento, administracin y control de los esquemas. Comunicacin de los cambios a los usuarios.

2) Asegurar la mxima disponibilidad de los datos; por ejemplo, haciendo copias (back-ups), administrando diarios (journals o logs), reconstruyendo la BD, etc.

3) Resolucin de emergencias.

4) Vigilancia de la integridad y de la calidad de los datos.

5) Diseo fsico, estrategia de caminos de acceso y reestructuraciones.

6) Control del rendimiento y decisiones relativas a las modificaciones en los esquemas y/o en los parmetros del SGBD y del SO, para mejorarlo.

7) Normativa y asesoramiento a los programadores y a los usuarios finales sobre la utilizacin de la BD.

8) Control y administracin de la seguridad: autorizaciones, restricciones, etc.

La tarea del ABD no es sencilla.

Los SGBD del mercado procuran reducir al mnimo el volumen de estas tareas, pero en sistemas muy grandes y crticos se llega a tener grupos de ABD de ms de diez personas. Buena parte del software que acompaa el SGBD est orientado a facilitar la gran diversidad de tareas controladas por el ABD: monitores del rendimiento, monitores de la seguridad, verificadores de la consistencia entre ndices y datos, reorganizadores, gestores de las copias de seguridad, etc. La mayora de estas herramientas tienen interfaces visuales para facilitar la tarea del ABD

Ejercicios de autoevaluacin

1. Qu ventajas aportaron los SGBD relacionales con respecto a los prerrelacionales?

2. Para mejorar la disponibilidad y el coste, hemos decidido que una cierta parte de una BD que est situada en el ordenador central de la empresa estar duplicada (replicada) en un ordenador situado en una oficina alejada (conectado permanentemente por va telefnica). Los programas que actualizan la BD, tendran que preocuparse de actualizar tambin la rplica? Por qu?

3. Hemos programado una transaccin para consultar cuntos alumnos cursan una asignatura. Si este nmero es inferior a quince, se nos informar de cuntos hay y en una lista, en una hoja de papel o en la pantalla nos aparecern todos ellos. Sin embargo, si es superior o igual a quince, simplemente dir cuntos hay. Supongamos que de forma concurrente con esta transaccin se podrn estar ejecutando otras que inserten nuevos alumnos o que los supriman. Qu problema se podr producir si el SGBD no asla totalmente las transacciones?

4. De las siguientes afirmaciones, decid cules son ciertas y cules son falsas:

a) El modelo ER es ms conocido como modelo relacional.

b) Los SGBD no permiten la redundancia.

c) El DML es un lenguaje declarativo.

d) El DDL es un lenguaje pensado para escribir programas de consulta y actualizacin de BD.

e) En un ordenador que acta como servidor de BD, con dos RAID y tres discos duros y con un SGBD actual, no es necesario que los encargados de realizar los programas para consultar esta BD sepan en qu discos est.

f) Cuando un programa quiere acceder a unos datos mediante un ndice, lo debe decir al SGBD

II. MODEOS DE DATOS

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:

Por ejemplo

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

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

Por ejemplo

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

III. MODELO ENTIDAD RELACION

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

3 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

IV. MODELO RELACIONAL

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 tupl