BASES DE DATOS I

GUA DEL ALUMNO

SECRETARA DE EDUCACIN PBLICA SUBSECRETARA DE EDUCACIN SUPERIOR E INVESTIGACIN CIENTFICA SUBSISTEMA DE UNIVERSIDADES TECNOLGICAS COORDINACIN GENERAL DE UNIVERSIDADES TECNOLGICAS
ELABOR: (GRUPO DE DIRECTORES DE LA CARRERA DE INFORMATICA) REVIS: FECHA DE ENTRADA EN VIGOR: (COMISIN ACADMICA NACIONAL DEL REA ....................)

APROB:

COORDINACIN GENERAL DE UNIVERSIDADES TECNOLGICAS

SEPTIEMBRE 2001

I. DIRECTORIO (Anotar el nombre del funcionario actual) SECRETARO DE EDUCACIN PBLICA (Anotar el nombre del funcionario actual) SUBSECRETARIO DE EDUCACIN SUPERIOR E INVESTIGACIN CIENTFICA DR. ARTURO NAVA JAIMES COORDINADOR GENERAL DE UNIVERSIDADES TECNOLGICAS RECONOCIMIENTOS

(NOMBRE DE LA SIGNATURA) D.R. 20001 ESTA OBRA, SUS CARACTERSTICAS Y DERECHOS SON PROPIEDAD DE LA: COORDINACIN GENERAL DE UNIVERSIDADES TECNOLGICAS (CGUT) FRANCISCO PETRARCA No. 321, COL. CHAPULTEPEC MORALES, MXICO D.F. LOS DERECHOS DE PUBLICACIN PERTENECEN A LA CGUT. QUEDA PROHIBIDA SU REPRODUCCIN PARCIAL O TOTAL POR CUALQUIER MEDIO, SIN AUTORIZACIN PREVIA Y POR ESCRITO DEL TITULAR DE LOS DERECHOS. ISBN (EN TRMITE) IMPRESO EN MXICO.

NDICE

# I. II. III. IV.

CONTENIDO DIRECTORIO Y RECONOCIMIENTOS NDICE INTRODUCCIN DE LA ASIGNATURA UNIDADES TEMTICAS UNIDAD I. GENERALIDADES UNIDAD II. MODELO DE BASES DE DATOS UNIDAD III. MODELO RELACIONAL UNIDAD IV. LGEBRA RELACIONAL UNIDAD V. NORMALIZACIN UNIDAD VI. FUNDAMENTOS PARA EL DISEO DE BASES DE DATOS UNIDAD VII. ACCESO A DATOS.

PAGINA 2 3 4

V. VI. VII.

REFERENCIAS GLOSARIO ANEXOS

UNIDAD I

INTRODUCCION

I. II. III. IV. V. VI. VII. VIII. IX. X.

Objetivos de los sistemas de Base de Datos Abstraccin de datos Modelo de datos Independencia de datos Lenguaje de definicin de datos Lenguaje de manipulacin de datos Manejador de Base de Datos Administrador de Base de Datos Usuarios de Base de Datos Estructura global de sistema MODELO ENTIDAD RELACION

UNIDAD II I. II. III. IV. V. VI. VII. VIII.

Entidades Relaciones Atributos Restricciones Claves Diagramas entidad relacin Reduccin de los diagramas entidad relacin a tablas Diseo de un esquema de Base de Datos entidad relacin

UNIDAD III MODELO RELACION I. II. III. IV. V. Estructura de Base de Datos relacionales Algebra relacional Clculo de tuplas Modificacin de las Bases de Datos Vistas UNIDAD IV RESTRICCIONES DE INTEGRIDAD I. Restricciones de dominio II. Integridad referencial III. Dependencias funcionales IV. Restricciones lgicas UNIDAD V DISEO RELACIONALES I. II. III. DE BASE DE DATOS

Peligros en las Bases de Datos relacionales Normalizacin Diseo fsico

UNIDAD VI LENGUAJES RELACIONALES COMERCIALES

I. II. III.

Ejemplos de lenguajes relacionales comerciales SQL QBS

Unidad I Generalidades
SISTEMAS DE BASE DE DATOS Definicin Los sistemas de bases de datos son esencialmente sistemas computarizados para guardar informacin. La base de datos puede ser vista como un gabinete electrnico de archivos, es decir, un depsito para coleccionar archivos de datos computarizados. Los usuarios del sistema se le dan facilidades para desarrollar una serie de operaciones en tales archivos entre los que se encuentran los siguientes:

Agregar nuevos archivos a la base de datos Insertar nuevos datos a los archivos existentes Consultar datos de los archivos existentes Actualizar datos de los archivos existentes Borrar datos de los archivos existentes Eliminar archivos existentes de la base de datos

I. Objetivos de los sistemas de la Base de Datos Una vez visto lo que es un sistema de base de datos, es primordial saber para que sirve este sistema, es decir, cual es el objeto o propsito de que existan Sistemas de Base de Datos.

Uno de los objetivos de los sistemas de base de datos es dar mantenimiento a la informacin y hacerla accesible en un momento dado. La informacin en cuestin puede ser cualquier cosa que se considere de significado a los individuos o a las organizaciones.

Componentes

La base de datos.- Coleccin integrada de datos almacenados ms o menos permanentemente. El Hardware.- Donde los datos estn residentes. El Software.- Controla el almacenamiento y salida de datos. El Usuario.- Interpretan los datos.
Base de Datos

Una base de datos es una coleccin de datos almacenados y usados por los sistemas de aplicacin de alguna Corporacin, Empresa, Institucin, Individuo etc.
Hardware

El hardware cosiste en los volmenes de almacenamiento secundario. Tpicamente los discos es donde reside fsicamente la base de datos. Los problemas encontrados en esta rea no son considerados como problemas de los sistemas de base de datos sino son competencia del rea de electrnica. En el hardware se analizan loas tcnicas para la organizacin fsica de la base de datos, las cuales no se vern en el curso. Cabe mencionar que existen las mquinas de base de datos, es decir, mquinas especialmente diseadas para manejar Sistemas de Base de Datos.
Software

Entre la base de datos fsica y los usuarios del sistema esta una capa de software. El software del sistema de Base de Datos tambin denominado Sistema Manejador de Base de Datos (Data Base Management System, DBMS) tiene como propsito fundamental permitir al usuario tener relacin con los datos en trminos abstractos. En este sentido, el DBMS acta como un interprete, permite al usurario identificar lo que debe hacer con poco o ninguna atencin en la presentacin de los datos en el mbito de hardware. El DBMS es algn software existente ms complejo y la manera de sentir sus diferentes aspectos es considerar los varios tipos de usuarios que interactuan con l.

Usuario

Son las personas que interpretan los datos y los hay de acuerdo a sus funciones. Este punto es tan importante que se le ha dado un apartado mas adelante.
Ventajas

Las siguientes son las ventajas ms importante de los Sistemas de Base de Datos: Reduce la Redundancia Evita la Inconsistencia Mantiene la Integridad Comparte los datos Aplica restricciones de seguridad Provee Independencia de Datos

Reduccin de redundancia

Como contraste, en los sistemas convencionales de procesamiento de datos, cada aplicacin mantiene sus propios archivos, a menudo con una considerable redundancia (repeticin de los mismos datos) y con altas posibilidades de que stos datos no concuerden. En sistemas de base de datos se reduce considerablemente la redundancia integrando archivos separados. Por otro lado, no se sugiere que toda la redundancia deba ser necesariamente eliminada. Algunas veces, existen razones tcnicas para mantener mltiples copias de los mismo datos almacenados, sin embargo, toda esta redundancia debe ser cuidadosamente controlada.
Evitacin en la Inconsistencia

Esto es realmente un corolario del punto anterior. Reduciendo la redundancia hay pocas oportunidades que dos entradas no concuerden. En claro que una base de datos en estado inconsistente es capaz de proporcionar informacin incorrecta o conflictiva a sus usuarios.
Mantiene la Integridad

Por integridad se entiende como la unificacin de varios archivos en una base de datos con toda o parcialmente eliminada la redundancia. El problema de integridad de los datos es un problema que tiene que ver con que los datos sean exactos. La inconsistencia de dos entradas que representan el

mismo hecho es un ejemplo de fallas en la integridad. Por supuesto, este problema en particular existe porque hay redundancia. Aun si en la redundancia no existiese, la base de datos podra tener informacin incorrecta, por ejemplo, que un empleado tenga 400 horas de trabajo a la semana en vez de 40. Vale la pena apuntar que la integridad de los datos ms importante en un sistema multiusuario, precisamente porque los datos son compartidos. Sin controles apropiados, sera posible que un usuario actualizase la base de datos incorrectamente y por lo tanto generara datos annimos y as afectar a otros usuarios (inocentes).
Comparticin de Datos

Compartir los datos es uno de los beneficios ms importantes de los sistemas de base de Datos, por compartir los datos se entiende que pedazos de una base de datos pueden ser compartidos por varios usuarios diferentes. Por lo general cada usuario la usa para propsitos diferentes. Aun ms, los diferentes usuarios podran accesar el mismo pedazo al mismo tiempo. Esto se le conoce como acceso concurrente, (en sistemas multiusuario, pro supuesto). Tal compartimento de datos se debe al hecho de que la base de datos esta integrada.
Aplica Restricciones de Seguridad

La seguridad es un caso intrigante en Sistemas de Base de Datos. Los datos estn ms en peligro porque estn coleccionados en un lugar central ms que dispersos en diferentes lugares. Tomando esto en cuenta, los sistemas de Base de Datos han sido diseados con controles sofisticados.
Provisin de Independencia de Datos

Estrictamente hablando ste es el objeto de los Sistemas de Base de Datos ms que las ventajas antes mencionadas. Este concepto es tan importante que se le ha dedicado un apartado por separado ms adelante. Inmunidad de las aplicaciones a los cambios almacenamiento y las estrategias de almacenamiento. Independencia lgica de datos. Independencia fsica de datos. II. ABSTRACCION DE DATOS Debe ser obvio que entre la computadora que ve los bits y el usuario final que maneja la abstraccin existen varios niveles de abstraccin. La siguiente figura muestra los tres diferentes niveles de abstraccin de un base de datos. Debe enfatizarse que solamente la base de datos fsica existe. en las estructuras de

Vista 1

Vista 2

Vista n

Nivel Conceptual

Nivel Fsico

Los tres niveles de datos abstractos

La base de datos fsica reside permanentemente en almacenamiento secundario y puede vrsele en varios niveles de abstraccin que van desde los registros y archivos lgicos hasta los bits y las direcciones fsicas de los dispositivos de almacenamiento secundario. La base de datos conceptual es una abstraccin del mundo real. El DBMS provee un lenguaje de definicin de datos que especfica el esquema conceptual de la base de datos, ste lenguaje de alto nivel hace posible que se describa la base de datos conceptual en trminos de un Modelo de Datos. Una vista o subesquema es un modelo abstracto de una porcin de la base de datos conceptual. Muchos de los DBMS proveen un lenguaje para declarar vistas y otro para la consulta y operaciones de las vistas. Hay ocasiones en que las vistas pueden estar a un nivel ms abstracto, es decir, estar construidas de los datos de la base de datos conceptual pero que no existen. Por ejemplo, en una vista esta la edad de las personas y en la base de datos conceptual esta la fecha actual y la fecha de nacimiento. III. MODELO DE DATOS El modelo de datos es un grupo de herramientas conceptuales para describir datos, sus relaciones, su semntica y sus limitantes. Se han propuesto varios modelos de datos diferentes, los cuales pueden dividirse en tres grupos: Modelo lgico basado en objetos Modelo lgico basado en registros

Modelos fsicos de datos

Antes de mencionar algunas caractersticas de estos modelos es menester aclarar que un modelo de datos consiste de dos elementos: Una notacin matemtica para expresar los datos Operaciones en los datos para expresar consultas

Modelo lgico basado en objetos

Estos modelos se utilizan para describir los datos en los niveles conceptuales y de vistas. Se caracterizan por el hecho de que perciben una estructura bastante flexible y hacen posible especificar claramente las limitantes de los datos. Algunos de estos modelos son: Modelo Entidad Relacin Modelo Binario Modelo Semntico de Datos Modelo Infolgico

Se ha escogido el modelo entidad relacin para su estudio dado a que primero hace una percepcin adecuada, aunque imperfecta, de las situaciones del mundo real. Segundo, porque es bastante apropiado para el diseo de base de datos y tercero porque sirve para justificar los tipos de estructuras de datos y los modelos ms ampliamente usados.

Modelos lgicos basados en registros

Los modelos lgicos basados en registros se utilizan para describir los datos en los niveles conceptual y de vistas. A diferencia de los basados en objetos, stos modelos sirven para especificar tanto la estructura lgica general de la base de datos como una descripcin en un nivel ms alto de la implementacin. Sin embargo, no permiten especificar en forma clara las limitantes de los datos. Los modelos de esta divisin ms ampliamente aceptados son: Modelo jerrquico.- Un registro hijo tiene un registro padre. Modelo de red.- Un registro hijo tiene mas de un registro padre. Modelo relacional.- Se basa en relaciones.

A continuacin se muestran los diferentes modelos de datos con la misma base de datos: Nombre Direccin Ciudad Numero

Lowery Shiver Shiver Hodges Hodges

Maple North North Sidehill Sidehill Numero 900 556 647 801

Queens Bronx Bronx Brooklyn Brooklyn

900 556 647 801 647

Balance 55 100000 105366 10533

Lowery Queens

Maple

Hodges

Sidehill Brooklyn

Shiver North

Bronx

556 100000

647 105 366

900 55

647

105 366

801 10 533

Lowery Ejemplo Jerrquico de base de 900 Maple Queens datos 556 Shiver North Bronx 647 Hodges Sidehill Brooklyn 801

55
100000 15366 10533

Ejemplo de la relacin entre la Base de Datos De stos modelos de datos se han generado las bases de datos correspondientes, as por ejemplo, una BD relacional o sistema relacional o bien sistema relacional de base de datos o sistema de base de datos relacional es aquella en que sus datos estn representados por el modelo relacional. A continuacin se menciona algunos sistemas de Base de datos de acuerdo al tipo de modelo de datos que manejan: Modelo Relacional Sistema Fox Pro Clipper Informix DB2 SQL/DS INGRES ORACLE Rdb/VMS IMS System 2000 IDMS DMS 1100 TOTAL Vendedor IBM IBM Relation Tech. Inc. Oracle Corp. DEC IBM Intel IBM Sperry Cincom Systems

Jerrquico Red

El modelo relacional se estudiar dada su gran versatilidad para implementar sistemas de base de datos, adems de ofrecer mucho ms ventajas que los otros dos modelos.
Modelo fsico de datos

Los modelos fsicos de datos sirven para descubrir los datos en el nivel ms bajo. A diferencia de los modelos lgicos son muy pocos los utilizados. Los ms conocidos son: Modelo unificador Modelo de cuadros

Los modelos fsicos de datos capturan aspectos de la implantacin de los sistemas de base de datos, los cuales no es tema de estudio.

INSTANCIAS Y ESQUEMAS Adems de las gradaciones en los niveles de abstraccin mostrada en la figura respectiva, hay otra dimensin ortogonal de percibir las bases de datos. Cuando la base de datos es diseada, se esta interesado en los planes o esquemas, pero cuando se usa, nos concierne con los datos actuales. De aqu resalta que los valores de los datos cambian frecuentemente mientras que los planes permanecen igual por un perodo grande. El contenido corriente de la base de datos se le llamar una instancia de la base de datos, tambin se le conoce como extensin como estado. Los planes consisten de una enumeracin de los tipos de entidades, as como de las relaciones que guardan entre s. A stos planes se le llama esquema. De esta manera se habla del esquema conceptual para referirse a la base de datos conceptual y esquema fsico para la base de datos fsica. Los planes para una visita, simplemente se le llama subesquema. Algunas veces al trmino esquema se le denomina intensin. IV. INDEPENDENCIA DE DATOS El encadenamiento de los niveles de abstraccin de la figura respectiva produce dos niveles de independencia de datos. En un sistema de base de datos bien diseado, el esquema fsico puede ser cambiado por el Administrador de la base de datos sin alterar el esquema conceptual o bien redefinir los subesquemas. A sta independencia se le llama independencia fsica de datos. Debe resaltarse que las modificaciones al esquema fsico afecta la eficiencia de los programas de aplicacin, pero nunca a reescribirlos. La relacin entre las vistas y la base de datos conceptual tambin provee un tipo de independencia llamado independencia lgica de datos. Muchas modificaciones al esquema conceptual pueden ser hechas sin afectar los subesquemas existentes, pero otras si. Una vez ms ningn cambio en la base de datos conceptual debe reflejarse en la definicin de los programas de aplicacin. El nico cambio que podra redefinir los programas sera la eliminacin de informacin en le esquema conceptual. Inmunidad de las aplicaciones a los cambios almacenamiento y las estrategias de acceso. en las estructuras de

V. LENGUAJE DE DEFINICIN DE DATOS Un esquema de Base de Datos se especifica por medio de un conjunto de definiciones que se expresen mediante un lenguaje especial lenguaje de

definicin de datos (data definition language (DDL)). El resultado de la compilacin de sentencias de DDL es un conjunto de tablas Las cuales se almacenan en un archivo especial llamado diccionario de datos (o directorio). Un directorio de datos es un archivo que contiene metadatos, es decir, <<datos sobre datos>> .Este archivo se consulta antes de leer o modificar los datos reales en el sistema de la base de Datos. La estructura de almacenamiento y los mtodos de acceso usados por los sistemas de la base de datos se especifican por medio de un conjunto de definiciones en un tipo especial DDL llamado lenguaje de almacenamiento y definicin de datos. El resultado de la compilacin de esta definiciones es un conjunto de instrucciones que especifican los detalles de la implementacin de los esquemas de la base de datos que normalmente se esconden a los usuarios.

LENGUAJE DE BASE DE DATOS En los lenguajes de programacin ordinarios, las declaraciones y los comandos de ejecucin son todos parte del mismo lenguaje. En el mundo de las bases de datos es normal separar las dos funciones en dos lenguajes. El motivo es que mientras en un programa ordinario las variables existen solamente para cuando el programa se esta ejecutando y en un sistema de base de datos los datos existen siempre. Estos datos deben ser declarados una vez y para todos los usuarios. Como se menciono anteriormente, el esquema conceptual es especificado en un lenguaje provisto como parte del DBMS llamado lenguaje de definicin de datos (Data Definition Language, DDL). Este lenguaje no es de procedimientos ms si notacin y sirve para describir los tipos de entidades y sus relaciones en trminos de un modelo de datos en particular. El lenguaje de definicin de datos es usado cuando las bases de datos son diseadas y cuando ese diseo es modificado. No es usada para obtener o modificar los datos. El diseo detallado de la base de datos fsica es hecho por las rutinas del DBMS que compila sus instrucciones. La descripcin de subesquema y su correspondencia al esquema conceptual requiere de un lenguaje de definicin de datos para subesquemas, el cual es muy similar al lenguaje de definicin de datos.
La manipulacin de la base de datos requiere un lenguaje especializado llamado lenguaje de manejo de datos (Data Manegemente Language, , DML), o lenguaje de consulta.

Es usual que los programas de aplicacin hagan ms que manipular la base de datos; hacen tareas de clculo. Por ejemplo, un programa de aplicacin que haga reservaciones debe desplegar y leer determinada informacin, hacer decisiones y

operaciones (Hay vacantes?, Reservado igual al reservado menos uno). Por tal motivo, un programa de aplicacin es escrito en un lenguaje convencional como C y se le denomina lenguaje host.

VI. LENGUAJE DE MANIPULACIN DE DATOS Por manipulacin de datos queremos decir: La La La La recuperacin de informacin almacenada en la base de datos. insercin de informacin nueva a la base de datos supresin de informacin de la base de datos modificacin de datos almacenados en la base de datos

A nivel fisico debemos definir algoritmos que permitan acceso eficiente a los datos, en los niveles de abstraccin ms altos, se pone nfasis en la facilidad de uso. El objetivo es proporcionar una interaccin eficiente entre Las personas y el sistema. Un lenguaje de manipulacin de datos (data manipulation language (DML)) es un lenguaje que capacita a los usuarios a acceder o manipular datos segn esten organizados por el modelo de datos adecuado. Existen bsicamente dos tipos: Procedimentales, los DML requieren que el usuario especifique que datos se necesitan y como obtenerlos. No procedimentales, los DML requieren que el usuario especifique qu datos se necesitan sin especificar com obtenerlos. VII.MANEJADOR DE BASE DE DATOS El manejador de base de datos es un programa que provee la interfaces entre el nivel bajo de los datos (base de datos fsica) y los programas de aplicacin o con las consultas sometidas al sistema. El manejador tiene las siguientes tareas: Interaccin con el manejador de archivos Imposicin de la integridad Imposicin de la seguridad Respaldo y recuperacin Control de concurrencia

Interaccin con el manejador de archivos

Los datos como tales estn almacenados en disco y con accesados por medio del sistema de archivos el cual es provisto por el sistema de archivos el cual es provisto por el sistema operativo. EL manejador de base de datos traduce las instrucciones del DML en comandos del sistema de archivos.
Imposicin de integridad

Los valores de los datos almacenados en la base de datos deben satisfacer ciertos requerimientos de consistencia. El manejador de base de datos determinar si las actualizaciones desobedecen las restricciones impuestas, si es as, tomar decisiones apropiadas. Por ejemplo, tratar de poner 400 horas de trabajo a la semana en vez de 40.
Imposicin de la seguridad

No todos los usuarios deben tener acceso al contenido total de la base de datos. El manejador de base de datos debe imponer estos requerimientos de seguridad.
Respaldos y recuperacin El sistema de cmputo como cualquier otro elemento mecnico o elctrico, est propenso a tener fallas. Fallas como crash en los discos, falta de energa elctrica, errores de software entre otros. En tales casos, la informacin de la base de datos se pierde y es por ello que el manejador de base de datos tiene la responsabilidad de detectar tales fallas y restablecer la base de datos al estado que exista antes de ocurrir la falla. Control de concurrencia

Cuando varios usuarios actualizan la base de datos concurrentemente, la consistencia de los datos puede no preservarse. Es responsabilidad del manejador de la base de datos controlar la interaccin entre los usuarios y concurrentes.
VIII. Administrador de la base de datos

La tercera clase de usuario es el administrador de la base de datos (Data Base Administrator, DBA). La estructura o descripcin de la base de datos son rara vez cambiados, es decir, el programa que describe la base de datos es modificado y recompilado reemplazando de esta manera la vieja descripcin. El programa en cuestin esta escrito en lenguaje propio del DBMS denominado Lenguaje de Definicin de Datos (Data Definition Language, DDL). Esta operacin no es frecuente pero es muy importante y una persona de alto nivel se le confiere la responsabilidad para todos los asuntos que tienen que ver con la base de datos.

Algunas de las responsabilidades del DBA o su staff son las siguientes:

La creacin de la descripcin original de la estructura de la base de datos y la manera en que esa estructura es reflejada por los archivos de la base de datos fsica.

La autorizacin a varios usuarios para accesar la base de datos o parte de ella. Modificacin de la descripcin de la base de datos o sus relacin con la organizacin fsica de a base de datos. Realizar respaldos de la base de datos y reparar los daos a la base de datos debido a fallas del hardware, del software o del mal uso.

Es importante resaltar que la posicin del DBA dentro de la corporacin es o debe ser de nivel directivo a que debe tener la habilidad de interpretar los requerimientos de la Alta Direccin. IX. USUARIOS DE LA BASE DE DATOS Se consideran tres clases amplias de usuarios: Programador de aplicaciones Usuarios finales Administrador de la base de datos.

Programador de aplicaciones

El usuario, programador de aplicaciones es el responsable de escribir y mantener programas de aplicacin que usan las bases de datos. Estos programas estn escritos en un lenguaje propio del DBMS denominados lenguajes de manejo de datos (Data Management Language, DML), o bien algn lenguaje host. Estos programas operan con el contenido de la base de datos en forma de consulta, insercin, eliminacin o cambio. Estos programas almacenados en el sistema de archivos y compilados son invocados por comandos y pueden ser de tipo batch que son los convencionales o de tipo en lnea que estn disponibles en terminales en lnea.
Usuarios finales

Los usuarios finales se han clasificado en dos tipos:

1. Usuarios inexpertos 2. Usuarios expertos

Usuarios inexpertos

Son usuarios que no tienen una capacitacin formal de computacin. El usuario inexperto tiene acceso a la base de datos por medio de un programa de aplicacin, escrito por un programador de aplicaciones o bien mediante interfaces de manejo de mens o de formas (programas de aplicacin preconstruidos) cuya operacin es mediante selecciones de un men o poniendo opciones en una forma. Estas interfaces son parte del DBMS. La interfaces ASSIST del DBASE es un ejemplo de interfaces de manejo de mens.
Usuarios expertos

Son usuarios que tiene cierta experiencia computacional, obviamente mucho menos que un programador de aplicaciones. A estos usuarios tambin se les conoce como usuarios sofisticados y algunas veces se le llama usuarios especializados cuando manejan un tema especfico. El usuario experto accesa la base de datos va una interfase de manejo de comandos (programa de aplicacin preconstruidos) tambin conocidos como Procesador de Lenguaje de Consulta Interactivo o simplemente Lenguaje de Consulta Estructurado (Structure Query Languaje, SQL) es un ejemplo tpico de un lenguaje de consulta. La interfase de manejo de comandos es ms flexible que la interfase de manejo de mens o de formas. X. ESTRUCTURA GLOBAL DEL SISTEMA Un sistema de base de datos esta particionado en mdulos que tiene que ver con cada una de las responsabilidades de todo el sistema. En la mayora de los casos, el sistema operativo provee solamente los servicios bsicos y el sistema de base de datos debe construirse sobre sta base. As, el diseo de un sistema de base de datos debe incluir consideraciones de interfase entre el sistema de base de datos y el sistema operativo.
Los componentes funcionales de un sistema de base de datos incluye:

Manejador de archivos Manejador de base de datos Procesador de consultas Precompilador DML

Compilador DDL

Usuario final Inexperto Interfaces de Aplicacin

Programador de Aplicaciones Programas de Aplicacin

Usuario Final Experto Consultas (Query)

Administrador de la Base de Datos Esquema de Base de Datos

Precopilador Lenguaje de Manipulacin de datos (DML)

Procesador de Consultas

Compilador Lenguaje de Definicin de DBMS Datos (DDL)

Cdigo Objeto Programa(s) Aplicacin

Manejador Gestor de B.D

S.O

Manejador (gestor) de Archivos

Archivos de datos

Diccionario de datos

UNIDAD II MODELO ENTIDAD-RELACION El modelo de datos entidad relacin (E-R) se basa en una percepcin del mundo real el cual consiste de un conjunto de objetos bsicos llamados entidades y relaciones de facilitar el diseo de base de datos permitiendo as la especificacin del esquema de la empresa o corporacin. Tal esquema representa la estructura lgica general de la base de datos. I. ENTIDADES
Entidades y Conjunto de Entidades

Una entidad es una cosa u objeto que existe y es distinguible. Por ejemplo, una silla es una entidad, de tal modo lo es cada persona, cada automvil. No prodriamos considerar a una hormiga como una entidad a menos que tuviramos una manera de distinguirla de las dems. Las entidades pueden ser abstractas de modo que conceptos como el amor y el odio son entidades. Un grupo similar (del mismo tipo) de entidades forman un conjunto de entidades. Ejemplos de conjuntos de entidades son: todas las personas, todos los automviles, todas las emociones. Una entidad es representada por un conjunto de atributos, por ejemplo, el conjunto de atributos del conjunto de entidades Clientes podran ser nombre_cliente, no_seguro_social, domicilio y ciudad_cliente. Otro ejemplo, posibles atributos del conjunto de entidades Cuentas, seran no_cuenta y saldo. Para cada atributo hay un conjunto de valores permitidos llamados dominios del atributo. El dominio del atributo nombre_cliente podra ser el conjunto de todas las cadenas de tipo texto de cierta longitud. Similarmente, el dominio del atributo no_cuenta podra ser el conjunto de todos los nmeros enteros positivos. En este capitulo trabajaremos con cinco conjuntos de entidades los cueles conformarn parte de la base de datos en un banco: Sucursal.- conjunto de todas las sucursales de un banco en particular. Cliente.- conjunto de todas las personas que tienen una cuenta en el banco. Empleado.- conjunto de todas las personas que trabajan en el banco. Cuenta.- conjunto de todas las cuentas del banco. Transaccin.- conjunto de todas las transacciones ejecutadas en el banco.

Cada uno con los siguientes atributos:

Sucursal (sucursal_nombre, sucursal_ciudad, bienes) Cliente (cliente_nombre, social_seguro) Empleado (empleado_nombre, telefono_numero) Cuenta (cuenta_numero, balance) Transaccin (transaccin_numero, fecha, cantidad) II.RELACIONES Relaciones y Conjunto de Relaciones
Una relacin es una asociacin entre varias entidades. Por ejemplo, se podra definir la relacin que asocie el cliente Harris con la cuenta 401. Esta relacin especfica que Harris es un cliente con la cuenta bancaria 401. Un conjunto de relaciones es un conjunto de relaciones del mismo tipo. Considrese por ejemplo, dos conjuntos de entidades Cliente y Cuenta, el conjunto de relaciones ClieCuen denotar la asociacin entre los clientes que tienen cuentas bancarias. El conjunto de relaciones ClieCuen es un ejemplo de conjunto de relaciones binarias, es decir, relaciones que involucran dos conjuntos de entidades. La mayora de los conjuntos de relaciones en un sistema de base de datos son binarias, ms sin embargo, tambin hay conjuntos de relaciones que involucran ms de dos conjuntos de entidades. La funcin que una entidad juega en una relacin es llamada su rol. Los roles son normalmente implcitos y no son normalmente especificados. Sin embargo, ellos son tiles cuando el significado de una relacin necesita de claridad. Por ejemplo, el conjunto trabajo_para podra relacionar pares ordenados de las dos entidades empleado. El primer empleado del par toma el rol de gerente mientras que el segundo tima el rol de trabajador. De esta manera, todas la relaciones del conjunto trabajo_para estn caracterizadas por el par ordenado (gerente,trabajador), el par (trabajador,gerente) se excluye. Una relacin tambin puede tener atributos descriptivos. Por ejemplo, date podra ser un atributo del conjunto de relaciones ClieCuen el cual especificara la ltima fecha en el cliente acceso la cuenta. III. Atributos Dado a que la nocin de conjunto de entidades y conjunto de relaciones no est precisa, es posible definir el conjunto de entidades y las relaciones entre las entidades de diferentes maneras. La principal diferencia es la manera de tratar los atributos. Considera el conjunto de entidades empleado con los atributos empleado_nombre y telfono_numero. Se puede argumentar fcilmente que un telfono es aun entidad en su propia concepcin con atributos telfono_numero y localizacin (lugar donde se encuentra el telfono dentro de la oficina). Si se tomase ste punto de vista, el conjunto de entidades empleado debera redefinirse como: Empleado.- Conjunto de entidades con atributo Empleado_nombre. Telfono.- Conjunto de entidades con atributos Telfono_numero y localizacin. EmpPhn.- Conjunto de relaciones que denota la asociacin entre empleados y los telfonos que ellos tienen.

Entonces, cul es la principal diferencia entre estas dos definiciones? En la primera, la definicin implica que dad empleado tienen precisamente un solo numero telefnico. En el segn establece que un empleado puede tener varios nmeros telefnicos definicin es ms general que la primera y puede reflejar ms precisamente una situacin del mundo real. Aun ms, si diramos un nmero telefnico a un empleado, la segunda definicin sera ms apropiada si el telfono a un empleado, la segunda definicin ser ms apropiada si el telfono es compartido por varios empleados. Por lo tanto, surge una pregunta Qu constituye un atributo y qu constituye un conjunto de entidades? Desgraciadamente, no hay una respuesta sencilla, la diferencia principal depende de la estructura de la empresa a ser modelada y semntica asociada a los atributos. IV.RESTRICCIONES Restricciones de asignacin (MAPPING) Limitantes de mapeo En un diagrama E-R se definen ciertas limitantes, las cuales la base de datos debe de contener. La primera es la cardinalidad de mapeo que expresa el nmero de entidades que pueden asociarse con otro conjunto de entidades va un conjunto de relaciones.

La cardinalidad de mapeo se efecta en conjunto de relaciones binarias y son: Una a Una Una entidad del conjunto de entidades A est asociada con a lo ms una entidad del conjunto de entidades B, y una entidad del conjunto B est asociada con a lo ms una entidad de A.

Una a Muchas Una entidad de A est asociada con cualquier numero de entidades de B. Una entidad de B, sin embargo, est asociada con a lo ms una entidad en A. Muchas a Una Una entidad de A est asociada con a lo ms de una entidad en B. Una entidad en B, sin embargo, est asociada con cualquier nmero de entidades de A. Muchas a Muchas Una entidad A est asociada con cualquier nmero de entidades de B, y una entidad de B est asociada con cualquier nmero de entidades de A.

Para ilustrar esto, considrese el conjunto de relaciones ClieCuen, sin una cuenta puede solamente pertenecer a un solo cliente y un cliente puede tener varias cuentas, entonces el conjunto de relaciones es una a muchas de cliente a cuenta. El segundo tipo de limitantes es la dependencia de existencia que especfica, si la existencia de una entidad x depende de la existencia de la entidad y, entonces x tiene dependencia de existencia de y. Operacionalmente significa que si y es eliminada entonces tambin lo debe ser x. La entidad y se dice que es entidad dominante y x es entidad subordinada. Para ilustrar lo anterior, considrese los conjuntos de entidades cuenta y transaccin, formes el conjunto de relaciones log que especifique que para una cuenta en particular existen varias transacciones. Esta relacin es una a muchas de cuenta a transaccin. Cada entidad de

transaccin debe estar asociada con una entidad de cuenta. Si una cuenta es eliminada, entonces todas las transacciones asociadas a ella tambin deben ser eliminadas. En contraste, las entidades transacciones pueden eliminarse sin afectar cualquier cuenta. V. CLAVES Llaves Es importante ser capaz de especificar como las entidades y las relaciones son distinguibles. Conceptualmente, las entidades y relaciones individuales son distinguibles, pero desde la perspectiva de base de datos, la diferencia entre las entidades o entre relaciones se expresa en trminos de sus atributos los cuales tomados colectivamente nos permite identificar unvocamente cada entidad del conjunto de entidades. Por ejemplo, el atributo social_seguro es una superllave. De igual manera lo es la combinacin de cliente_nombre y social_seguro. Cliente_nombre no puede ser seperllave dado a que hay varios clientes con el mismo nombre. El concepto de superllave no es suficiente porque como se vio en el prrafo anterior, una superllave puede tener atributos extraos (adicionales). Si K es una superllave, entonces lo es cualquier superconjunto de K. Se est interesando en superllaves en las que no hay subconjuntos que sean llaves. A tales superllaves mnimo son llamadas llaves candidato. Se llamar llave primaria a la llave candidato que el diseador de la base de datos escoja como medio de identificar las entidades. Es posible que una entidad no tenga los suficientes atributos para conformar la llave primaria. A tales conjuntos de entidades se les denomina conjunto de entidades dbiles. A un conjunto de entidades que tiene llave primaria se le llama conjunto de entidades fuertes. Para ilustrar esto, considrese el conjunto de entidades transaccin con sus tres atributos, aunque cada transaccin es distinta, transacciones en cuentas diferentes pueden compartir el mismo nmero de transaccin. De este modo, transaccin no tiene llave primaria y es un conjunto de relaciones una a muchas. Se sugiere que sta relacin no deba tener atributos descriptivos, ya que cualquier atributo requerido podra ser asociado al conjunto de entidades dbiles. Aunque el conjunto de entidades dbiles no tiene llave primaria, se necesita un medio de distinguir cada entidad. El discriminador de un conjunto de entidades dbiles es el conjunto de atributos que identifica unvocamente a cada entidad de ste conjunto. Por ejemplo, del conjunto de entidades transaccin, el discriminador es el atributo transaccin_numero dado a que hay un slo nmero de transaccin para cada transaccin. Para conformar la llave primara del conjunto de relaciones se toman las llaves primarias de los conjuntos de entidades que asocia si la semntica de los atributos descriptivos del conjunto de relaciones lo amerita se toman en cuenta tambin. El total de atributos del conjunto de relaciones se forma de la unin de los atributos descriptivos de las relaciones y las llaves primarias de los conjuntos de entidades que asocia. Para ilustrar lo anterior, considrdese el conjunto de relaciones ClieCuen tiene como atributo social_seguro, la llave primaria de cliente, cuenta_numero, la llave primaria de cuenta y el atributo descriptivo date. La llave primaria de este conjunto de relaciones eta conformado por el conjunto de atributos (social_seguro, cuenta_numero). VI. Diagramas Entidad-Relacin Como se vio en el capitulo uno, toda la estructura lgica de la base de datos puede ser expresada por un diagrama E-R. El diagrama E-R consiste de los siguientes componentes: Rectngulos.Representan conjunto de entidad

Elipse.Diamante.Lneas.-

Representa atributos Representa conjunto de relaciones Une atributos a los conjuntos de entidades y conjuntos de relaciones. Tambin une conjuntos de entidades con conjunto de relaciones.

Vase el siguiente diagrama E-R, muestra dos conjuntos de entidades, un conjunto de relaciones y sus respectivos atributos.

Direcci Seguro Social Nombre del Cliente Ciudad del Cliente

Fech

Numero de Cuenta Balance

Ciente

ClieCue

Cuenta

El conjunto de relaciones ClieCuen puede ser muchas a muchas, una a muchas, muchas a una o una a una. Para distinguir entre stas, debe dibujarse una lnea dirigida cuando hay participacin en uno y se dibujo una lnea no dirigida cuando hay participacin de muchas. Vase los siguientes figuras donde se indica lo anterior.
Direcci Seguro Social Nombre del Cliente Ciudad del Cliente Fecha Numero de Cuenta

Balanc

Ciente

ClieCue
(a)

Cuenta

Direcci Seguro Social Nombre del Cliente Ciudad del Cliente

Fech

Numero de Cuenta

Balance

Ciente

ClieCue

Cuenta

(b)
Direcci Seguro Social Nombre del Cliente Ciudad del Cliente Fech Numero de Cuenta

Balance

Ciente

ClieCue

Cuenta

Los roles son indicados en diagramas E-R etiquetando las lneas que unen las relaciones con las entidades. La siguiente figura indica los roles de gerente y trabajador entre el conjunto de entidades Empleado el conjunto de relaciones trabajo_para.
Nombre del Empleado Numero_Telfono

Empleados

Gerente

Trabajado r Un conjunto de entidades dbiles es indicado en un diagrama E-R con un rectngulo con doble
lnea. La siguiente figura muestra el conjunto de entidades dbiles transaccin que es dependiente del conjunto de entidades fuertes cuenta por medio del conjunto de relaciones log.
Numero de Numero de Transaccin

Trabajo Para

Cantidad Fech

Balanc e

Cuent

Log

Transacci n

Los conjuntos de relaciones no binarias pueden ser representados fcilmente en un diagrama E-R. El siguiente diagrama consiste de tres conjuntos de entidades: cliente, cuenta y sucursal relacionados a travs del conjunto de relaciones CAB. Este diagrama especfica que un cliente puede tener varias cuentas, cada una localizada en diferentes sucursales bancarias y que una cuenta puede pertenecer a varios clientes.
Ciudad de la Sucursal Ciudad del Cliente Balance Numero de Cuenta Sucursal

Direccin Seguro Social Nombre del Cliente

Nombre de la Sucursal

Activ

Client

CAB

Cuent

VII. Reduccin de Diagramas E-R a Tablas Una base de datos especificada por un diagrama E-R puede tambin ser representada por una coleccin de tablas. Para cada conjunto de entidades y para cada conjunto de relaciones, hay una nica tabla a la cual se le asigna el nombre del correspondiente conjunto de entidades o de relaciones. Cada tabla tiene un nmero de columnas las cuales tambin tienen nombre nicos y provienen de los atributos correspondientes del conjunto de entidades o de relaciones. Representacin de Entidades Fuertes Sea E un conjunto de entidades fuertes con atributos descriptivos, a1, a2, ..., an, se representa ste conjunto con una tabla llamada E con n columnas, una para cada atributo de E. Cada lnea de las tablas E corresponde a una entidad del conjunto de entidades E. La siguiente figura muestra la tabla del conjunto de entidades Cuenta: Balance 1000 2000 1500 1500 500 900 1200 1300 2000 2500

Cuenta-numero 259 630 401 700 199 467 115 183 118 225

210

2200

Otro ejemplo de representacin a tablas es el conjunto de entidades Cliente:

Clientenombre Oliver Harris Marsh Pepper Ratliff Brill Evers

Social-seguro 654-32-1098 890-12-3456 456-78-9012 369-12-1518 246-80-1214 121-21-2121 135-79-1357

Direccin Main North Main North Park Putnam Nassau

Cliente-ciudad Harrison Rye Harrison Rye Pittsfield Stamford Princeton

Representacin de Entidades Dbiles Sea A un conjunto de entidades dbiles con atributos a1, a2 ..., ar. Sea B un conjunto de entidades fuertes con el cual A es dependiente. Sea b1, b2, ..., bs los atributos que conforman la llave primaria de B. La representacin del conjunto de entidades A en tabla llamada A se har con las columnas de cada uno de los atributos de la unin del conjunto ( a1, a2, ..., ar ) y el conjunto 8b1, b2, ..., bs).

Para ilustrar lo anterior, considrese el conjunto de entidades transaccin mostrado en el siguiente diagrama E-R.
Direccin Segur o Nombre del Cliente Ciudad del Cliente Fecha Balanc Numero de Cuenta Numero de Transaccin

Fecha

Cliente

Client

ClieCue

Cuent

Log

Transaccin

Y la tabla correspondiente ser:

Cuenta-numero 259 630 401

Transaccin-numero 5 11 22

Fecha 11 May 1990 17 May 1990 23 May 1990

Cantidad +50 +70 -300

700 199 259 115 199 259

69 103 6 53 104 7

28 May 1990 3 June 1990 7 June 1990 7 June 1990 13 June 1990 17 June 1990

-500 +900 -44 +120 -200 -79

Representacin de Conjunto de Relaciones Sea R un conjunto de relaciones que involucra los conjuntos de entidades E1, E2, ... Em. Se representar R con una tabla llamada R y columnas para cada uno de los atributos que conforman las llaves primaras de cada uno de los conjuntos E1, E2, ... En. Para ilustrar lo anterior, vase el conjunto de relaciones ClieCuen del diagrama E-R anterior. Cliente tiene como llave primaria a social_seguro mientras que cuenta tiene como llave primaria a cuenta_numero, dado a que la relacin tiene el atributo fecha entonces la tabla queda como sigue:

Social_seguro 654-62-1098 654-32-1098 890-12-3456 456-78-9012 369-12-1518 246-80-1214 246-80-1214 121-21-2121 135-79-1357 135-79-1357 135-79-1357 Tabla ClieCuen

Cuenta_numero 259 630 401 700 199 467 115 183 118 225 210

fecha 17Junio 1990 17 Mayo 1990 23 Mayo 1990 28 Mayo 1990 13 Junio 1990 7 Junio 1990 7 Junio 1990 13 Junio 1990 17 Junio 1990 19 Junio 1990 27 Junio 1990

Como ejemplo final, considerese el conjunto de relaciones CAB del diagrama E-R respectivo. La llave primaria de Sucursal es Sucursal_nombre, por lo que la tabla queda como sigue: Social_seguro 654-62-1098 654-32-1098 890-12-3456 456-78-9012 369-12-1518 246-80-1214 246-80-1214 Cuenta_numero 259 630 401 700 199 467 115 Sucursal_nombre Downtown Redwood Perryridge Downtown M;ianus Round Hill Pownal

121-21-2121 135-79-1357 135-79-1357 135-79-1357 Generalizacin

183 118 225 210

North Town Downtown Perryridge Brighton

Considrese al conjunto de entidades cuenta con los atributos cuenta_numero y balance. Ahora, expandamos el ejemplo a cuentas de ahorros (salvando_cuenta) y cuentas de cheques (revisando_cuentas) cada uno con los mismos atributos de cuenta ms atributos adicionales. Por ejemplo, al conjunto de entidades salvando_cuenta se le agrega el revisando_cuentas se le agrega el atributos a comn. Estos cual contiene una relacin entre entidades de nivel alto y entidades de nivel bajo. En este ejemplo, cuenta es entidad de nivel alto y salvando_cuentas y revisando_cuentas son entidades de bajo nivel. En trmino de diagramas E-R la generalizacin se representa con un tringulo etiquetado con ISA lo que significa que la entidad de alto nivel es una generalizacin de una entidad de bajo nivel es una especializacin de una entidad de alto nivel. La figura siguiente muestra el diagrama E-R del ejemplo en cuestin. Hay dos maneras de representar un diagrama ER con generalizacin a tablas: 1.- Crear una tabla para el conjunto de entidades de alto nivel. Para cada conjunto de entidades de bajo nivel, crear una tabla que incluya columnas para cada uno de los atributos de este conjunto de entidades ms las columnas de los atributos que conforman la llave primaria del conjunto de entidades de alto nivel. Para este ejemplo se tendran tres tablas. Cuenta(cuenta_numero y blance) Salvando_cuenta(cuenta_numero, porcentaje_interes) Revisando_cuenta (cuenta_numero, cantidad_descubrimiento)

2.- No crear una tabla para el conjunto de entidades de alto nivel y en su lugar crear una tabla para cada uno de los conjuntos de entidades de bajo nivel con las columnas de sus atributos ms columnas de cada uno de los atributos que conforman el conjunto de entidades de alto nivel, Para ste ejemplo se tendra dos tablas: Salvando_cuenta(cuenta_numero, porcentaje_inters) Revisando_cuenta (cuenta_numero, cantidad_descubrimiento)

Agregacin Una limitante del modelo E-R es que no es posible expresar relaciones entre relaciones. Para ilustrar la necesidad de tal construccin, considrese una base de datos que describa la informacin acerca de empleados quienes trabajan para un proyecto en particular y que usan un nmero diferente de mquinas para su trabajo. El siguiente diagrama E_R muestra esta informacin. Puede aparecer que los conjuntos de relaciones trabajo y usos pueden ser cambiados en un solo conjunto de relaciones. Ms sin embargo, ellos no deberan combinarse dado a que obscurecera la estructura lgica del esquema. Transformar un diagrama E-R que incluya agregacin a tablas es un proceso directo. Para el diagrama E-R anterior se crean las siguientes tablas:

Empleado Proyecto Trabajo Maquinara Usos

La tabla para el conjunto de relaciones usos incluye una columna para cada uno de los atributos de llave primaria del conjunto de entidades maquinara y el conjunto de relaciones trabajo. Tambin incluye una columna para cada uno de los atributos del conjunto de relaciones usos.

La solucin es usar agregacin. La agregacin es una abstraccin en la que las relaciones son tratadas como entidades de alto nivel. As para nuestro ejemplo, se considera al conjunto de relaciones trabajo. Y los conjuntos de entidades empleado y proyecto como un conjunto de entidades de alto nivel llamado trabajo. Tal conjunto de entidad es tratado de la misma manera en que es tratado cualquier conjunto de entidades. Una notacin comn para la agregacin se muestra en el siguiente diagrama E-R.

VIII. DISEO DE UN ESQUEMA DE BASE DE DATOS E-R El modelo de datos entidad relacin proporciona un alto grado de flexibilidad en el diseo de un esquema de base de datos para modelar una empresa dada. En esta seccin consideramos como un diseador de base de datos puede elegir entre una amplia variedad de alternativas. Entre Las decisiones a tomar se encuentran: El uso de una relacin ternaria o de un par de relaciones binarias Si un concepto de un mundo real se expresa mejor mediante un conjunto de entidades o por un conjunto de relaciones. El uso de un atributo o de un conjunto de entidades.

Nombr e

Horas Id.

Nmer o

Empleados

Traba jo

Proyecto

Usa

Maquinaria

Id.

UNIDAD

III

MODELO RELACIONAL

I. Estructura de Base de Datos Relacionales Es un modelo lgico basados en registros en el que su operacin se basa en relaciones. La siguiente terminologa es funcin de las relaciones: Domonios, atributos tuplas, llaves y relaciones. Las cuales se definen como sigue: RELACIN: Es una tupla. TUPLA: Correspondera a lo que es una lnea de una tabla . ATRIBUTO: Correspondera a lo que es una columna en una tabla. LLAVE PRIMARIA: Es un identificador de la tabla, esto es; una columna o combinacin de columnas con la propiedad de que en cualquier momento dos lineas de la tabla no contengan el mismo valor en esa columna o combinacin de columnas. DOMINIO: Conjunto de valores del cual uno o ms atributos toman sus valores actuales. Adicional a los trminos anteriores el modelo relacional maneja: Llave candidato, llave alterna, llave fornea que sern vistas posteriormente. Una base de datos relacional consiste en una coleccin de tablas o relaciones que tienen un nombre nico Ejemplo:
Relacin, S

S# S1 S2 S3 S4 S5

Snombre Smit Jones Blake Clark Adams

Status 20 10 30 20 30

Ciudad London Paris Paris Lomdon Athens

S#, Snombre, Status, Ciudad ------------- Son atributos S#, Snombre---------------------------------- Son atributos que forman la llave primaria S1, Smith, 20, London----------------------- Forman una tupla (registro). 20, 10, 30, 20, 30----------------------------- Son elementos del dominio del atributo Status Trminos equivalentes del modelo relacional.

Trminos Formales Relacin Tuplas Atributo Llave

Equivalencia en Tablas Tabla Lnea / Tabla Columna Columna

Equivalencia en Archivos Archivo Registro Campo Campo

MODELO RELACIONAL El modelo de datos relacional es relativamente nuevo. Tras la introduccin del modelo relacional se ha desarrollado una teora esencial para las BD relacionales, que ayuda al diseo de BD relacionales y al procesamiento eficiente de solicitudes de informacin. El modelo relacional se ha establecido como el principal modelo de datos para aplicaciones comerciales de procesamiento de datos. Estructura de las bases de datos relacinales. Una BD relacional consiste en una coleccin de tablas, a cada una de las cuales se les asigna un nombre nico. Una fila de la tabla representa una relacin entre un conjunto de valores, puesto que una tabla es una coleccin de dichas relaciones, hay una estrecha correspondencia entre el concepto de tabla y el concepto matemtico de relacin, del cual toma su nombre el modelo de datos relacional. ESTRUCTURAS BSICAS Considrese la tabla depsito, con cuatro atributos : nombre_sucursal, nmero_cuenta, nombre_cliente y saldo. Para cada atributo hay un conjunto de valores permitidos, llamado dominio, de este atributo, por ejemplo, para nombre_sucursal, el dominio ser el conjunto de todos los nombres de las sucursales. Sea D1 el dominio de nombre_sucursal, y D2, D3 , D4 los dominios de los otros atributos. Cada una de las filas de depsito debe constar de 4 tuplas (v1, v2, v3, v4), perteneciendo cada una a su dominio correspondiente. En general, depsito contendr nicamente un subconjunto del conjunto de todas las filas posibles, por tanto, depsito es un subconjunto de: D1 x D2 x D3 x D4 En general, una tabla de n columnas debe ser un subconjunto de: D1 x D2 x ... x Dn-1 x Dn Los matemticos definen una relacin como un subconjunto de un producto cartesiano de una. lista de dominios, lo que se corresponde casi exactamente con nuestra definicin de tabla. Puesto que las tablas son esencialmente relaciones, usaremos los trminos matemticos relacin y tupla en lugar de los trminos tabla y fila. Sea la variable tupla t la primera tupla de la relacin. Usamos la notacin t[nombre_sucursal] para indicar el valor de t en el atributo nombre_sucursal, alternativamente, podemos escribir t[1] para indicarlo. Puesto que una relacin es

un conjunto de tuplas, usamos la notacin matemtica t r para indicar que la tupla t est en la relacin r. Necesitaremos que, para todas las relaciones r, los dominios de todos los atributos sean atmicos, entendiendo coma tal a aquel en el que sus elementos se consideran unidades indivisibles, por ejemplo, los nmeros naturales. En todos nuestros ejemplos supondremos dominios atmicos.

ESQUEMA DE LA BASE DE DATOS Cuando hablamos de una BD debemos diferenciar entre el esquema de la BD o el diseo lgico de la BD, y una instancia de la BD, que son los datos en la BD en un instante de tiempo dado. El concepto de esquema de una relacin corresponde a la nocin de definicin de tipo en los lenguajes de programacin, mientras que el de instancia de una relacin se corresponde con el de variable. Es conveniente dar un nombre al esquema de una relacin, por lo que adoptamos el convenio de usar nombres en minsculas para relaciones y nombres, empezando por una letra mayscula para los esquemas de relaciones. Siguiendo esta notacin usamos esquema_depsito para indicar el esquema de relacin para la relacin depsito. As: Esquema_depsito = (nombre_sucursal, nmero_cuenta, nombre_cliente, saldo) Indicamos el hecho de que depsito es una relacin sobre el esquema depsito por: depsito (esquema_depsito) En general, el esquema de una relacin es una lista de atributos y sus correspondientes dominios. No nos preocuparemos, por ahora, de dar una definicin precisa del dominio de cada atributo, sin embargo, cuando queramos definir nuestros dominios, para definir el esquema de relacin para la relacin depsito, usaremos la notacin: (nombre_sucursal: cadena, nmero_cuenta: entero, nombre_cliente: cadena, saldo: entero) Considrese la relacin cliente, con el esquema para esa relacin que sigue : Esquema_cliente = (nombre_cliente, calle, ciudad_cliente) Obsrvese que el atributo nombre_cliente aparece en los dos esquemas de relaciones. Esto no es una coincidencia, el uso de atributos comunes en esquemas de relaciones es una forma de relacionar tuplas de distintas relaciones. Se podra pensar en trminos de un esquema de relaciones en vez de en varios. Supngase que usamos slo una relacin para nuestro ejemplo con el esquema : Esquema_info_cuenta = (nombre_sucursal, nmero_cuenta, nom,bre_cliente, saldo, calle, ciudad_cliente) Obsrvese que si un cliente tiene varias cuentas debemos listar su direccin una vez para cada cuenta, es decir, debemos repetir informacin, lo que supone un desperdicio y se evita mediante el uso de dos relaciones. Adems, si un cliente tiene una o ms cuentas pero no ha dado una direccin, no podemos construir una tupla en esquema_info_cuenta, ya que no se conocen los valores para calle y ciudad_cliente. Para representar tuplas incompletas Bases de Datos debemos usar valores nulos. Usando dos relaciones, podemos representar

clientes cuya direccin se desconozca sin usar valores nulos, simplemente usamos una tupla en esquema_depsito y no creamos tupla en esquema_cliente hasta que la informacin est disponible. No siempre es posible eliminar los valores nulos, supngase que incluimos el atributo nmero_telfono en el esquema_cliente. Puede ocurrir que un cliente no tenga telfono, entonces tendramos que recurrir a los valores nulos. Veremos ms adelante que los valores nulos causan diversas dificultades en el acceso o actualizxacin de la BD y, por tanto, deben eliminarse cuando sea posible. Para el propsito de este captulo supondremos una empresa bancaria con el diagrama E-R de la figura. Las claves primarias para los conjuntos entidad cliente y sucursal son nombre_cliente y nombre_sucursal. Ls esquemas de relaciones para esta empresa son: Esquema_sucursal = (nombre_sucursal, activo, ciudad_sucursal) Esquema_cliente = (nombre_cliente, calle, ciudad_cliente) Esquema_depsito = (nombre_sucursal, nmero_cuenta, nombre_cliente, saldo) Esquema_prstamo = (nombre_sucursal, nmero_prstamo, nombre_cliente, cantidad)
NumeroCuenta Saldo

NomSucursal

Calle
NomCliente

Activo Ciudad_ Cliente

DEPOSITO

Ciudad_ Sucursal

CLIENTE

SUCURSAL

PRESTAMO

NumeroPrestamo Cantidad

CLAVES Las nociones de superclave, clave candidata y clave primaria tambin pueden aplicarse al modelo relacional, por ejemplo, en esquema_sucursal, {nombre_sucursal} y {nombre_sucursal, ciudad_sucursal} son superclaves, la

primera es una clave candidata, no as la segunda, que contiene a la primara, por lo que la primera es la clave primaria, y la clave primaria para esquema_cliente es {nombre_cliente}. Sea R un esquema de relacin. Si decimos que un subconjunto K de R es una superclave para R estamos retringindonos a considerar las relaciones r(R), en las que no haya dos tuplas distintas que tengan los mismos valores en todos los atributos de K. Es decir, si t1 y t2 estn en r y t1 t2, entonces t1[K] t2[K]. LENGUAJES DE CONSULTA Un lenguaje de consulta es un lenguaje en el que el usuario solicita informacin de la BD. Son, normalmente, de ms alto nivel que los estndar de programacin. Los lenguajes de consulta pueden clasificarse en lenguajes procedimentales y no procedimentales. En un lenguaje procedimental, el usuario da instrucciones al sistema para que realice una serie de operaciones en la BD para calcular el resultado deseado. En uno no procedimental, el usuario describe la informacin deseada sin dar un procedimiento especfico para obtenerla. La mayor parte de los sistemas comerciales de BD relacionales, ofrecen un lenguaje de consulta que incluye elementos de los dos enfoques. En este captulo examinamos dos lenguajes puros, el lgebra relacional es procedimental, mientras que el clculo relacional de tuplas y el clculo relacional de dominios son no procedimentales. Estos lenguajes de consulta son concisos y formales, pero ilustran las tcnicas fundamentales para extraer datos de la BD. Inicialmente nos interesaremos nicamente por las consultas, aunque un lenguaje de manipulacin de datos completo incluye, adems de un lenguaje de consulta, un lenguaje para la modificacin de la BD. El lgebra relacional. El lgebra relacional es un lenguaje de consulta procedimental. Consta de un conjunto de operaciones que toman una o dos relaciones como entrada y producen una nueva relacin como resultado. Las operaciones fundamentales en el lgebra relacional son seleccionar, proyectar, producto cartesiano, renombrar, unin y diferencia de conjuntos. Adems, existen otras operaciones, interseccin de conjuntos, producto natural, divisin y asignacin, que se definirn en trminos de las operaciones fundamentales.

EL MODELO DE ARQUITECTURA DE BASES DE DATOS Hasta fecha relativamente cercana, las bases de datos eran el resultado de una compleja programacin y de complicados mecanismos de almacenamiento. Con la popularizacin de la microinformtica, la aparicin de aplicaciones especficas tambin trajo con ella la disponibilidad de herramientas de gestin de datos, que acabaron desembocando en los denominados sistemas de gestin de bases de datos, identificados por sus siglas SGBD (DBMS en ingls, siglas de DataBase Management Systems). De esta manera, la gestin de base de datos pudo

liberarse de los grandes ordenadores centrales, pudiendo distribuirse segn los intereses de los usuarios, y dotando de autonoma en la gestin de informacin a muchas entidades. Los SGBD permitieron a todo tipo de usuarios crear y mantener sus bases de datos, dotndolos de una herramienta que era capaz de transformar el nivel lgico que stos diseaban en un conjunto de datos, representaciones y relaciones, traducindolo al nivel fsico correspondiente. Para que fuese posible, y para asegurar a los usuarios cierta seguridad en el intercambio de datos entre diferentes sistemas, y en el diseo de ficheros y bases de datos, fue necesario normalizar los esquemas que guiaban la creacin de las bases de datos. Las bases de datos respetan la arquitectura de tres niveles definida, para cualquier tipo de base de datos, por el grupo ANSI/SPARC. En esta arquitectura la base de datos se divide en los niveles externo, conceptual e interno (KORTH y SILBERSCHATZ, 1994:5; MIGUEL y PIATTINI, 1993: 83-107; MOTA, CELMA y CASAMAYOR, 1994: 11-12): 1. Nivel interno: es el nivel ms bajo de abstraccin, y define cmo se almacenan los datos en el soporte fsico, as como los mtodos de acceso. 2. Nivel conceptual: es el nivel medio de abstraccin. Se trata de la representacin de los datos realizada por la organizacin, que recoge las vistas parciales de los requerimientos de los diferentes usuarios y las aplicaciones posibles. Se configura como visin organizativa total, e incluye la definicin de datos y las relaciones entre ellos. 2. Nivel externo: es el nivel de mayor abstraccin. A este nivel corresponden las diferentes vistas parciales que tienen de la base de datos los diferentes usuarios. En cierto modo, es la parte del modelo conceptual a la que tienen acceso.

Niveles de la arquitectura de bases de datos. En ocasiones puede encontrarse el nivel conceptual divido en dos niveles, conceptual y lgico. El primero de ellos corresponde a la visin del sistema global desde un punto de vista organizativo independiente, no informtico. El segundo correspondera a la visin de la base de datos expresada en trminos del sistema que se va a implantar con medios informticos. El modelo de arquitectura propuesto permite establecer el principio de independencia de los datos. Esta independencia puede ser lgica y fsica. Por independencia lgica se entiende que los cambios en el esquema lgico no deben afectar a los esquemas externos que no utilicen los datos modificados. Por independencia fsica se entiende que el esquema lgico no se vea afectado por cambios realizados en el esquema interno, correspondientes a modos de acceso, etc. MODELADO CONCEPTUAL DE BASES DE DATOS RELACIONALES: EL MODELO E/R El modelo Entidad/Relacin es un modelo de datos semntico cuyo objetivo inicial era vencer algunas de las dificultades mostradas por el modelo relacional, al que pretenda sustituir. Concretamente, pretenda dotar de "significado" a las estructuras de datos, carentes del mismo, del modelo relacional. En la prctica, este modelo de datos no ha llegado a implementarse en ningn DBMS comercial, pero ha tenido una enorme repercusin como herramienta de modelado de bases de datos (paradjicamente, bases de datos relacionales), existiendo hoy en da herramientas de diseo conceptual que incorporan la totalidad de sus conceptos e incluso productos que transforman diagramas conceptuales E/R en bases de datos reales en diversos formatos.

Consideramos que el modelado E/R se ha convertido en estndar para el diseo de bases de datos relacionales, por lo que lo utilizaremos para describir nuestra implementacin. Esta aseveracin se ve reforzada por la eleccin de este modelo de datos, por ejemplo, en proyectos tan importantes como Multilex. A continuacin mostramos una muy sucinta descripcin de este modelo. Para una descripcin detallada, nos referimos a Chen. En el modelo Entidad/Relacin, el UoD/mundo/empresa/seccin de la realidad1 se representa mediante un nmero muy reducido de conceptos semnticos bsicos: el mundo est compuesto de entidades; una entidad es cualquier objeto distinguible relevante en el mundo en cuestin (los profesores y cursos en el mundo acadmico de nuestro ejemplo anterior). Estas entidades poseen un nmero indeterminado de propiedades, que son "trozos" de informacin que describen a las entidades de uno u otro modo. Cada una de las entidades tiene una identidad, esto es, son identificables de forma nica. Grupos de entidades relacionadas mantienen relaciones con otros grupos de entidades. Tambin existen subtipos de entidades: la entidad E2 es un subtipo de la entidad E1 si y slo si cada E2 es tambin un E1. Se supone que mediante estos simples componentes se puede modelar cualquier "seccin de realidad". Aplicando estos conceptos al submundo que nos proponemos modelar, el lexicn, podramos considerar a los distintos lexemas como las entidades centrales que lo componen. Los lexemas tienen ciertas propiedades (morfolgicas, sintcticas, semnticas) y mantienen ciertas relaciones con otros lexemas (sinonimia, hiperonimia). Esto es una enorme simplificacin del asunto, pero nos puede servir para mostrar el modus operandi que el modelo nos impone. El modelo E/R aporta una herramienta de modelado para representar las entidades, propiedades y relaciones: los diagramas Entidad/Relacin. Mediante stos, el esquema conceptual abstracto puede ser mostrado grficamente y mantener una independencia conceptual con respecto a la implementacin propiamente dicha. En realidad, podemos hacer que los diagramas sean un reflejo fiel de las relaciones, interrelaciones y atributos del modelo relacional de datos o podemos englobar diversas relaciones en una sola entidad o conjunto de propiedades. Los diagramas E/R son directamente proyectables sobre un esquema fsico relacional excepto en lo que se refiere a las relaciones muchos a muchos. Los diagramas E/R son parecidos a los diagramas de flujo (organigramas) clsicos en que utilizan rectngulos, rombos y valos, pero los significados de estos elementos son distintos. La Figura muestra un ejemplo que nos servir para mostrar cmo han de interpretarse estos diagramas.

Ejemplo de diagrama E/R Los rectngulos representan entidades, los rombos relaciones y los valos propiedades. Otra diferencia fundamental con los organigramas es que stos tienen un principio y un final, mientras que un diagrama E/R no. Esto es obvio, puesto que los organigramas representan procesos, mientras que los diagramas E/R representan estados. El tipo de relacin entre dos entidades se representa mediante 1s y Ms (tambin el smbolo o n). En la Figura 64 la entidad E1 mantiene una relacin de uno a muchos con la entidad E2 y una relacin de uno a uno con la entidad E3. Existen otras convenciones que hemos querido mostrar en esta figura. Una propiedad cuyo nombre est subrayado seala que sa es la propiedad que identifica de forma nica a la entidad, y que se corresponder con la clave primaria de una relacin en la implementacin relacional. Finalmente, un rectngulo doble, como el de la entidad E2, significa que esa entidad es dependiente o dbil, es decir, su existencia depende de la existencia de otra entidad (E1) en nuestro ejemplo. En algunos diagramas E/R el rombo que indica la relacin entre una entidad independiente y otra dependiente tambin aparece con lneas dobles.

Finalmente, las relaciones tipo/subtipo (self-joint en la implementacin relacional) se especifican mediante una relacin de una entidad consigo misma y con las lneas de unin dirigidas, tales como las que muestra la relacin R4.

Diagrama E/R proyectable sobre diseo relacional Este modelo especifica la existencia de tres entidades, Profesor, Curso y Departamento, que se corresponden con otras tantas relaciones. Un departamento tiene muchos profesores y un profesor puede dar muchos cursos. Para cada una de las entidades existe una propiedad que las identifica nicamente y que se corresponde con la clave primaria (en este caso clave subrogada) de cada una de las tablas en la implementacin relacional. Las entidades tienen otras propiedades que las describen y que se corresponden con los distintos campos de la tabla (relacin). Finalmente, las tres entidades contempladas son consideradas como independientes, aunque tambin habramos podido modelar la existencia de alguna de ellas como dependiente de otra; por ejemplo podramos haber establecido la restriccin de que un profesor no puede existir sin estar adscrito a ningn departamento, o que un curso no puede existir sin un profesor que lo imparta.

Modelo entidad-relacin. El modelo de datos entidad-relacin (E-R) se basa en una percepcin de un mundo real que consiste en un conjunto de objetos bsicos llamados entidades y relaciones entre estos. Se desarrollo para facilitar el diseo de BD permitiendo la especificacin de un esquema empresarial, que representa la estructura lgica global de la BD. Entidades y conjuntos de entidades. Una entidad es un objeto que existe y es distinguible de otros objetos, por ejemplo John Harris, con nmero de seguridad social 890-12-3456, es una entidad, ya que indica nicamente una persona especifica. Una entidad puede ser concreta, como un libro, o abstracta, como un concepto. Un conjunto de entidades es un grupo de entidades del mismo tipo, por ejemplo, en un banco, el conjunto de entidades cliente. Los conjuntos de entidades no necesitan ser disjuntos, es posible definir los conjuntos de entidades de empleados y clientes de un banco, pudiendo existir una persona ser ambas o ninguna de las dos cosas. Una entidad est representada por un conjunto de atributos, que formalmente es una funcin que asigna un conjunto de entidades a un dominio. As, cada entidad se describe por medio de un conjunto de pares (atributo, valor de dato), un par cada elemento del conjunto de entidades. El concepto de un conjunto de entidades corresponde a la nocin de definicin de tipo en un lenguaje de programacin. Por tanto, una BD incluye una coleccin de conjuntos de entidades cada uno de los cuales contiene un nmero cualquiera de entidades del mismo tipo. En este tema trabajaremos con cinco conjuntos de entidades: 1.- Sucursal. El conjunto de todas las sucursales de un banco. Cada sucursal se describe por los atributos nombre_sucursal, ciudad_sucursal y activo. 2.- Cliente. El conjunto de todas las personas que tienen cuentas en el banco, y se describen por medio de los atributos nombre_cliente, seguridad_social, calle y ciudad_cliente. 3.- Empleado. El conjunto de todas las personas empleadas en el banco, que se describen por los atributos nombre_empleado y nmero_telfono. 4.- Cuenta. El conjunto de todas las cuentas de banco, descritas por nmero_cuenta y saldo. 5.- Transaccin. El conjunto de todas las transacciones de cuentas ejecutadas en le banco. Cada transaccin se describe por los atributos nmero_transaccin, fecha y cantidad. Relaciones y conjuntos de relaciones. Una relacin es una asociacin entre varias entidades, por ejemplo, podemos definir una relacin que asocia al cliente Harris con la cuenta 401. Un conjunto de relaciones es un grupo de relaciones del mismo tipo. Formalmente es un relacin de n 2 conjuntos de entidades (posiblemente no distintos). Si E1, E2, ...,En son conjuntos de entidades, entonces un conjunto de relaciones R es un

subconjunto de {(e1, e2, ..., en)|e1 E1, e2 E2, ..., en En} donde (e1, e2, ..., en) es una relacin. La mayora de los conjuntos de relaciones en un sistema de BD son binarios, aunque ocasionalmente hay conjuntos de relaciones que implican ms de dos conjuntos de entidades, como la relacin entre cliente, cuenta y sucursal. Siempre es posible sustituir un conjunto de relaciones no binario por varios conjuntos de relaciones binarias distintos. As, conceptualmente, podemos restringir el modelo E-R para incluir slo conjuntos binarios de relaciones, aunque no siempre es deseable. La funcin que juega una entidad en una relacin se llama papel, y normalmente son implcitos y no se suelen especificar. Sin embargo son tiles cuando el significado de una relacin necesita ser clarificado. Tal es el caso cuando los conjuntos de entidades de un conjunto de relaciones no son distintos. Por ejemplo, el conjunto de relaciones trabaja_para podra modelarse por pares ordenados de entidades empleado. El primer empleado de cada par toma el papel de director, mientras el segundo toma el papel de trabajador. Una relacin tambin puede tener atributos descriptivos, por ejemplo fecha en el conjunto de relaciones cuenta_cliente que especifica la ltima fecha en la que el cliente tuvo acceso a su cuenta. Atributos. Es posible definir un conjunto de entidades y sus relaciones de varias formas diferentes. La principal diferencia est en la forma en que tratamos los diversos atributos. Considrese el conjunto de entidades empleado con atributos nombre_empleado y nmero_telfono. Se puede argumentar fcilmente que un telfono es una entidad en s mismo con atributos nmero_telfono y situacin (la oficina donde est). Si tomamos este punto de vista, el conjunto de entidades empleado debe redefinirse como sigue: 1.- El conjunto de entidades empleado con atributo nombre_empleado. 2.- El conjunto de entidades telfono con atributo nmero_telfono y situacin. 3.- El conjunto de relaciones empltelf, que indica la asociacin entre los empleados y los telfonos que tienen. El discriminador de un conjunto de entidades dbil es un conjunto de atributos que permite que se haga esta distincin. Por ejemplo, el discriminador del conjunto de entidades dbil transaccin es el atributo nmero_transaccin, ya que para cada cuenta un nmero de transaccin identifica de forma nica una entidad. La clave primaria de un conjunto de entidades dbil esta formada por la clave primaria del conjunto de entidades fuerte de la que depende su existencia y su discriminador. En el caso del conjunto transaccin, la clave primaria es {nmero_cuenta, nmero-transaccin}, donde nmero_cuenta identifica a la entidad dominante de una transaccin y nmero_transaccin distingue entidades transaccin dentro de la misma cuenta. Sea R un conjunto de relaciones que implica a los conjuntos E1, E2, ..., En. Sea (Ei) la clave primaria que denota el conjunto de atributos que forma la clave primaria para el conjunto de entidades Ei. Supngase que R no tiene atributos.

Entonces los atributos que describen las relaciones individuales del conjunto R, denotadas por el atributo(R), son: Clave_primaria (E1) Clave_primaria (En) ... Clave_primaria (En) En el caso de que R tenga atributos descriptivos, digamos {a1, a2, ...,am}, entonces el conjunto atributo(R) consta de: Clave_primaria (E1) ... Clave_primaria (En) {a1, a2, ...,am} Considrese el conjunto de relaciones CtaCli, que implica a los conjuntos de entidades cliente, con clave primaria seguridad_social, y cuenta, con clave primaria nmero_cuenta. Puesto que el conjunto de relaciones tiene el atributo fecha, el conjunto atributo(CtaCli) se compone de los tres atributos, seguridad_social, nmero_cuenta y fecha. Ahora ya podemos explicar que constituye la clave primaria de un conjunto de relaciones R. La composicin de la clave primaria depende de la cardinalidad de asignacin y de la estructura de los atributos asociados con el conjunto de relaciones R. Si el conjunto de relaciones R no tiene atributos asociados, entonces el conjunto atributo(R) forma una superclave. Esta superclave es una clave primaria si la cardinalidad de asignacin es muchas a muchas. Considrese el conjunto de relaciones CtaCli. Si el conjunto de relaciones es muchas a muchas su clave primaria ser {seguridad_social, nmero_cuenta}, si es muchas a una, de cliente a cuenta, entonces su clave primaria ser {seguridad_social}, ya que una persona puede tener una sola cuenta asociada. Si el conjunto de relaciones R tiene varios atributos asociados con l, entonces una superclave est formada como antes, ms la posible adicin de uno o ms de estos atributos. La estructura de la clave primaria depende tanto de la cardinalidad de asignacin como de las semnticas del conjunto de relaciones. Considrense los conjuntos de entidades cliente y banquero y un conjunto de relaciones BanqueroCli. Supngase que ste conjunto de relaciones tiene el atributo tipo asociado con l que representa la naturaleza de la relacin con el cliente (prestamista o banquero). Si un banquero determinado puede representar dos papeles distintos en una relacin con un cliente determinado, entonces la clave primaria de BanqueroCli consta de la unin de las claves primarias cliente y banquero, as como del atributo tipo. Sin embargo, si un banquero slo puede tener una relacin con un cliente determinado, entonces tipo no es parte de la clave primaria, que ser nicamente la unin de las claves primarias cliente y banquero. Diagrama entidad-relacin. Como vimos, la estructura global de una BD puede representarse grficamente por medio de un diagrama de E-R, que consta de: 1.- Rectngulos, que representan conjuntos de entidades. 2.- Elipses, que representan atributos. 3.- Rombos, que representan conjuntos de relaciones. 4.- Lneas, que enlazan atributos a conjuntos de entidades y conjuntos de entidades a conjuntos de relaciones. Para distinguir entre las diferentes cardinalidades, dibujaremos lneas, con o sin direccin entre los conjuntos de relaciones y el conjunto de entidades en cuestin.

Una lnea con direccin ( ) marcar la cardinalidad una, mientras que una lnea sin flecha (--) indicar la cardinalidad muchas. Adems, un conjunto de entidades dbil se indica por medio de un rectngulo de doble contorno.

Reduccin de los diagramas E-R a tablas. En trminos de un diagrama E-R, la generalizacin se representa por medio de un componente tringulo etiquetado ISA (is a, es un/a) y representa, por ejemplo, que una cuenta de ahorros es una cuenta.

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 entidades de nivel ms alto se dice que son heredados por los conjuntos de entidades de nivel ms bajo. Por ejemplo, cuenta_ahorros hereda los atributos de cuenta, por lo que tendr tres atributos, nmero_cuenta, saldo y tasa_inters. Existen dos mtodos diferentes para transformar un diagrama E-R que incluye generalizacin en una forma tabular:

1.- Crear una tabla para el conjunto de entidades de nivel ms alto. Para cada conjunto de entidades de nivel ms bajo, crear una tabla que incluya una columna para cada uno de los atributos de ese conjunto de entidades, ms una columna para cada atributo de la clave primaria del conjunto de entidades del nivel ms alto. As, para el ejemplo anterior tendremos tres tablas : cuenta (nmero_cuenta, saldo), cuenta_ahorros (nmero_cuenta, tasa_inters) y cuenta_cheques (nmero_cuenta, saldo_deudor). 2.- No crear una tabla para el conjunto de entidades de nivel ms alto. En cambio, para cada conjunto de entidades de nivel ms bajo, crear una tabla que incluya una columna para cada uno de los atributos de ese conjunto de entidades, ms una columna para cada atributo del conjunto de nivel ms alto. Entonces, para el ejemplo, tendremos: cuenta_ahorros (nmero_cuenta, saldo, tasa_inters) y cuenta_cheques (nmero_cuenta, saldo, saldo_deudor). Agregacin Una limitacin del modelo E-R es que no es posible expresar relaciones entre relaciones. Para ilustrar la necesidad de una construccin as, considrese una BD que describe informacin acerca de empleados que trabajan en un proyecto determinado y usan varias mquinas distintas.

Puede ocurrir que los conjuntos de relaciones trabajo y usa se combinen en un nico conjunto de relaciones. Sin embargo, no deben combinarse, puesto que oscurecera la estructura lgica del esquema. La solucin es usar agregacin. La agregacin es una abstraccin a travs de la cual las relaciones se tratan como entidades de nivel ms alto. As, para nuestro ejemplo, recordamos el conjunto de relaciones trabajo y los conjuntos de entidades empleado y proyecto como un conjunto de entidades de nivel ms alto llamado trabajo, as, se trata de la misma forma que cualquier otro conjunto de entidades.

El diseador de un esquema de BD debe decidir cuando es conveniente el uso de conjuntos de entidades dbiles, generalizacin y agregacin para modelar una empresa con el modelo de datos E-R. Cada una de estas caractersticas contribuye a la modularidad del diseo: 1.- Un conjunto de entidades fuertes y sus conjuntos de entidades dbiles dependientes pueden ser considerados como un objeto nico en la BD, ya que las entidades dbiles son dependientes por existencia de una entidad fuerte. 2.- La agregacin agrupa una parte del diagrama E-R en un conjunto de entidades nicas. Es posible tratar el conjunto de entidades agregado como una unidad nica sin preocuparse de los detalles de estructura interna. 3.- Generalizacin, o jerarqua de relaciones ISA, contribuye a la modularidad permitiendo que atributos comunes de conjuntos de entidades similares sean representados una sola vez en un diagrama E-R. Sin embargo, el uso excesivo de estas caractersticas puede introducir una complejidad innecesaria en el diseo.

Llaves primarias. Como ya se ha mencionado anteriormente, la distincin de una entidad entre otra se debe a sus atributos, lo cual lo hacen nico. Una llave primaria es aquel atributo el cual consideramos clave para la identificacin de los dems atributos que describen a la entidad. Por ejemplo, si consideramos la entidad ALUMNO del Instituto Tecnolgico de La Paz, podramos tener los siguientes atributos: Nombre, Semestre, Especialidad, Direccin, Telfono, Nmero de control, de todos estos atributos el que podremos designar como llave primaria es el nmero de control, ya que es diferente para cada alumno y este nos identifica en la institucin. Claro que puede haber ms de un atributo que pueda identificarse como llave primaria en este caso se selecciona la que consideremos ms importante, los dems atributos son denominados llaves secundarias.

Una clave o llave primaria es indicada grficamente en el modelo E-R con una lnea debajo del nombre del atributo.

Entidades
Corresponden a un conjunto de sujetos de inters en el modelo. Su representacin grfica es un rectngulo, con el nombre del conjunto de sujetos al que se refiere, que por convenio utilizaremos en plural:

Algunos criterios para identificar entidades son los siguientes: Criterio Ejemplos Personas Alumnos, Pasajeros, Profesores, Clientes Instituciones Bancos, Empresas, Universidades Unidades organizacionales Departamentos, Sucursales, Plantas, Lneas Clasificaciones, agrupaciones y Tipos, Clases, Conceptos, Cuentas, Grupos jerarquas Documentos Facturas, Pedidos, Ordenes, Cheques Catlogos Materiales, Productos, Asignaturas, Habilidades

Asociaciones *
Representan la interrelacin entre las entidades del modelo, estableciendo una accin, un hecho o una relacin de pertenencia entre dos (o ms) entidades. Cada asociacin se representan con un rombo, con el nombre dentro de l y lneas conectndolo a las entidades participantes:

Algunos ejemplos de asociaciones: Clientes colocan Pedidos Proveedores suministran Materiales Pedidos contienen Partidas Bancos emiten Cheques Alumnos forman Grupos

Debemos buscar nombres significativos para las asociaciones, que en general sern verbos indicando acciones entre las entidades involucradas. Sin embargo, muchas asociaciones establecen unicamente una relacin de pertenencia y resulta difcil encontrar nombres diferentes para tales asociaciones. Para evitar este problema, tomaremos el convenio de no denominar a las relaciones de pertenencia utilizando simplemente un rombo sin etiqueta. No existe restriccin alguna en el modelo al respecto de que exista ms de una asociacin entre una pareja de entidades, y por tanto esto es perfectamente permisible siempre y cuando represente un hecho de la realidad que se modela. Como ejemplo de una pareja de entidades con ms de una asociacin tenemos el siguiente:

En este caso la asociacin solicitan se refiere al hecho en que la lnea de produccin solicita la adquisicin de un material y por otra parte, la asociacin utilizan se refiere al hecho de que el material es utilizado en la lnea de produccin, dos hechos distintos entre una misma pareja de entidades. Cardinalidad de una asociacin La cardinalidad de una asociacin es el nmero de elementos de las entidades participantes que se relacionan entre s, a travs de la asociacin en cuestin. Los tres casos de mayor inters son 1:1 (uno a uno), 1:N (uno a muchos) y N:N (Muchos a muchos), si bien pueden establecerse explcitamente los valores de N, sobre todo en los casos en que sea restrictivo. En el diagrama la cardinalidad se indica sobre la lnea que une cada entidad con la asociacin:

Esto debe leerse en dos sentidos: 1 cliente coloca N pedidos y un pedido es colocado por 1 (y slo 1) cliente.

En este caso, 1 proveedor surte N materiales pero al mismo tiempo 1 material puede ser surtido por N proveedores.

Atributos Los atributos son caractersticas, propiedades o valores de las entidades y/o asociaciones que las describen en detalle. En la notacin original de Chen, los atributos se representan con elipses. Para evitar sobrecargar los diagramas, utilizaremos unicamente los nombres de los atributos bajo la entidad o asociacin correspondiente:

Identificador de entidad El identificador es un conjunto formado por uno o ms atributos que identifican de manera nica a uno de los elementos del conjunto representado en una entidad. Ejemplos: el rfc de un cliente, el nmero de un pedido, la matrcula de un alumno. En la notacin Original de Chen, el identificador se indica con una elipse doble; para evitar sobrecargar el diagrama, subrayaremos el conjunto de atributos que funcionen como identificador de la entidad.

Mtodologa para integrar un Modelo Entidad Relacin 1. Identificar entidades 2. Identificar asociaciones entre entidades 3. Determinar la cardinalidad de las asociaciones 4. Incorporar atributos de entidades y asociaciones 5. Determinar identificadores 6. Verificar con los requerimientos y refinar el modelo en caso necesario Adems de entidades, asociaciones y atributos, se definen smbolos adicionales para algunos conceptos que facilitan la conceptualizacin y lectura de los modelos. Roles Los roles se utilizan cuando una entidad juega ms de un rol en una asociacin, ya sea consigo misma, o bien cuando dos (o ms) entidades presentan mltiples asociaciones entre ellas. Estos son los casos:

En el primer caso, la entidad Ciudades juega dos roles: el de Orgenes y el de Destinos, cada uno de los cuales se asocia con el viaje a travs de las asociaciones Parten y Llegan. En el segundo caso, en la entidad Empleados estn incluidos los Jefes, y la mayora de los empleados le reportan a algn jefe. Entidades generalizadoras, especializadoras y relaciones ISA En algunas ocasiones encontramos conjuntos de entidades para los que para todos los elementos existen determinados atributos o asociaciones, mientras que para algunos subconjuntos existen asociaciones o atributos exclusivos para el subconjunto. En este caso es til establecer una entidad generalizadora y una o varias entidades especializadoras como se muestra en el modelo:

En este caso, la entidad Empleados es la generalizadora, las entidades Honorarios y Planta son las especializadoras. Culaquier empleado, de planta u honorarios puede ser asignado para realizar Proyectos. Los atributos RFC y FolioRecibo no se definen para todos los empleados, unicamente para los de honorarios; los atributos NoIMSS y FechaPlanta slo se definen para los empleados de planta quienes adems son los nicos que Reciben Prestaciones. Las relaciones ISA (del ingls is a, o "es un") son implcitamente de cardinalidad 1:1 por lo que no se indica explcitamente. Entidades fuertes y dbiles En ocasiones aparecen entidades que para identificarse plenamente requieren un contexto que puede expresarse como una asociacin con otra entidad. Un caso tpico es el que se muestra en el siguiente modelo:

En l, dado que el nombre de una ciudad puede repetirse en diferentes estados y an el nombre de los estados puede repetirse entre diferentes pases, decimos que estado es una entidad dbil de pases y que ciudad es una entidad dbil de estado para indicar que existe una depencia de identificacin entre los conjuntos de entidades, lo cual denotamos con la lnea doble en la entidad y la asociacin. Se asume que la cardinalidad es siempre 1:N, con N del lado de la entidad dbil, por lo que no se indica explcitamente. Cuando utilizamos el modelo entidad-relacin para abstraer una situacin, existen algunos detalles sobre la informacin que no se exhiben en nuestro modelo, pero resulta importante contemplar. A estos detalles les denominamos reglas de integridad adicionales. Porqu les llamamos adicionales? El modelo entidad-relacin establece reglas de integridad implcitas; por ejemplo, cuando tenemos el modelo que se muestra a continuacin:

implcitamente se establece que un pedido debe estar relacionado con un cliente que exista, esto es, no puede haber pedidos para los que no se sepa de que cliente son. Del mismo modo, en el modelo:

la asociacin surten est formada por todas las parejas vlidas de un proveedor con un material, donde la nocin de validez se refiere a que una pareja aparece en surten solo si efectivamente el proveedor indicado surte el material indicado. Los dos ejemplos anteriores constituyen reglas de integridad implcitas en el modelo entidad-relacin. A continuacin discutiremos cuales son las reglas de integridad adicionales. Cules son las reglas de integridad adicionales? El primer caso de reglas de integridad adicionales es lo que llamamos cotas de la cardinalidad, en las cuales se exhibe una cardinalidad mnima y una mxima, en la forma que se ejemplifica:

aqu la asociacin Imparten tiene una cardinalidad acotada 0: 5 que significa que un profesor puede impartir desde cero (cuando un semestre se dedica a la investigacin o algn posgrado) hasta cinco cursos (que representa la carga mxima para un profesor de tiempo completo). En el caso de la asociacin Inscriben, la informacin que nos brindan las cardinalidades acotadas se interpretan como: Un alumno debe inscribirse al menos a uno y cuando ms a siete cursos. En un curso deben inscribirse cuando menos tres y a lo ms cuarenta alumnos.

Adems de las cotas de cardinalidad (que son de hecho una ampliacin a la notacin de la cardinalidad que habamos manejado hasta este momento), existen reglas para las que no hay una notacin en el modelo. Estas reglas se especifican en trminos de predicados o expresiones lgicas que algunos atributos deben cumplir. En caso de que existan ciertas condiciones que relacionen valores de los atributos de una o ms entidades o asociaciones, para enriquecer nuestro modelo de datos, debemos anexar una lista de estas condiciones. A continuacin se presenta una serie de ejemplos de reglas de integridad adicionales, en los que la pareja Entidad.Atributo denota un atributo de una entidad (o asociacin). Curso.FechaInicial <= Curso.FechaFinal La fecha final del curso debe ser mayor o igual a la fecha inicial. Empleado.Sueldo < Jefe.Sueldo El sueldo del empleado debe ser menor que el de su jefe. Suma(Embarque.Cantidad) <= Pedido.Cantidad La suma de las cantidades de los embarques no deben exceder la cantidad del pedido. Caracterstica.LimiteInferior <= Medicion.Valor <= Caracterstica.LimiteSuperior El valor de la medicin debe estar comprendido entre el lmite inferior y el superior de la caracterstica.

Cmo buscar reglas de integridad adicionales? No existe una "receta" para determinar las reglas de integridad adicionales, pero una gua importante para buscarlas, consiste en analizar los recursos escasos o crticos y la forma en que se restringen: Restricciones de recursos humanos: capacidad de carga de trabajo, delimitacin de responsabilidades, distribucin del salario, consideraciones fiscales y legales. Restricciones ecolgicas: volmenes de desperdicios, verificaciones de emanaciones y emisiones, condicionantes. Restricciones de tiempo: en qu perodos es vlido realizar una transaccin o programar un recurso, evitar traslapes.

Restricciones de instalaciones: de qu aulas se dispone, cul es su capacidad, con qu lneas de produccin se cuenta, cul es su volumen de produccin. Restricciones de transporte: con cuantas unidades se cuenta, cul es su capacidad, en qu forma pueden combinarse los embarques. Restricciones de recursos financieros: verificaciones presupuestales, transferencias restringidas, prioridades de gastos, distribucin del salario o las utilidades. Restricciones de recursos materiales: volmenes de pedidos, tiempo de surtido, criterios de seleccin de proveedores.

Reglas de traslado del Modelo Entidad-Relacin al modelo relacional Para instrumentar un Modelo Entidad - Relacin en una base de datos relacional, es necesario traducir el modelo a tablas. Para definir las tablas, utilizaremos la notacin: nombretabla(nombrecolumna1,nombrecolumna2,nombrecolumna3, ....,nombrecolumnan) para especificar una tabla. Las columnas subrayadas constituyen la llave de la tabla, es decir una columna o conjunto de columnas tales que conocido su valor se determina univocamente el rengln de la tabla del que se trata, es decir, los valores de la columna o combinacin de valores de las columnas subrayadas son nicos en la tabla. El procedimiento de transferencia es el siguiente: 1. Por cada entidad se define una tabla nombrada igual que la entidad, cuyas columnas corresponden uno a uno (y se llaman igual) a los atributos de la entidad. El identificador de la entidad corresponde a la llave primaria de la tabla. IMPORTANTE: si no existe un identificador obtenido del anlisis, en este punto se debe optar por crear una llave primaria "artificial" (un nmero o cdigo creado) que garantice la unicidad de identificacin de las tuplas. 2. Por cada asociacin del MER con cardinalidad N:N se define una tabla cuyas columnas corresponden a los identificadores de las entidades que intervienen en la asociacin, ms los atributos de la asociacin misma. La llave primaria de la tabla creada corresponde a la concatenacin de las llaves primarias de las tablas de las entidades participantes en la asociacin (en algunos casos, por cuestiones de eficiencia, puede convenir agregar una llave primaria

"artificial", sin dejar de asegurar la unicidad de la llave formada por la concatenacin de las llaves de las entidades participantes) 3. Por cada asociacin del MER con cardinalidad 1:N se hace lo siguiente: sea A la entidad conectada con cardinalidad 1 y B la entidad conectada con cardinalidad N, dadas las tablas de A y B obtenidas en el paso 1, deber agregarse a la tabla de B, la llave primaria de la tabla de A. Para aplicar el procedimiento en un modelo abstracto (sin asociarlo con un caso particular), considrese el siguiente MER:
x1 a1 c1

A
a2 1 a3

X
x2

c2 c3 c4

Y
b1 b2 N

Su traduccin al MR, siguiendo los pasos, sera: 1. Crear las siguientes tablas: A(a1,a2,a3) B(b1,b2) C(c1,c2,c3,c4) ntese que se han subrayado a1, b1 y c1 para denotar que son la llave primaria de la tabla, por representar el identificador de la entidad. 2. Se agrega la tabla: X(a1,c1,x1,x2) para representar la asociacin X, ya que tiene cardinalidad N:N. Ntese que se incorporan llos identificadores de las entidades A y B y que la concatenacin de ambas, constituye la llave de la tabla X; adems se incluyen como columnas de la tabla, los atributos propios de la asociacin X. 3. Se modifica la tabla B, agregando la llave de la tabla A, para representar la asociacin Y con cardinalidad 1:N:

B(b1,b2,a1) ntese que a1 no forma parte de la llave primaria de B y que la asociacin Y no implica la creacin de una nueva tabla en el modelo. El MR resultante es el siguiente: A(a1,a2,a3) B(b1,b2,a1) C(c1,c2,c3,c4) X(a1,c1,x1,x2) Reglas para manejar los elementos adicionales del MER: Relaciones ISA. Las relaciones ISA son 1:1. Como caso particular, de las relaciones 1:N, las tablas que representan a las entidades generalizadores, heredan sus identificadores a las tablas que representan entidades especializadoras. La llave primaria de la entidad generalizadora y las especializadora(s) es la misma. Para el MER abstracto que se ilustra a continuacin:

g1 g2

g3

ISA a1 a2

ISA b1

Ea

Eb

Los esquemas del MR correspondiente son:

G(g1,g2,g3) Ea(g1,a1,a2) Eb(g1,b1)

Entidades fuertes y dbiles Como casos particulares de relaciones 1:N, las entidades fuertes heredan su identificador a las entidades dbiles. La llave primaria de la tabla que representa una entidad dbil incluye tanto la columna que corresponde a la llave primaria de la entidad fuerte como una columna que distinga a las diferentes tuplas de la entidad dbil relacionadas con una misma tupla de la entidad fuerte. Para el MER abstracto que se muestra:

f1

F
f2

d1 d2

Los esquemas del MR correspondientes son:

F(f1,f2) D(f1,d1,d2)
Roles Cuando usamos roles para manejar relaciones reflexivas (de una entidad consigo misma) o mltiples relaciones entre una pareja de entidades, la herencia de identificadores a las tablas correspondientes se hace con el algoritmo general antes presentado, con la diferencia de que los roles se utilizan para nombrar las columnas de identificadores heredados que juegan diferentes papeles. Para el MER abstracto que se ilustra:

e1 e2

E
N

RolDe
N

r1

R
r2

Los esquemas del MR correspondientes son: E(e1,e2) R(e1,RolDeEe1,r1,r2) Ntese que en este caso el algoritmo general nos llevara a una tabla con dos columnas llamadas e1, lo cual es invlido; el rol nos ayuda a definir un nombre distinto para la columna que indica que R asocia dos elementos de E. DIFERENCIA ENTRE EL MODELO RELACIONAL Y EL MODELO ENTIDAD RELACIN
El modelo entidad relacin tenemos: Conjunto de entidades Personas Conjunto de relacione Trabaja Conjunto de relaciones Departamentos El modelo relacional tenemos: Tabla: Personal Tabla: Trabaja Tabla: Departamentos El modelo entidad relacin unos son conjuntos de entidades y otros son conjuntos de relaciones y en el modelo relacional modelo relacional todas son relaciones.
RELACIONES

RELACIN: Es un subconjunto del producto cartesiano de una lista de dominios. Un dominio es simplemente un conjunto de valores.

El producto cartesiano de dominios: D1, D2, D3,............., DK que se escribe como: D1 X D2 X D3 X............X DK es el conjunto de todas las K tuplas (V1, V2, V3,.............VK), tales que V1 estn en D2, V3 est en D3 y Vk est en Dk. Ejemplo:

K=2 D1={0,1} D2={a, b, c}

El producto cartesiano D1 X D2= { (0,a), (0,b), (0,c), (1,a), (1,b), (1,c),} De ste producto cartesiano se puede obtener 64 relaciones dos de las cuales son las siguientes: R={(0,a), (1,a)} Es una relacin que consta de 2 tuplas de grado 2. S={( 1,a), (1,b), (1,c)}Es una relacin que consta de 3 tuplas de grado 2. NOTA: Grado es el nmero de elementos que tiene cada tupla. Se recomienda al lector la resolucin de los siguientes ejerccios: D1=(rojo, verde, caf) D2=(margarita, clavel) D3=(amor, odio, tristeza)

MANEJO DE DATOS El manejo de datos se maneja fundamentalmente con el manejo de los lenguajes de base de datos. Los lenguajes de la base de datos se puede presentar de manera formal o de manera comercial. Los lenguajes de menea formal se clasifican en: Algebra relacional Clculo relacional El clculo relacional a su vez tiene dos divisiones: Clculo relacional basado en tuplas. Clculo relacional basados en dominios. Ejemplos: Soporte de los lenguajes comerciales LENGUAJES FORMALES
- Algebra relacional

- Clculo relacional basado en tupla - Clculo relacional basado en dominios

LENGUAJES COMERCIALES -SQL -SQL, QUEL -QBE En los lenguajes formales en el manejo de los datos se centra bsicamente en consultas, sin embargo se les ha hecho modificaciones para realizar las operaciones de insercin, eliminacin y actualizacin. Los lenguajes comerciales soportan todas las operaciones anteriores. BASE DE DATOS RELACIONAL Repitiendo la definicin, una base de datos relacional, es una base de datos que es percibida por sus usuarios como una coleccin de tablas (y nada ms que tablas ). La siguiente figura (coleccin de tablas) muestra un ejemplo de lo que es una base de datos relacional, por supuesto, llamada FACTURACIN DE UNA TIENDA COMERCIAL. Se usar sta base de datos para la mayora de los ejemplos en esta unidad. La base de datos facturacin consiste: Tabla Empleados
NO_EMPL NOMB_EM PL ANGEL MIRNA TOMAS PAOLA JAIME CIUDAD TELEFON O
91(8)352-46-90 91(933)608-70 91(148)101-98 91(8)338-5050 91(771)130-73

SALARIO COMISION

EMPL1 EMPL2 EMPL3 EMPL4 EMPL5

MONTERREY VILLAHERMO SA CHIHUAHUA MONTERREY PACHUCA

1300.00 1500.00 1300.00 2000.00 1700.00

5 10 5 20 5

Tabla Clientes

RFC_CLIE RFCM701010 RFCB710912 RFCCL720813 RFCCJ710423 RFCC711209

NOMB_CLIE MARY BETY LUIS JOSE CATY

CIUDAD MEXICO GUADALAJAR A MONTERREY MEXICO

TELEFONO 91(5)724-45-55 91(3)650-38-30 91(8)338-50-50 91(5)523-52-00 91(992)723-32

FAX 91(5)394-48-31 91(3)650-38-30 91(8)338-57-50 91(5)669-03-93 91(992)719-55

RFCJ701129 Tabla Partes

JUAN

MERIDA MONTERREY

91(8)376-3591

91(8)332-0904

NO_PARTE NOMB_PART E P1 PIJA P2 PIJA P3 RONDANA P4 RONDANA P5 TORNILLO P6 TORNILLO P7 TUERCA

MEDIDA
2 1 1 1

P_U

IVA

DESC

.25 .20 .20 .15 .15 .20 .05

15 10 10 0 0 15 20

0 0 10 15 30 0 20

Tabla Factura FACTURA FECHA 201 15/08/94 254 09/09/94 235 01/09/94 220 21/08/94 222 21/08/94 Tablas Pedidos
FACTU RA 201 201 201 264 264 235 235 235 235 235 220 222 222 222 NO_PART E P1 P2 P4 P3 P4 P3 P4 P5 P6 P7 P1 P1 P3 P4

NO_EMPL EMPL2 EMPL4 EMPL1 EMPL1 EMPL2

RFC_CLIE RFCL720813 RFCL720813 RFCL720813 RFCM70101 0 RFCC711203

IVA 4.75 3.60 8.80 8.75 9.90

SUMA_TOT 52.50 52.35 100.55 38.75 128.90

CANT S_PARC 1 100 25.00 50 10.00 100 15.00 200 40.00 100 15.00 100 100 20.00 200 15.00 100 30.00 500 20.00 100 25.00 200 100 25.00 300 50.00 20.00 60.00

DESC

0.00 0.00 2.25 4.00 2.25 2.00 2.25 9.00 0.00 5.00 0.00 0.00 2.00 9.00

S_PARC 2 25.00 10.00 12.75 36.00 12.75 18.00 12.75 21.00 20.00 20.00 25.00 50.00 18.00 51.00

IVA

3.75 1.00 0.00 3.60 0.00 1.80 0.00 0.00 3.00 4.00 3.75 7.50 1.80 0.00

SUMA_T OT 28.75 11.00 12.75 39.60 12.75 19.80 12.75 21.00 23.00 24.00 28.75 57.50 19.80 51.00

UNIDAD IV ALGEBRA RELACIONAL

INTRODUCCIN Es una coleccin de operaciones sobre las relaciones (tablas). Cada operador del lgebra relacional toma una o dos relaciones como entradas produce nueva relacin como salida; a esto se le llama la propiedad de Clousure del lgebra relacional. Por medio de esta propiedad es posible tener expresiones anidadas. Ejemplo: Sean A; B, C, relaciones y alfa, beta, gama operadores binarios del lgebra relacional Entonces: A alfa B es una expresin relacional. Donde: A y B son relaciones de entrada del operador alfa A alfa B es la relacin de salida (A beta B) gama C es otra expresin relacional. Donde: A beta B es una expresin relacional anidada A y B son las relaciones de entrada del operador beta y A beta B es la relacin de entrada junto con relacin C para operador gama. (A alfa B) gama (C beta D) es otra expresin relacional. La interpretacin se deja al alumno OPERADORES Los siguientes ocho operadorews constituyen el conjunto de operadores del lgebra relacional. UNIN La unin de dos relaciones A & B se representa por:

A UNIN B Y constituye una relacin en el que todas las tupla pertenecen a una o ambas relaciones. A & B deben necesariamente ser compatibles. Dos relaciones se dicen que son compatibles si y solo si tienen los mismos atributos. Ejemplo: Sea A l conjunto de las tuplas de clientes que estn en Mxico. RFC_CLIE NOMB_CLIE CIUDAD TELEFONO RFCM701010 RFCJ710424 MARY JOSE MXICO MXICO 91(5)724-45-55 91(5)523-52-00
FAX

91(5)394-48-31 91(5)669-03-93

Y sea B el conjunto de la tuplas parte P1 RFC_CLIE NOMB_CLIE RFCM701010 MARY RFCL7720813 LUIS RFCC711209 CATY Entonces, A UNIN B RFC_CLIE NOMB_CLIE RFCM701010 MARY RFCL7720813 LUIS RFCC711209 CATY RFCJ710424 JOSE

de clientes de aquellos clientes que compraron la

CIUDAD MXICO MONTERREY MERIDA TELEFONO 91(5)724-45-55 91(8)338-50-50 92(992)723-32 FAX 91(5)394-48-31 91(8)338-57-50 91(992)719-55

CIUDAD MXICO MONTERREY MERIDA MXICO

TELEFONO 91(5)724-45-55 91(8)338-50-50 92(992)723-32 91(5)523-52-00

FAX 91(5)394-48-31 91(8)338-57-50 91(992)719-55 91(5)669-03-93

Es el conunto de todas las tuplas de clientes que ya se que eestn en Mxico o que hayan comprado la parte P1 /o ambos). La relacin resultante tiene los mismo atributos que las relaciones de entrada. A la expresin el conjunto de las tuplas de clientes de aquellos se sustituir po la tabla de todos los clientes y as ejemplo, la expresin de ejemplo quedara sea A la tabla de todos los clientes que estn en Mxico. Esta sustitucin se debe a que es ms prctico y expresa ms claramente la peticin del usuario. INTERSECCIN La interseccin de dos relaciones A & B representada por: A INTERSECT B Constituye una relacin en elque todas las tuplas pertenecen a la relacin A pero no a la relacin B.

DIFERENCIA La diferencia de dos relacioens A & B representada por: A MINUS B Constituye una relacin en la que todas las tuplas pertenecen a la relacin A pero no a la relacin B. PRODUCTO CARTESIANO El producto cartesiano de dos relaciones A & B representado por: A TIMES B Constituye un conjunto de todas las tuplas t, tales que es la concatenacin de una tupla a que pertenece a A y una tupla b que pertenece a B. La concatenacin de tupla a (a1, a2, a3,...,am) y la tupla b(b(m+1), b(m+2), b(m+3),...,b(m+n))
Nota: La relacin que se deriva del producto cartesiano no debe tener nomnre de atributos duplicados; esto es una regla.

SELECCIN Sea Teta una operacin de comparacin escalar valido, por ejmplo (=,<>, >=,...,etc.).La seleccin de la realacin R sobre atributos X e Y se representa por: R WHERE R . X Teta R.Y La expresin es el conjunto de todas las tuplas de t de R tales que si la comparacin de la tupla t. X Teta t . Y es verdadero, es parte del conjunto de la seleccin, si no es verdadero no es parte de la seleccin t los atributos X e Y deben estar definidos en mismo dominio & la comparacin Teta debe tener sentido en ese dominio. Un valor constante puede estar especificado en lugar de cualquier de los atributos X e Y.
PROYECCIN

En la proyeccin de una relacin R sobre los atributos X, Y,....,Z se representa por: R[X, Y,....Z] Y es el conjunto de todas las tuplas: (x,y,....z) Tales que la tupla t aparece en R con el valor x del atributo X, el valor del atributo Y, el valor z del atributo Z. Esto es el conjunto obtenido por la seleccin de atributos especficos en orden izquierda a derecha a como estn puesto los atributos en la operacin proyeccin R{X,Y,.....Z} y aliminada la informacin duplicada de aquellas tuplas con los mismos atributos, pueden verse entonces como una seleccin vertical.

JOIN (PRODUCTO NATURAL) Sea A & B dos relaciones, la unin natural (_JOIN) nos permite combonar una proyeccin de una seleccin de un producto cartesiano entre ambas relaciones en una sola operacin y se representa por: A JOIN B La unin natural efectua el producto cartesiano, se realiza una seleccin forzada la igualdad deaquellos atributos que aparecen en ambas relaciones (atributos comunes) y finalmete se lleva la proyeccin eliminando los atributos que estan duplicados. Formalmente la unin natural de dos relacioenes A y B se define como: ((A TIME B) WHERE A.AX=B.BX AND A.AY=A.BY AND,...,A.AZ=
CLCULO TUPLAS

Cuando escribimos una expresin en lgebra relacional, damos una secuencia de procedimientos que genera la respuesta a nuestra consulta. El clculo relacional de tuplas, es cambio, es un lenguaje de consultas no procedimental. Describla informacin deseada sin dar un procedimiento especfico para obtener informacin. Una consulta en el calculo relacional de tuplas se expresa como
{t /P(t)}

es decir, el conjunto de todas las tuplas t, tal que el predicado P, es verdadero para t. Siguendo la notacin anterior, usamos t[A] para representar el valor de la tupla t en el atributo A, y usamos t E r para indicar que la tupal t esta en relacion r.

El clculo relacional representa una alternativa a el lgebra relacional para el manejo de los datos en este modelo la diferencia entre las dos es la sigueiente: Mientras que el algebra provee una coleccin de operraciones explcitas (join, proyeccin, etc) que son usadas para construir algunas relaciones deseadas el clculo meramente provee una notacin para formular la definicin de la relacin deseada. El clculo simplemente establece lo que es el problema y el {algebra proporciona un procedimiento para resolver ese problema. El lgebra y el clculo son expresiones equibalente, i.e. que para cada expresin en lgebra existe una exresion en clcilo y viceversa.

La caacteristica fundamental del clculo se basa en la nocin de variable de tupla, tambin conocida como variable de rango. Brebemente, una variable de tupla es una variable que varia sobre alguna relacin, i.e. una variable cuyos unicos valores permitidos son tuplas de esta relacin. En otras plabras, si una variable de tuplaT varia sobre la relacin R, entonces en cualquier momento, T representa alguna tupla t de R. Devido a su dependencia de la nocin de las variables de tuplas (y para distinguirla del clculode dominios vease mps adelante), el clculo relacinal oroginal a llegado a conocerse como clculo de tuplas. Lacroix y Pirote propusieron un clculo relacional alterno llamado un clculo de dominios, en el cal las variables de tuplas son remplazadas por variables de dominio, i.e. variables que variasobre un domonio en lugade una relacin. CLCULO RELACIONAL ORIENTADO A TUPLAS VARIABLES DE TUPLA Una variable de tupla es definida por el siguiente enunciado RANGE OF T IS X1; X2; .....; Xn Donde T es una variable de tupla y X1, X2,.........Xn son expresiones de clculo de tupla, que representan las relaciones R1, R2, ........Rn (Digamos). Las relaciones R1, R2, ........Rn deben de ser todas compatibles. La variable de tuplaT varia sobre la unin de todas las relaciones (de la una a la n).Por supuesto, si la listde expresiones identifica solamente una relacion R (que normalmente es el caso), entonces, la variable de tupla T varia sobre las tuplas de esa sola relacin. Las siguientes definiciones de variables tienen sentido: RANGE OF RX IS R RANGE OF RY IS R RANGE OF RZ IS R RANGE OF SX IS S RANGE OF SY IS S RANGE OF SZ IS S. Donde R y S son relaciones RX, RY y RZ son variables de tuplas sobre la relacin R. SX, SY, SZ son variables de tuplas sobre relacin S y RX.A, RX.B...,RX.C son atributos de la variable de tupla RX. VARIABLES LIBRES Y LIMITADAS Las variables de tuplas se clasifican en dos: Libres y Limitadas.

Las limitadas son aquellas que tienen el cuantificador de existencia (EXIST) O el cuantificador universal(FORAL) las libres sn todas aquellas variables que no son limitadas. EXPRESIONES Una expresin en clculo de tuplas tiene la siguiente forma: T.A, U. B,......,V.C WHERE wff Donde t, u, ....v son: dos variables de tupla A,B......C: son atributos sobre las variables de tupla respectiva y WFF es una formula bien formada (well-Formed-Formula) que contienen exactamente a T, U, ...,V como varibles libres. WFF pude ser definida usando gramaticaBNF (Backus Normal Form) como sigue: Wff::=comparacin /(wff)/wff and wff/wff or wff/ EXIST var_Tupla(wff)/ FORALL var_tupla (wff) El valor de esta expresin esta definida como una proyeccin del subconjunto del producto cartesiano T X U X.....X V (Donde T U.....,Vvarian sobre todos sus posibles valores ) para la cual wff se evalua, verdadera, o si WHERE wff es omitida proporciona una proyeccin sobre todo el producto cartesiono
IV. MODIFICACIN DE UNA BASE DE DATOS

La modificacin de la base de datos se expresan usando el operador asignacin. Las asignaciones se hacen a relaciones ya existentes en la base de datos. Una solicitud de eliminacin se expresa de forma muy parecida a una consulta. Sin embargo, en vez de presentar tuplas al usuario, quitamos lasd tuplas seleccionadas de la base de datos. Slo podemos eliminar tuplas completas ; no podemos eliminar nicamnete valores de determinados atributos. En lgebra relacional, una eliminacin se expresa as. R r ----E Donder r es una relacin y E es una consulta del lgebra relacional. Debajo se presentan varios ejemplos de solicitudes de eliminacin en lgebra relacional. -Eliminar todas las cuentas de Smith. Depsito depsito --- nombre-cliente ="smith" (depsito) -Eliminar todos los prstamos con nmero de prstamos entre 1300 y 1500. Depsito (depsito) depsito -- nmero-prstamo

>=1300 y nmero_prstamo<=1500

-Eliminar todas las cuentas de las sucursales situadas en Needhaam. r1 ciudad-sucursal = "Needham" (depsito |X|sucursal) r2 II nombre-sucursal, nmero-cuenta, nombre-cliente, saldo(r1) depsito depsito --r2 Ntese que en el ejemplo anterior simplificamos la expresin usando asignacin a relaciones temporales(r1 y r2). INSERCIN Para insertar datos en una relacin, bien especificamos la tupla que se va a insertar o escribimos una consulta cuyo resultado sea un conjunto de tuplas que se va insertar. Obiamente, en este ultimo caso, los valores de los atributos para las tuplas insertadas deben ser del mismo orden . En lgebra relacional una insercin se expresa as: r r E Donde r es una relacin y E es una expresin del lgebra relacional. La insercin de una sola tupla se expresa haciendo que E sea una relacin una relacin constante que contiene una tupla. Supngase que queremos insertar el hecho de que Smith 1200 dlares en la cuenta 9732 de la sucursal Perrydge.Escribimos: Depsito deposito {("Perryridge", 9732, "Smith" , 1200)} De forma ms general, podramos querer insertar tuplas basadas en el resultado de una consulta. Supongase que queremos proporcionar todos los clientes con prestamos en la sucursal Perryridge y una cuenta de ahorros de 200 dlare. El nmero de prestamos servir como nmero de cuenta para las nuevas cuentas de ahorro. Escribimos: r1 ( nombre-sucursal="Perryridge" (prstamo) r2 Iinombre-sucursal, nmero -prstamo, nombre-cliente(r1) depsio depsito (r2 x{(200)}) En vez de especificar una tupla como hicimos anteriormente, especificamos varias tuplas. Cada tupla tiene nombre-sucursal (Perryridge), un nmero-prestamo(que sirve como un nmero de cuenta para la nueva cuenta y el saldo inicial de la nueva cuenta (200 dlares). ACTUALICZACIN En ciertas ocasiones podemos querer cambiar un valor en una tupla sin cambiar todos los valores de la tupla. Si hacemos estos cambios usando eliminacin e insecin, es posible que no podamos conservar los valores que no queremos cambiar. En lugar de ello, usamos el operador actualizacin

 A E(r)

Donde r es el nombre de una relacin con atributo A, al cual se le asigna el valor de la expresin E. La expresin E es cualquier expresin aritmtica que implica constantes y atributos en la palnificacin de relacin r. Para ilustrar el uso del operador , supngase que se estn haciendo pagos de intereses y que todos los saldos se van a sumentar en un 5 por 100. Escribimos:
saldo saldo*1.05(depsito)

La sentencia anterior se aplica una vez a cada tupla de depsito. Supongamos ahora que las cuentas con saldos mayores de 10 000 dlares reciben el 6 por 100 de inters mientras todas las dems reciben el 5 por 100. Escribimos:
saldo saldo*1,06(saldo<10000(depsito)) saldo saldo*1,05(saldo<=10000(depsito))

Obsrvese que en el ejemplo anterior es importante el ordenn en el q ue aplicamos las expresiones de actualizar. Si cambiamos el orden , una cuenta cuyo saldo estuviera justo por debajo de 10000 dlares recibiran El 11,3 por 100 de inters!
V.VISTAS Cualquier relacin que no es parte del modelo conceptual, pero se hace visible al usuario como una <<relacin virtual>> , se llama vista . es posible tener un gran nmero de vistas sobre cualquier conjunto de relaciones reales dado.

Puesto que las relaciones reales en el modelo conceptual pueden modificarse, generalmente no es posible almacenar una relacin correspondiente a una vista . En cambio, una vista debe volverse a calcular para cada consulta que se refiere a ella. Cuando se define una vista, el sistema de base de datos debe almacenar la definicin de las vistas. As , la definicn de vista no es una expresin del lgebra relacional. Mas bien , una definicin de vista hace que se guarde una expresin que se va a sustituir en consultas usando la vista. Definicin de vista: Una vista se define usando la sentencia create view para definir una vista debemos darle un nombre y presentar la consulta que clcula la vista. La forma de la sentencia create view es

create view u as <expresin de consulta> donde <expresin de consulta > es cualquier expresin legal de consulta en lgebra

relacional. El nombre de la vista se representa por u. Como ejemplo, considrese la vista que consta de sucursales y sus clientes. Supngase que queremos que esta vista se llame todos-clientes. Definimos esta vista como sigue:
create view todos-clientes as II nombre-sucursal, nombre-cliente (depsito) nombre-sucursal, nombre-cliente (prstamo)

Una vez que se ha definido una vista, el nombre de la vista puede usarse para referirse a la relacin virtual que genera la vista. Los nombre de la vista pueden aparecer en cualquier lugar que pueda aparecer el nombre de una relacin. Usando la vista todos -clientes podemops definir a todos los clientes de la sucursal Perryridge escribiendo :
nombre-cliente( nombre-sucursal="Perryridge" (todos los clientes))

UNIDAD V NORMALIZACIN
Normalizacin

Una simple vista de normalizacin 1. Cada tabla debe describir uno y solo un tipo de objeto cosa. 2. Cada registro debe contener informacin acerca de estos objetos. 3. Cada campo en la tabla debe describir un hecho acerca de dicho objeto. 4. Una lista de atributos similares (campos) dentro de una tabla indica que no es normal.
Siete pasos para la normalizacin

1. Identificar todos los objetos importantes y generar una tabla para cada uno. 2. Identificar las relaciones uno a muchos entre los objetos(tablas). 3. Generar llaves nicas para cada tabla y establecer relaciones entre las tablas citadas en el paso dos. 4. Conforme usted agrega cada campo a la tabla, asegrese que describe solo un atributo acerca de un objeto. 5. Si usted describe un nuevo objeto necesita tener un numero independiente de atributos acerca de un objeto regrese al primer paso. 6. Si la relacin es uno a uno verifique si esta utilizando dos tablas para describir una cosa. 7. Si la relacin es muchos a muchos verifique si usted necesita tener una tabla independiente para describir la relacin. Nuestros principios originales de Base de Datos disearon estos pasos. Note sin embargo que la normalizacin no habla acerca de recuperacin, validacin, concurrencia y los similares de datos no relacionados (i.e. ndices para obtener datos de una sola tabla).

Si usted sigue estas reglas meticulosamente usted no necesita saber5 mas acerca de normalizacin. La descripcin detallada de cada forma proporciona una mejor idea acerca de algunos de los principios de normalizacin.
Primera Forma Normal

Descripcin General

Supongamos que usted desea almacenar informacin acerca de el representante de ventas una vez que la tabla fue diseada, la siguiente estructura de base de datos podra ser generada:
Tablas SalesRep

Nombre del campo Hire-Date Product1sls Product2sls Product3sls Sales-rep Slsname Slsquota Slsrgn Slstitle

Etiqueta Data hired Product 1 sales |product 2 sales Product 3 sales Sales Rep Name Yearly Quota Region Title

Formato DT Dat 99/99/99/ Dec->>,>>9.99 Dec->>,>>9.99 Dec->>,>>9.99 Cha !(3) Cha x(30) Dec->,>>>,>>9 Cha x(8) Cha x(30)

A de los campos tienen sentido: hide-date, title, regin, quota. En una inspeccin mas minuciosa nosotros vemos una serie de nombres de campos de los cuales son muy similares. Los campos produt1sls, product2sls, etc., representan el volumen de ventas del representante de ventas para cada producto. Cualquier lista serie de nombre de campos los cuales son muy similares en apariencia son un indicador de las necesidades de correccin de la primera forma normal (regla numero cuatro de una simple vista de normalizacin mencionada anteriormente.

Aunque una compaa puede tener actualmente solo tres productos. Murphy predice que algn da (concretamente al da siguiente del que usted instale su software) la compaa tendr cuatro ( regla numero cinco de los siete pasos para la normalizacin. Este es uno de los muchos problemas de una tabla que no sea primera forma normal; no puede manejar un cambio en el ambiente. Otro problema es que el cdigo tiene que ser inteligente. Esto es tiene que saber el nombre de el campo para el primer producto (product1 sls), el segundo producto etc..., entonces si la compaa agrega un nuevo producto tanto en el diseo de la base de datos como el cdigo deben ser modificados. Ejemplo
Por ejemplo, supongamos que el registro para nuestro primer representante de ventas Buba se ve de la siguiente manera:

Sales Rep: Name: Region: Title: Yearly quotas: Product 1 Sale: Product 3 Sale:

BBB Brawn Buba B. East Sales Representative 250,000 Data hired: 100.00 Product 2 Sale: 300.00

06/01/52 200.00

Para poder obtener las ventas totales para Buba, uno tendra que hacer lo siguiente: Define variables totalSales as decimal. find first salesrep. TotalSales=product1 sls + product2sls + product3 sls. Display TotalSales with side-label. El resultado seria el siguiente: Total sales:600.00
Como la misma prueba para encontrar todas las ventas para el producto 1 en el sistema el programa tendra que leer lo siguiente:

Define variable prod1sales as decimal. For each salesrep:

Prodd1 sales=Prod1sales + product1 sls. End. Display Prod1sales. Para efectos de nuestro curso solo haremos7.100.00 ProdSales: referencia al Enfoque Relacional. Este tiene todo tipo de limitaciones. Cuales de los elementos del inventario es el producto 1? De que manera vincula el campo product1 sls con el elemento de inventario correcto? Los problemas con este diseo son demasiados. Deque manera se pone una tabla en Primera Forma Normal? Para poner la tabla en Primera Forma Normal, elimine los grupos que se repiten en la tabla. Compare esta versin anterior para ver que tan ordenada esta.
Tabla SalesRep

Nombre del campo Hire-Date Product1sls Product2sls Product3sls Sales-rep Slsname Slsquota Slsrgn Slstitle

Etiqueta Data hired Product 1 sales |product 2 sales Product 3 sales Sales Rep Name Yearly Quota Region Title

Formato DT Dat 99/99/99/ Dec->>,>>9.99 Dec->>,>>9.99 Dec->>,>>9.99 Cha !(3) Cha x(30) Dec->,>>>,>>9 Cha x(8) Cha x(30)

El siguiente paso es generar una tabla por separado llamada Sales, vinculada con Salesrep por la llave del campo sales-rep y con el elemento por la llave del campo temnum. La nueva tabla Sales puede verse de la siguiente manera:

Nombre del Campo Etiqueta Item-Num Item-Name Item-Num Item-Name

Formato DT Int 99999 Cha x(15)

Valor inicial 0 0

Name Sales-Rep YTDSales Caractersticas

Salesman Name Sales Rep

Cha x(25) Cha !(3)

0 0

Year To Data Sales Dec->>,>>9.99 0

En esta primera forma normal usted puede tener tantos productos como desee. La primera vez que un vendedor hace la venta de un producto un nuevo registro es actualizado. Adems el usuario ahora puede encontrar todas las ventas de un representante de ventas de todas las ventas de cualquier elemento independientemente de quien lo vendi. En esta tabla el vinculo con salesrep en el campoSalesRep. El campo tem-Num identifica la parte y el campo Name la describe. (El campo tem-Num vinculara la parte con la tabla de inventario). Vinculando as mismo los campos YTDsales product1 sls, product2sls, etc. Ejemplo Prompt-for salesrep.sales-rep
Supongamos que Buba vende el articulo 1 el cual es aletas para nadar. El cdigo quiz se vera de la siguiente manera:

Validate (can-find(first salesrep using sales rep), Sales Code not on file.). find salesrep using sales-rep no-lock no-error. Display salesrep.rep-name Prompt-for item. item-num Validate (can-find(first item using item-num),Item is not on file.). Find item using item-num no-lock no-error. Display item-name. Find first sales where sales. sales-rep =salesrep.sales-rep And sales.item.num =item. item-num No-error. If not available (sales) Then do: Create sales Assign Sales.item-num =item.item-num

Sales.item-name =item.item-name Sales.sales-rep End. /*create*/ Prompt-for sales.ytdsales. Assign ytdsales. El frame se vera de la siguiente manera: Sales-rep BBB Rep-Name Brawn.Buba B. Item-num 00002 Item-Name Tennis racquet Sales 100.00 =salesrep.sales-rep Sales.name =isalesrep.slsname.

En este diseo los datos son inteligentes: ni el software ni la base de datos tiene que saber el numero de elementos para poder actualizar las figuras de ventas. El proporcionar esta informacin, y el trabajo del software es validar lo que el usuario ha introducido encontrar las relaciones apropiadas y almacenar los nuevos datos. Pasos para generar la primera forma normal Revise cada dato almacenado. 1. Existe mas de un campo en la tabla el cual refiere el mismo atributo (como ventas) 2. Separa las referencias repetidas en otras tablas. 3. Genere un vinculo de la tabla primaria a la tabla secundaria utilizando la llave que nicamente identifica al ndice de la tabla primaria.

Segunda forma Normal

Eliminar Datas Redundantes

Descripcin general Supongamos que la base de datos Customer tiene las siguientes estructuras:
Customer

Nombre del campo Etiqueta Adsress Address2 City Contact Curr-bal Cust-Num Discount Max-Credit Mnth-sales Name Phone Sales-region Sales-rep St Tax-no TermCode Termdesc Ytd.sls Zip Addr Addr2 City Contact Unpaid bal Cust Num Disc % Max Cred Mnth sls Name Tel num Sls rep Sls rep State Tax-num Terms Code Ytd sls Zip

Formato DT Cha x(20) Cha x(20) Cha x(12) Cha x(20) De->,>>>,>>9.99 Int >>>>9 Int >>9 Dec->,>>>,>>9 Dec->,>>>,>>9.99 Cha x(20) Cha x(8) Cha !(3) Cha xx Cha x(15) Int >>9 Dec->,>>>,>>9.99 Int 99999

Valor inicial 0 0 0 0 0 0 0 0 12 0 0 0 0 0 0 0 0 0

Cha (999)999-9999 0

Terms descry Cha x(20)

Dentro de esta tabla esta el campo termdesc, el cual describe los trminos de pago que se permiten normalmente al cliente. Una lista parcial de la tabla muestra lo siguiente: La pantalla se vera de la siguiente forma: Name Lift line Skiing Urpon Frisbee Hoops Croquet Co. Go Fishing Ltd Match point tennis 2% 10/Net 30 Net 90 2% 10/Net 30 Net 30 Net 60

Tipos de datos en una Base de Datos El almacenamiento tanto del cdigo terms as como la descripcin de terms es obviamente redundante. Sin embargo adems de la duplicacin de los datos, existen otros problemas menos evidentes causados por esta estructura. Supongamos que usted desea renombrar una de las categoras terms. Esto significa que usted tendr que cambiar cada descripcin en cada registro de cliente. Ejemplo
Por ejemplo, supongamos que el crdito se vuelve algo ajustado y su compaa decide cambiar todos los Net terms 30 a Net 15. supongamos no seria difcil de escribir:

For each customer where termdesc=Net 30. Termdesc=Net 15.

End. Sin embargo supongamos que existen algunos Net 30 terms los cuales fueron introducidos como Net 30. Este programa no funcionaria, usted tendra que agregar otra clusula (i.e. termdesc=net30). Y que hay de los terms que fueron grabados Net 30 days, etc. Para poder cambiar el contenido exacto de este campo para cada registro, para poder escribir el programa el cual cambiara los datos. O supongamos que el ultimo cliente terms Net 90 sale el negocio y debe ser eliminado de la base de datos. El cdigo y descripcin del terms Net 90 no aparecer en ningn lado en la base de datos ! Es fcil ver que adems de almacenar informacin redundante los datos que no estn en segunda forma normal tambin causan muchos otros problemas. Afortunadamente la solucin para estos problemas es sencilla: generar una tabla terms.

Nombre del campo Etiqueta TermCode TermDesc Terms Code

Formato DT Valor inicial Int >9 0 0

Terms Description Cha x(20)

For each terms: Display terms. End. Terms Code 1 2 3 4 Terms Description 2% 10 / Net 30 Net 30 Net 60 Net 90

Cada uno de los diferentes terms tiene un registro individual en la tabla. Una vez que se ha hecho el campo TermDesc puede ser eliminado de la tabla customer.
Esta normalizacin a la Segunda Forma resuelve todos los problemas descritos anteriormente. Si la descripcin para terms numero 2, net 30 debe ser cambiada a Net 15, usted solo tiene que encontrar un registro en la tabla terms y cambiarlo. El cambiar este registro no requiere de ningn conocimiento de clientes tiene estos terms, ni tampoco el software tiene que saber cual es la descripcin exacta de los terms. El usuario proporciona el cdigo y verifica que la computadora haya hecho la seleccin correcta. Adems de reducir la posibilidad de error el cambio para cada cliente es instantneo en el caso de cambiar la descripcin de terms en el registro del cliente de acuerdo al volumen de los registros podran llevarse un largo tiempo para el cambio y quedar en la posibilidad de bloqueo si las transacciones fueron delimitadas dentro de un mbito incorrecto. Y finalmente cuando el ultimo cliente como terms de 90 das es eliminado de la base de datos el cdigo terms de Net 90 aun permanece. El generar una base de datos en Segunda Forma Normal maneja mucho mas que solo eliminar datos redundantes. En terminologa de normalizacin si un atributo depende de solo parte de una llave compuesta colquelo en una tabla por separado. En terminologa normal si un campo depende de otro campo (la descripcin del terms es dependiendo del cdigo terms), ponga los valores relacionados en otra tabla utilizando la llave). Tercera Forma Normal Eliminar columnas que no son dependientes de la llave. Descripcin General Algunas veces existe informacin la cual es importante acerca de un objeto pero la informacin no esta directamente relacionada con el objeto. En otras palabras la informacin no es dependiente de la llave del objeto. Supongamos que la tabla se vera de la siguiente manera: Nombre del campo Etiqueta DT Formato Valor inicial Address Addr Cha X(20) 0 Address2 Addr2 Cha X(20) 0 City City Cha X(12) 0 Cust-num Cust-num Int >>>>9 0 Cust-po Cust-po Cha X(20) 0

Name Odate Order-num Phone Sales-rep Shp-via Slsname St Terms Zip

Name Order date Order num Sls phone Sls rep Ship-via Name State Terms Zip

Cha Dat Int Cha Cha Cha Cha Cha Cha Int

X(20) 99/99/99 >>>>9 (9999) 999-9999 (3) X(20) X(30) X(2) X(20) 99999

0 0 0 0 0 0 0 0 0 0

En esta versin de la tabla el cdigo sales-rep es almacenado en la tabla order as como el numero telefnico y nombre del vendedor. El nombre y telfono son informacin importante que uno debe saber cuando revisa una orden pero no son determinados por el numero de orden. En otras palabras no describen al representante de ventas pueden ser extrados de la tabla cuando sean necesarios para procesar una orden. Esto es bastante sencillo en PROGRESS:

For each order, salesrep of order:

Esto se lee en los registros de ambas tablas as como el telfono y nombre son tan accesibles como si fueran parte de la tabla order. En otro ejemplo supongamos que la tabla order se vea de la siguiente manera: Order-line Nombre del campo Etiqueta DT Formato Valor inicial Disc Disc% Int >>9 0 Item-num Item num Int 99999 0 Line-num Line num Int >>9 0 Order-num Order num Int >>>>9 0 Price Price Dec ->,>>>,>>9.99 0 Qty Qty Int ->>>>9 0 Qty-ship Ty ship Int ->,>>>,>>9 0 Sales-rep Sls rep Cha (3) 0 TotPrice Total Price Dec ->,>>>,>>9.99 0 Aqu el cdigo sales-rep no describe la order line si no que describe la orden en si. En este caso, debido a que cada order-line es un dependiente de orden la existencia del campo sales-rep en la tabla orden es suficiente, ya que usted puede citar lo siguiente: El campo Sales-rep nicamente describe esta relacin combinada. Otro principio de la tercera forma normal es que ningn campo debe ser funcionalmente dependiente de otro campo (qty) de la cantidad vendida y el precio. Debido a que este valor puede ser siempre determinado en tiempo de despliegue, no necesita ser almacenado. 1. Si un atributo no describe el objeto determinado por la llave coloque el atributo en una tabla por separado. 2. Si un atributo es derivado de los valores de uno o mas atributos dentro de la tabla, elimnalo. Base de datos aun mas que la normalizacin de la Tercera Forma puede ser concebida como: cada atributo debe ser un hecho acerca de la llave de toda la llave y nada mas que la llave. La Tercera Forma Normal satisface muchos requerimientos y frecuentemente es lo suficiente refinada para muchos escenarios de la base de datos. Sin embargo en algunos casos muchas relaciones complejas entre los datos justifican el normalizar una comn o de Tercera Forma Normal.

Cuarta Forma Normal ___Aislar Mltiples Relaciones Independientes Descripcin General En su amplia c0ompaia el historial de empleados es muy importante en el diseo inhiba el sistema, el registro de empleados contena grupos repetidos para almacenar los puestos: jobtitle 1 , jobtitle 2, etc. Una vez normalizados los datos, un jobhist es generado: Jobhist Nombre del campo Etiqueta DT Formato Valor inicial Employeedo Employee Number Int 99999 0 JobSkill Cha X(10) 0 Position Cha X(10) 0 Etc. Sin embargo al revisar el historial de varios empleados usted nota que el Job skill y el position en realidad son independientes: Employee Job skill Position 1 Salesman Asst Mngr Stocker Asst Mngr Manager Asst Mngr Manager Store Mngr En otras palabras de todos los job skills disponibles varios fueron relacionados por el empleado 1 mientras era asistente administrador. Adems por lo menos uno de los job skills tambin fue realizado mientras que el individuo fue administrador. Una mejor organizacin de estos dos datos seria generar dos tablas: una para job skills una para positions. Nombre del campo Etiqueta DT Formato Valor inicial Employee Employee Number Int 99999 0 Job skill Job skill Cha X(10) 0

Position Nombre del campo Etiqueta DT Formato Valor inicial Employeeno Employee Number Int 99999 0 Position Position Held Cha X(10) 0 Esto le permitir encontrar todos los trabajos de este empleado aso como todos sus positions. Adems usted ahora puede hacer una sola tabla de remisin de todos los individuos que han tenido alguna position en particular que son calificados para relacionar cierto trabajo. Debido a que estos dos conjuntos de datos no estn relacionados almacenarlos en tablas separadas puede

conservar espacios para datos y en general permite un acceso rpido y preciso a diferentes hechos acerca del empleado. Si existen relaciones que son verdaderas independientes colquelas en tablas por separado.

Quinta Forma Normal Aislar Mltiples Relaciones Relacionadas Semnticamente. Descripcin General Asumir que la pliza de la compaa es tener en existencia un articulo de cada color para cada tamao. Supongamos que usted ordena tres artculos camisa para mujer camisas para hombre y camisas para nios y que cada uno viene en rojo, blanco azul; pequea, mediana grande. In embargo, cada articulo solo tiene un numero de elemento ( y un precio, descripcin, etc) no importa su tamao o color. Item Nombre del campo Etiqueta DT Formato Valor inicial Item-num Item num Int 99999 0 Color Item color Cha X(10) 0 Desc Item Description Cha X(30) 0 Price Price Dec ->,>>>,>>9.99 0 Size Item size Cha X(10) 0 El ordenar un conjunto de elementos requerir de agregar 27 registros a la base de datos. 1 Mens Small Red 2 Mens Small White 3 Mens Small Blue 4 Mens Medium Red Etc. 10 Womens Small Red 11 Womens Small White 12 Womens Small Blue Etc. 19 Childs Small Red 20 Childs Small White 21 Childs Small Blue Debido a que la talla y color no estn relacionadas podemos separar estos registros de elementos en tres diferentes tablas: item, color talla, seria aplicable a los elementos en mano, pero son independientes uno del otro. Las nuevas estructuras de la tabla se veran de la siguiente manera: Item Nombre del campo Etiqueta DT Formato Valor inicial Item-num Item num Int 99999 0 Desc Item Description Cha X(30) 0

Price Price Dec ->,>>>,>>9.99 0 Etc. Color Nombre del campo Etiqueta DT Formato Valor inicial Color Item color Cha X(10) 0 Talla Nombre del campo Etiqueta DT Formato Valor inicial Size Item size Cha X(10) 0 Asumiendo que cada elemento fue ordenado en cada color y cada talla, tendra que haber solo nuevos registros en nuestra nueva base de datos: Mens Womens Childs Small Medium Large Red White Blue Supongamos que un fabricante agrego un Nuevo color Amarillo a esta lnea. En el diseo original, seria nuevo diseo, solo un nuevo registro necesita ser agregado (a la tabla color). Lo mismo se aplica si usted decide comprar tallas extra, pequeas, estilos maternidad. En realidad cuatro estilos en cuatro tallas y cuatro colores requeriran de 64 registros en la tabla original pero solo 12 en el nuevo sistema. Cuando usted considere que en el registro de elementos existe informacin lo cual no se necesita repetir: (peso, costo, descripcin, etc.), el repetir esta informacin para cada registro en un gran inventario seria excesivamente costoso en trminos de espacio de disco y velocidad de procesamiento. Aun si usted no ordenara cada talla de cada color, aun seria conveniente el generar una tabla de registros talla-color, quiz de la siguiente manera: Talla-color Nombre del campo Item-num Color Size Etiqueta Item num Item color Item size Dt Int Cha Cha Formato 99999 X(10) X(10) Valor inicial 0 0 0

Esta tabla tendra una entrada por talla, por color, pr item. Este diseo generara un registro de item contena talla y color. Sin embargo el almacenamiento total en el espacio del disco puede ser medido por el numero de campos de cada registro de elemento, los cuales no tiene que ser repetidos para poder describir el elemento. Flexibilidad es inmenso cuando este nivel de normalizacin es introducido. Puede haber consideraciones practicas, los cuales justifican el separar relaciones de muchos a muchos.

Tabla 2-2 Tabla no Normalizada con Mltiples Campos Duplicados. Cust Num Name Street Order Order Order Number 1 Number 2 Number 3 101 Jones, Sue 2 mill Ave. M31 M98 M129

102 103 104

Hand, Jim 12 Dudley St. M56 Lee, Sandy 45 School St. M37 Taan, Staeve 67 Main St. M41

Null M40 Null

Null Null Null

Aqu en lugar de un solo campo Order-Number existen tres campos separados pero duplicados para Order-Number (Order-Number1, Order-Number2 y Order-Number3). Esta informacin no es suficiente. Qu pasa si un cliente tiene mas de tres ordenes? Usted deber agregar un nuevo campo borrar el valor de un campo existente para hacer una nueva entrada. Es difcil estimar un numero mximo razonable de ordenes para un cliente. Si un negocio es de gran actividad quiz usted deber generar 200 campos de Order-Number para un registro. Tambin, si un cliente tiene 10 ordenes la base de datos contendr 190 valores invlidos para este cliente. Adems es difcil y se lleva tiempo el recuperar datos con campos repetidos. Por ejemplo para determinar que cliente tiene Order-Number M98, usted deber ver cada campo Order-Number individualmente (los 200 mas de ellos) en cada registro para controlar un igualador. Para reducir la tabla Customer a la Primera Forma Normal divdala en dos tablas mas pequeas, una tabla para almacenar solo la informacin del Customer (ver Tabla 2-3) y otra para almacenar solo informacin de la Order (ver Tabla 2-4). Tabla 2-3 Tabla Customer (Llave primaria) 101 Name Jones, Sue Hand, Jim Lee, Sandy Taan, Staeve Customer (Llave externa) 101 101 101 102 103 103 104 Street 2 mill Ave. 12 Dudley St. 45 School St. 67 Main St.

Order Num (Llave primaria) M31 M98 M129 M56 M37 M140 M41

Note que solo hay una instancia de un campo en la tabla Customer y Order y cada campo contiene exactamente un valor. El campo Cust-Num en la tabla Order se relaciona con el campo Cust-Num en la tabla Customer. Una tabla que es normalizada a la Primera Forma Normal Tiene las siguientes ventajas: Le permite generar cualquier numero de ordenes para cada cliente sin tener que agregar nuevos campos. Le permite consultar y clasificar datos para ordenes muy rpidamente debido a que usted solo busca un campo Order-Number. Utiliza el espacio en disco mas eficiente no se almacenan campos vacos.