INTRODUCCIN

a) Presentacin y contextualizacin En esta unidad aprender los conceptos principales sobre las bases de datos relacionales, archivos de datos, y la diferencia que existe entre ellos. Entender la importancia de los sistemas de informacin, as como su relacin con el modelamiento de datos. El ciclo de vida de los sistemas de informacin con sus correspondientes etapas. Para terminar la unidad usted aprender el modelo conceptual ms popular, me refiero al modelo entidad relacin, diseara modelos conceptuales, utilizando los elementos del modelo entidad relacin como base. Le invito a tomar los valiosos conocimientos que contiene esta unidad, siguiendo detalladamente la metodologa planteada.

b) Competencia

Analiza y reconoce la importancia del modelamiento de datos en el desarrollo de sistemas de informacin.

c) Capacidades 1. Comprende los conceptos fundamentales de base de datos. 2. Distingue los distintos tipos de modelos para disear una base de datos y la forma de capturar los requisitos del cliente. 3. Comprende los conceptos y prcticas fundamentales del modelo entidad relacin. 4. Disea bases de datos utilizando el modelo entidad relacin. d) Actitudes

Lee con dedicacin todo lo concerniente a las generalidades del diseo de base de datos relacionales y modelo entidad relacin. Realiza preguntas sobre cualquier duda que tuviera en el contenido de la unidad. Practica los casos sobre modelo entidad relacin que se encuentran en el texto y las asignaciones de clase. Comparte sus conocimientos adquiridos investigando y desarrollando casos sobre el modelo entidad relacin, con sus compaeros de clase que lo necesiten.

e) Presentacin de ideas bsicas y contenido esenciales de la Unidad

La Unidad de Aprendizaje 1: Generalidades del Diseo de Base de Datos Relacional y Modelo Conceptual; comprende el desarrollo de los siguientes temas: TEMA 1: INTRODUCCIN A LAS BASES DE DATOS TEMA 2: MODELOS E INGENIERA DE REQUISITOS TEMA 3: MODELO ENTIDAD RELACIN TEMA 4: CASO COMERCIAL Y ALQUILER DE PELCULAS

Tema 01: Introduccin a las Bases de Datos

Las bases de datos se encuentran en todo tipo de empresas y no siempre funcionando dentro de computadoras, se dividen en no informticas y informticas, las primeras, las encontramos, por ejemplo: En un estudio contable, los libros contables de las empresas seran una base de datos de libros contables, en una Universidad el listado de matriculados sera la base de datos de matriculados, aunque no siempre se sigue este patrn la idea inicial de base de datos. Base de datos Es un almacenamiento de datos formalmente definido, controlado centralmente para intentar servir a mltiples y diferentes aplicaciones. La base de datos es una fuente significativa de datos que son compartidos por numerosos usuarios para diversas aplicaciones. Kendall y Kendall Una base de datos informtica es la razn de ser del curso, es un conjunto de elementos relacionados entre s, que cumplen con los requerimientos de informacin de un rea o de toda la empresa. Analizando los conceptos antes descritos, la frase clave es datos relacionados y que son los datos?

Otros conceptos de Base de datos Una base de datos tiene una fuente de la cual se derivan los datos,

cierto grado de interaccin con los acontecimientos del mundo real y un pblico que est activamente interesado en el contenido de la base de datos. Ramez Elmasri y Shamkant B. Navathe

Elementos conocidos como por ejemplo el nombre, direccin, el nmero telefnico, el DNI, el RUC de la empresa entre otros, son atmicos es decir no pueden dividirse ms. Ejemplos de datos: Manuel - 16791125 - 25 - Mz. - T Lote 5 - 2,590.3 Archivos de datos Inicialmente los datos se almacenaban en archivos como por ejemplo txt, doc, etc., durante muchos aos los programas informticos utilizaron archivos para registrar los datos, pero el gran problema era la redundancia. Kendall y Kendall dice: Consiste en almacenar los datos en archivos individuales, exclusivos para casa aplicacin particular. En este sistema los datos pueden ser redundantes (repetidos innecesariamente) y la actualizacin de los archivos es ms lenta que en una base de datos. Ejemplo de archivo tradicional: Se cuenta con dos archivos alumno y matricula en el primero se encuentra los datos de los alumnos mientras que en el segundo se encuentra la matricula de los alumnos.

La redundancia radica en la repeticin de los nombres de los alumnos, otro problema aparece en los errores de digitacin, como se observa en el archivo matricula el nombre del alumno Pedro Marengo est mal escrito, lo que ocasionar problemas posteriores. Gestor de base de datos relacional (GBDR) Programa de computadora que permite crear y administrar una base de datos; en el mercado nacional encontramos a los de mayor uso al mysql, sqlserver y oracle. Es un sistema que rene, almacena, procesa y distribuye conjuntos de informacin entre los diferentes elementos que configuran una organizacin, y entre la organizacin misma y su entorno. Juan Antoni Pastori Collado Sistemas de informacin Tambin se dice que es un conjunto de elementos relacionados entre s, que se encarga de procesar manual y/o automticamente datos, en funcin de determinados objetivos. Para entenderlo mejor veamos el siguiente grfico:

Ciclo de vida de los sistemas de informacin Un buen desarrollo de software depende muchas veces del correcto modelamiento de la base de datos. El proceso de software comprende etapas como anlisis, diseo, desarrollo y pruebas, el modelamiento de la base de datos se encuentra en la etapa de diseo. Otra forma de representar el ciclo de vida de los sistemas de informacin es el propuesto por Kendall y Kendall.

Figura 02: Ciclo de vida de los sistemas de informacin Fuente: Kendall y Kendall En la etapa 4, Diseo del Sistema se encuentra la etapa de modelado de datos. La etapa 1, 2 y 3 del modelo de Kendall y Kendall, es la de anlisis, en esta etapa se planea los tiempos y objetivos del proyecto de software adems de los requerimientos de informacin. Despus de la captura de requisitos viene la etapa de diseo, una de las actividades es el modelamiento de datos, aspecto que veremos a profundidad en el transcurso del curso. En la etapa 5, 6 y 7 etapa de desarrollo del software o escritura del cdigo fuente, este cdigo se escribe en base al modelado realizado en la etapa de diseo. Al final se instala la aplicacin informtica en los equipos del cliente y se realiza casos de prueba, conversando previamente con el cliente.

INGENIERA DE REQUISITOS
La base de la ingeniera de requisitos, radica en conocer cules son las necesidades, especificaciones y requerimientos del cliente, parece muy fcil llegar a cumplir este objetivo, no obstante el principal problema en el diseo de los sistemas de informacin, incluso el diseo de base de datos, es la mala especificacin de los requerimientos del cliente, por la sencilla razn que muchas veces ni el cliente mismo sabe lo que necesita, en consecuencia la ingeniera de requisitos, es una rama de la ingeniera del software, que nos ayuda a entender al cliente y capturar mejor los requerimientos, un

ejemplo: En elprologo a un libro de Ralph Young sobre las prcticas efectivas en los requisitos, el autor de este libro escribi: Es tu peor pesadilla. Un cliente entra en tu oficina, se sienta, te mira directo a los ojos, y dice: Yo s que usted piensa que entiende lo que digo, pero lo que usted no entiende es que lo que digo no es realmente lo que quiero decir. Esto sucede de manera invariable cuando el proyecto est avanzado, despus de que han realizado los compromisos relativos al tiempo de entrega, las reputaciones estn en juego y el dinero est en serio peligro. Todos los que hemos trabajado en el negocio de los sistemas y el software por ms de unos cuantos aos hemos vivido esta pesadilla, y solo unos pocos de nosotros hemos aprendido a continuar aun con esta circunstancia. Nosotros tenemos dificultades cuando tratamos de obtener requisitos de nuestros clientes. Tenemos problemas al comprender la informacin que adquirimos. Con frecuencia, registramos los requisitos de una manera desorganizada e invertimos muy poco tiempo en verificar lo que registramos. Permitimos que el cambio nos controle en lugar de establecer mecanismos para controlarlo. En resumen, fallamos al establecer un cimiento slido para el sistema o software. Cada uno de estos problemas representa un reto. Cuando estos se combinan, la imagen es desalentadora incluso para los gerentes y profesionales del software ms experimentados. Pero existen soluciones. La ingeniera de requisitos proporciona el mecanismo apropiado para entender lo que el cliente quiere, analizar las necesidades, evaluar la factibilidad, negociar una solucin razonable, especificar la solucin sin ambigedades, validar la especificacin, y administrar los requisitos conforme stos se transforman en un

sistema operacional. El proceso de la ingeniera de requisitos se lleva a cabo a travs de siete distintas funciones: inicio, obtencin, elaboracin, negociacin, especificacin, validacin y gestin. PRESSMAN, Roger La captura de requisitos, est dividido en 7 fases: Por lo general, las semillas de los desastres ms importantes en software se siembran en los primeros tres meses desde el comienzo del proyecto. Capers Jones INICIO Inicio del proyecto, algunas veces se puede iniciar con una conversacin, pero generalmente inicia con la identificacin de necesidades del negocio OBTENCIN Realmente parece muy fcil preguntarle al cliente, cules son sus necesidades, mbito del proyecto o inclusive, el alineamiento que tiene con los objetivos estratgicos del negocio, pero muchas veces es complicado, los siguientes aspectos nos ayudarn a entender mejor porque es tan complicado:. Problemas de mbito Tamao del proyecto mal definido o no tan claro, esto puede confundir al analista con requisitos innecesarios para los objetivos del negocio. Problemas de comprensin Cuando los actores clave del negocio, los que usaran el sistema tienen poca comprensin de lo que necesitan, o simplemente no saben cmo comunicrselo al analista. Problemas de volatilidad Los requerimientos planteados al inicio del proyecto cambian

continuamente. ELABORACON Toda la informacin adquirida del cliente se plasma en un modelo. NEGOCIACIN Por lo general, el cliente siempre requiere ms de lo que se pueda lograr en el tiempo planeado, el ingeniero de requisitos tiene que negociar realizando estimaciones y costos del proyecto. ESPECIFICACIONES Una especificacin puede ser un documento escrito, un conjunto de modelos grficos, un modelo matemtico formal, una coleccin de escenarios de uso, un prototipo o cualquier combinacin de estos. VALIDACIN Proceso que verifica si las especificaciones son correctas. GESTIN Conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en cualquier momento mientras se desarrolla el proyecto. Cmo formular las primeras preguntas? Quin est detrs de la solicitud de este trabajo? Quin usar la solucin? Cul ser el beneficio econmico de una solucin exitosa? Existe otra fuente para la solucin requerida?

Es mejor saber algo de la preguntas que todo de las respuestas. James Thurber Para comprender mejor el problema se debe realizar las siguientes preguntas: Cmo podra caracterizarse un buen resultado generado por una solucin exitosa? Cules problemas ataca esta solucin? Podra usted describir o mostrar el ambiente de negocios en el que se utilizar la solucin? Los aspectos especiales del desempeo o las restricciones que afectarn laforma en que se busque la solucin? Las siguientes preguntan permitirn evaluar la efectividad de las respuestas anteriores: Es usted la persona adecuada para contestar esta pregunta? Sus respuestas son oficiales? Mis preguntas son relevantes para su problema? Estoy haciendo demasiadas preguntas? Alguien ms puede proporcionar informacin adicional? El que pregunta es un tonto durante cinco minutos: el que no pregunta es un tonto por siempre. Proverbio Chino

MODELOS Un modelo es una representacin abstracta o conceptual de la realidad; en las bases de datos son tres los modelos que permiten disearla y son: modelo conceptual, modelo lgico y modelo fsico. Modelo Conceptual El diseo del modelo conceptual parte de la especificacin de requisitos. Es independiente del gestor de base de datos relacional, describe un conjunto de objetos de la realidad, el modelo conceptual que utilizaremos es el ENTIDAD/RELACIN. Modelo lgico Se obtiene del modelo entidad relacin, lo que cambia es la forma de presentacin, se dice que es una descripcin de la estructura de la base de datos, que puede ser procesada por el gestor de base de datos relacional (GBDR). El modelo lgico que utilizaremos en el curso, es el relacional, por ser el que utilizan los GBDR. Se podra decir que el modelo lgico es como un puente, porque se encuentra entre el modelo conceptual y el modelo fsico.

Modelo fsico Es una descripcin de la implantacin de una base de datos en un gestor de base de datos relacional como por ejemplo Sqlserver, Mysql y Oracle. El diseo de un modelo fsico depende enteramente del GBRD y parte del modelo lgico.

Tema 03: Modelo Entidad - Relacin

MODELO ENTIDAD RELACIN
El modelo entidad relacin, es el modelo conceptual ms utilizado, permite plasmar una realidad de la empresa, o una rea funcional, como por ejemplo comercial, finanzas, recursos humanos, tesorera, entre otras. Propuesto por Peter Chen en 1967, el objetivo del modelo es representar grficamente la realidad de la empresa. Los elementos bsicos del modelo entidad relacin son: Entidades, atributos y asociaciones.

Entre las notaciones ms utilizadas se encuentra la de Chen y la CW Bachman, ms conocida como notacin pata de gallo, en este curso ensearemos las dos, aunque despus veremos que la ms utilizada es la notacin pata de gallo. Es preciso explicar que inicialmente el modelo entidad relacin contaba con elementos como entidades, atributos, asociaciones, mas tarde se agregaron nuevos elementos, y ahora se conoce como el modelo entidad relacin extendido, con elementos como atributos compuestos y las jerarquas de generalizacin. ENTIDAD Es un objeto importante de la vida real que tiene atributos como por ejemplo ALUMNO, Cules son sus atributos?: cdigo, nombre, apellidos, telfono, direccin, correo; una de las maneras de identificar entidades, es preguntndonos si tiene atributos, sino tiene atributos no es entidad. Una entidad son los sujetos de inters para la organizacin y el modelo que se quiere construir. Otra Definicin De Entidad Cualquier tipo de objeto de donde se recoge informacin: cosa, persona, concepto abstracto. Por ejemplo: carro, casa, empleado, cliente, empresa, oficio, producto, concierto, excursin, etc. Las entidades se representan grficamente mediante rectngulos y su nombre aparece en el interior. Un nombre de entidad solamente puede aparecer una vez en el modelo entidad relacin. Existen dos tipos de entidades, fuertes y dbiles, una entidad dbil es una entidad cuya existencia depende de la existencia de una entidad fuerte.

PERSONA

CATEGORIA

TURNO CARRERA
ASOCIACIN

MATRICULA FACTURA

Ejemplo de entidades con su representacin grfica

Conexin entre dos entidades, a veces llamada relacin binaria, no obstante es preciso mencionar que existen entidades que se pueden relacionar con varias entidades. ATRIBUTO Caracterstica que describe una entidad o asociacin, adems los atributos representan las propiedades bsicas de las entidades y sus relaciones. Ejemplos: Con la notacin Chen se representa de la siguiente manera:

Explicando la figura Nro. 3, la entidad ALUMNO, tiene 4 atributos, cdigo, apellido, nombre y direccin, se debe considerar que la entidad ALUMNO, puede tener ms atributos, esto depender de la institucin educativa que se encuentre analizando.

El siguiente grfico representa la notacin pata de gallo. Figura Nro. 5 Entidad con atributos, notacin pata de gallo

La figura Nro. 4 representa prcticamente lo mismo que la figura Nro. 3, con la diferencia que los atributos en la notacin Chen se encuentran representados fuera de la entidad y en la notacin pata de gallo se encuentran dentro de la entidad, realmente no se debe preocupar mucho, por el aspecto de las notaciones, sino se debe tener en cuenta la correcta descripcin de los atributos de una entidad.
Los atributos de una entidad se clasifican en diferentes tipos:

Atributos Simples y Compuestos

Un atributo simple es aquel que no se puede dividir en partes, ejemplo de atributos simples: DNI, cdigo alumno, RUC, curso, grado, seccin, nivel, etctera. En cambio los atributos compuestos se pueden dividir en partes, como por ejemplo: datos cliente, se puede dividir en nombre, apellido paterno, apellido materno.

Figura Nro. 6 Partes del atributo datos cliente

La gran pregunta es cmo aplico la teora de los atributos compuestos?, aunque hay varias maneras, se explica utilizando el ejemplo de la figura Nro. 5.

Explicacin En la entidad ALUMNO, el atributo direccin puede estar compuesto por: calle, nmero, distrito, ciudad y provincia, entonces la entidad ALUMNO, quedara de la siguiente manera. IMPORTANTE Algunas veces ser difcil identificar atributos compuestos, no obstante la clave de todo, es la prctica en el desarrollo de los ejercicios y casos prcticos.

ALUMNO
Cdigo Apellido Nombre Calle Numero Distrito Ciudad Provincia Figura Nro 7 Atributo direccin sub-dividido ATRIBUTOS UNIVALORADOS Un atributo es univalorado cuando el dato que contiene el atributo es nico, por ejemplo una persona no puede tener ms de un nmero de DNI. ATRIBUTOS MULTIVALORADOS Es multivalorado cuando un atributo tiene ms de un valor, por ejemplo: direccin, un cliente puede tener ms de una direccin, en este caso el atributo direccin es multivalorado

El Seor Abraham Silberschatz, Henry presenta el siguiente ejemplo: Un banco puede limitar el nmero de direcciones almacenadas de un cliente a dos. Colocando lmites en este caso, se expresa que el atributo direccin_cliente del conjunto de entidades cliente puede tener entre cero y dos valores.

ATRIBUTOS NULOS Tipo de atributo cuyos datos no se conocen o no hay valor para el atributo, se da en algunos casos, por ejemplo: en el atributo telfono, se puede dar el caso, que un cliente no tenga telfono. ATRIBUTOS CLAVE DE UNA ENTIDAD Atributos cuyos datos en ningn caso son iguales, por ejemplo: el DNI, puede ser un atributo clave porque no pueden existir 2 clientes con el mismo DNI.
Ejemplos atributos univalorados y multivalorados

CLIENTE
Cdigo Apellido Nombre Direccin DNI Figura Nro. 8 Entidad CLIENTE con atributos IMPORTANTE El concepto de dato, se entender mejor al estudiar el modelo relacional.
El campo DNI es una atributo univalorado porque no se puede dividir, veamos la

representacin grfica.

El valor del DNI de Manuel es nico y no le pertenece a otro cliente. En cambio el atributo direccin es multivalorado, porque puede tener 0, 1 o ms direcciones, siempre teniendo en cuenta lo que hemos registrado en el anlisis, algunas veces solamente necesitamos registrar una direccin, pero en otros casos, el cliente (empresa que nos contrata para realizar el modelamiento de datos), requiere registrar ms de una direccin, si ese fuera el caso, la entidad cambiara, ese cambio se explicar en el modelo relacional. Ver el ejemplo multivalorado:

Figura Nro. 10 Ejemplo atributos multivalorados Vemos en la figura 10, que Daniel tiene dos direcciones, entonces el atributo direccin es multivalorado.

Para Analizar Muchas veces no es fcil diferenciar si un atributo es entidad, ejemplo: ciudad es un atributo de cliente o es una entidad es si misma.

ASOCIACIONES O RELACIONES ENTRE ENTIDADES

La razn de ser del modelo entidad relacin, son las relaciones entre entidades. Existen varios tipos de relaciones que se explicarn a continuacin.
Una relacin es una asociacin entre dos o ms entidades

RELACIN DE UNO A UNO Una entidad A se relaciona con solo una entidad B y una entidad B se relaciona con solo una entidad A.

Ejemplo de entidades con relaciones de uno a uno.

Otra forma de identificar relaciones de uno a uno es la siguiente:

En el caso presentado anteriormente se observa que Daniel tiene el cdigo de matrcula M00001 y Manuel la M00002, claramente se ve que es una relacin de uno a uno. RELACIN DE UNO A MUCHOS Una entidad A se relaciona con muchas entidades B, sin embargo una entidad B se relaciona solamente con una entidad A.

Otra forma de identificar relaciones de uno a muchos es la siguiente:

Esta tcnica es muy buena, usted tiene que ingresar valores al crculo de clientes y al de facturas, en general dentro de los crculos solo hay datos de las entidades cliente y factura, observamos que Mario tiene dos facturas y puede tener muchas ms, y Karina hasta el momento solamente tiene una, pero tambin puede tener ms, por lo tanto es una relacin de uno a muchos de cliente a factura

De factura a cliente, la factura con nmero F00001 solamente le puede pertenecer a Mario y no a otro cliente en ningn caso, entonces concluimos que es una relacin de uno a uno, de factura a cliente. RELACIONES DE MUCHOS A MUCHOS Una entidad A se relaciona con muchas entidades B y una entidad B se relaciona con muchas entidades A.

De ALUMNO a HABILIDAD Un alumno tiene una o muchas habilidades De HABILIDAD a ALUMNO

Esa habilidad la puede tener uno o muchos alumnos

Se observa que Mario tiene varias habilidades como leer rpido y aprender rpido, pero Karina tambin aprende rpido y canta, entonces es una relacin de muchos a muchos, porque un alumno Mario tienes varias habilidades, pero esas habilidades tambin las puede tener otro alumno, como Karina. IMPORTANTE En los ejemplos anteriormente descritos solamente se ha utilizado la notacin pata de gallo, en los ejemplos siguientes se desarrollarn utilizando la otra notacin
Notacin CHEN:

Se nota la diferencia, las relaciones se representan por un rombo con los atributos fuera del recuadro de las entidades, los atributos clave, estn subrayados.

Tema 04: Caso Comercial y Alquiler de pelculas

Informacin sobre proveedores: cdigo, nombre, direccin, Telfono, ciudad, pas. Informacin sobre clientes: cdigo, DNI, nombre, direccin, telfono. Informacin sobre artculos: cdigo, nombre, precio unitario, Color, stock. Informacin sobre las facturas indicando cdigo_factura, numero,

CASO COMERCIAL Sea un sistema de informacin que represente la informacin de Proveedores, clientes y artculos disponibles en una determinada empresa de venta de computadoras. Contiene la siguiente informacin:

fecha, subtotal, IGV y total. Informacin sobre la relacin entre clientes y artculos.

Disear un diagrama entidad relacin que describa conceptualmente el sistema de informacin. 1. Encontrar las entidades de informacin:

Proveedor Cliente Articulo Factura

2. Disear las entidades y atributos:

Hasta el momento se ha identificado las principales entidades y atributos; ahora es el momento de relacionar las entidades y terminar de disear el modelo conceptual utilizando el modelo entidad relacin. RELACIN CLIENTE VS FACTURA

Para identificar el tipo de relacin que existe entre la entidad CLIENTE y la entidad FACTURA, se agregan clientes y facturas,

observamos que Mario puede tener en el tiempo varias facturas, pero la factura F00001 y F00002, solamente puede pertenecer a Mario y no a Karina, entonces se concluye que la relacin es de uno a muchos, ya que un cliente puede tener una o muchas facturas, pero esa factura solamente le pertenece a un cliente.

La relacin queda de la siguiente manera:

RELACIN ARTICULO VS FACTURA ARTICULO Codigo Nombre Precio_unitario Color Stock FACTURA Codigo_factura Numero Fecha Subtotal IGV Total

Se observa que un articulo puede estar en varias facturas, y en una factura pueden existir varios artculos, por lo tanto la relacin que se forma es de muchos a muchos.

La relacin final sera:

Relacin PROVEEDOR vs ARTICULO ARTICULO Codigo Nombre Precio_unitario Color

Stock

PROVEEDOR Codigo Nombre Direccion Telefono Ciudad Pas

Se observa que un artculo puede ser vendido por varios proveedores, y un proveedor puede vender ms de un artculo a la vez, por lo tanto la relacin es de muchos a muchos.

La relacin que de la siguiente manera:

El modelo final quedara de la siguiente manera:

CASO ALQUILER DE PELICULAS

La cadena de Video Clubs Gusters ha decidido, para mejorar su servicio, emplear una base de datos para almacenar la informacin referente a las pelculas que ofrece en alquiler. Esta informacin es la siguiente: Una pelcula se caracteriza por un titulo, nacionalidad, productora y fecha. En una pelcula pueden participar varios actores (nombre, nacionalidad, sexo) algunos de ellos como actores principales. Una pelcula est dirigida por un director (nombre, nacionalidad). De cada pelcula se dispone de uno o varios ejemplares

diferenciados por un nmero de ejemplar y caracterizados por su estado de conservacin. Un ejemplar se puede encontrar alquilado a algn socio (DNI, nombre, direccin, telfono). Se desea almacenar la fecha de comienzo del alquiler y la de devolucin. Un socio tiene que ser avalado por otro socio que responda de l en caso de tener problemas en el alquiler. 1. Identificamos las entidades Pelcula Actor Ejemplar Alquiler Socio

2. Definir entidades y atributos

Cuando el caso requiere mucho anlisis, sugiero leer el enunciado varias veces, para comprender mejor los requerimientos del cliente. RELACIN PELCULA VS ACTOR

La relacin que se forma, es de muchos a muchos, observamos que en la pelcula Tron, puede haber varios actores, y a la vez esos actores pueden participar de varias pelculas. Por ejemplo Cindy Morgan trabaj en Tron y Los viajes de Gulliver.

RELACIN EJEMPLAR VS PELICULA

Observamos que la pelcula Tron tiene varios ejemplares, pero ese ejemplar solamente le pertenece a la pelcula Tron, por lo tanto la relacin es de uno a muchos.

RELACIN EJEMPLAR VS ALQUILER

Se observa que un ejemplar puede ser alquilado por varios socios, y un socio puede alquilar varios ejemplares, por lo tanto la relacin es de muchos a muchos.

RELACIN SOCIO VS ALQUILER

Se observa que un socio puede alquilar una o muchas veces, pero ese alquiler solamente le pertenece a ese socio.

Para concluir, observamos el modelo entidad relacin final para este caso.

1. Introduccin 2. Base de datos relacionales 3. Diseo de las bases de datos relacionales 4. Microsoft access 5. Objetos de la base de datos 6. Conceptos bsicos de una base de datos

1. Introduccin El trmino base de datos fue acuado por primera vez en 1963, en un simposio celebrado en California. De forma sencilla podemos indicar que una base de datos no es ms que un conjunto de informacin relacionada que se encuentra agrupada o estructurada. El archivo por s mismo, no constituye una base de datos, sino ms bien la forma en que est organizada la informacin es la que da origen a la base de datos. Las bases de datosmanuales, pueden ser difciles de gestionar y modificar. Por ejemplo, en una gua de telfonos no es posible encontrar el nmero de un individuo si no sabemos su apellido, aunque conozcamos su domicilio.

Del mismo modo, en un archivo de pacientes en el que la informacin est desordenada por el nombre de los mismos, ser una tarea bastante engorrosa encontrar todos los pacientes que viven en una zona determinada. Los problemas expuestos anteriormente se pueden resolver creando una base de datos informatizada. Desde el punto de vista informtico, una base de datos es un sistema formado por un conjunto de datos almacenados en discos que permiten el acceso directo a ellos y un conjunto de programas que manipulan ese conjunto de datos. Desde el punto de vista ms formal, podramos definir una base de datos como un conjunto de datos estructurados, fiables y homogneos, organizados independientemente en mquina, accesibles a tiempo real, compartibles por usuarios concurrentes que tienen necesidades de informacin diferente y no predecibles en el tiempo. La idea general es que estamos tratando con una coleccin de datos que cumplen las siguientes propiedades:

Estn estructurados independientemente de las aplicaciones y del soporte de almacenamiento que los contiene. Presentan la menor redundancia posible. Son compartidos por varios usuarios y/o aplicaciones.

2. Base de datos relacionales En una computadora existen diferentes formas de almacenar informacin. Esto da lugar a distintos modelos de organizacin de la base de datos: jerrquico, red, relacional y orientada a objeto. Los sistemas relacionales son importantes porque ofrecen muchos tipos de procesos de datos, como: simplicidad y generalidad, facilidad de uso para el usuario final, perodos cortos de aprendizaje y las consultas de informacin se especifican de forma sencilla. Las tablas son un medio de representar la informacin de una forma ms compacta y es posible acceder a la informacin contenida en dos o ms tablas. Ms adelante explicaremos que son las tablas. Las bases de datos relacionales estn constituidas por una o ms tablas que contienen la informacin ordenada de una forma organizada. Cumplen las siguientes leyes bsicas:

Generalmente, contendrn muchas tablas. Una tabla slo contiene un nmero fijo de campos. El nombre de los campos de una tabla es distinto. Cada registro de la tabla es nico. El orden de los registros y de los campos no est determinados. Para cada campo existe un conjunto de valores posible.

3. Diseo de las bases de datos relacionales El primer paso para crear una base de datos, es planificar el tipo de informacin que se quiere almacenar en la misma, teniendo en cuenta dos aspectos: la informacin disponible y la informacin que necesitamos. La planificacin de la estructura de la base de datos, en particular de las tablas, es vital para la gestin efectiva de la misma. El diseo de la estructura de una tabla consiste en una descripcin de cada uno de los campos que componen el registro y los valores o datos que contendr cada uno de esos campos. Los campos son los distintos tipos de datos que componen la tabla, por ejemplo: nombre, apellido, domicilio. La definicin de un campo requiere: el nombre del campo, el tipo de campo, el ancho del campo, etc. Los registros constituyen la informacin que va contenida en los campos de la tabla, por ejemplo: el nombre del paciente, el apellido del paciente y la direccin de este. Generalmente los diferente tispos de campos que su pueden almacenar son los siguientes: Texto (caracteres), Numrico (nmeros), Fecha / Hora, Lgico (informaciones lgicas si/no, verdadero/falso, etc., imgenes. En resumen, el principal aspecto a tener en cuenta durante el diseo de una tabla es determinar claramente los campos necesarios, definirlos en forma adecuada con un nombre especificando su tipo y su longitud. 4. Microsoft access Posiblemente, la aplicacin ms compleja de la suite Office, sea Access, una base de datos visual. Como todas las modernas bases de datos que trabajan en el entorno Windows, puede manejarse ejecutando unos cuantos clic de mouse sobre la pantalla. Access contiene herramientas de diseo y programacin reservadas a los usuarios con mayor

experiencia, aunque incluye bases de datos listas para ser usadas; estn preparadas para tareas muy comunes, que cualquiera puede realizar en un momento determinado ordenar libros, archivar documentacin, etc.-. 5. Objetos de la base de datos Tablas: unidad donde crearemos el conjunto de datos de nuestra base de datos. Estos datos estarn ordenados en columnas verticales. Aqu definiremos los campos y sus caractersticas. Ms adelante veremos qu es un campo. Consultas: aqu definiremos las preguntas que formularemos a la base de datos con el fin de extraer y presentar la informacin resultante de diferentes formas (pantalla, impresora...) Formulario: elemento en forma de ficha que permite la gestin de los datos de una forma ms cmoda y visiblemente ms atractiva. Informe: permite preparar los registros de la base de datos de forma personalizada para imprimirlos. Macro: conjunto de instrucciones que se pueden almacenar para automatizar tareas repetitivas. Mdulo: programa o conjunto de instrucciones en lenguaje Visual Basic 6. Conceptos bsicos de una base de datos Campo: unidad bsica de una base de datos. Un campo puede ser, por ejemplo, el nombre de una persona. Los nombres de los campos, no pueden empezar con espacios en blanco y caracteres especiales. No pueden llevar puntos, ni signos de exclamacin o corchetes. Si pueden tener espacios en blanco en el medio. La descripcin de un campo, permite aclarar informacin referida a los nombres del campo. El tipo de campo, permite especificar el tipo de informacin que cargaramos en dicho campo, esta puede ser:

Texto: para introducir cadenas de caracteres hasta un mximo de 255 Memo: para introducir un texto extenso. Hasta 65.535 caracteres Numrico: para introducir nmeros Fecha/Hora: para introducir datos en formato fecha u hora Moneda: para introducir datos en formato nmero y con el signo monetario Autonumrico: en este tipo de campo, Access numera automticamente el contenido S/No: campo lgico. Este tipo de campo es slo si queremos un contenido del tipo S/No, Verdadero/Falso, etc. Objeto OLE: para introducir una foto, grfico, hoja de clculo, sonido, etc. Hipervnculo: podemos definir un enlace a una pgina Web Asistente para bsquedas: crea un campo que permite elegir un valor de otra tabla o de una lista de valores mediante un cuadro de lista o un cuadro combinado.

Registro: es el conjunto de informacin referida a una misma persona u objeto. Un registro vendra a ser algo as como una ficha. Campo clave: campo que permite identificar y localizar un registro de manera gil y organizada. Propiedades generales de los campos
PROPIEDAD Tamao del campo DESCRIPCIN Permite establecer la longitud mxima de un campo de texto numrico. Permite determinar la apariencia de presentacin de los datos, utilizando los formatos predefinidos o nuestros propios formatos Permite especificar el nmero de cifras decimales para mostrar los nmeros. Permite controlar y filtrar los caracteres o valores que los usuarios introducen en un control de cuadro de texto, evitando errores y facilitando su escritura. TIPO DE CAMPO Texto, numrico, contador

Formato

Todos, excepto OLE y Memo

Lugares decimales

Numrico y moneda

Mscara de entrada

Texto, numrico, fecha/hora, moneda

Ttulo

Permite definir una etiqueta de campo predeterminada para un formularios o informe Introduce en el campo un valor cuando se agregan nuevos registros (long. Mx. 255 caracteres) Permite escribir la condicin que deben satisfacer los datos introducidos para ser aceptados

Todos

Valor predeterminado

Todos, excepto OLE y contador

Regla de validacin

Todos, excepto OLE y contador

Texto de validacin

Define el texto del mensaje que se visualiza cuando los datos no Todos excepto OLE y contador cumplen las condiciones enumerdas en la regla de validacin Permite especificar si es necesario que exista un valor en un campo. Permite especificar si una cadena de longitud cero ("") es una entrada vlida para el campo Define un campo como ndice o campo clave. Todos excepto contador

Requerido

Permitir longitud cero

Texto, memo

Indexado

Texto, numrico, contador, fecha/hora.

Las propiedades de un campo, se establecen seleccionando el campo y haciendo clic en la propiedad deseada del cuadro PROPIEDADES DEL CAMPO situado en la parte inferior de la ventana DISEO DE TABLA. Access tiene una configuracin predeterminada para las propiedades de cada uno de los tipos de campo. Sin duda la ms importante es el tamao del campo, ya que este nos permitir hacer una estimacin del espacio ocupado por nuestra base de datos en el disco fijo.

Ingeniera de requisitos
De Wikipedia, la enciclopedia libre Saltar a: navegacin, bsqueda

En la ingeniera de sistemas y la ingeniera de software, la Ingeniera de requisitos o Ingeniera de requerimientos comprende todas las tareas relacionadas con la determinacin de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de los inversores, que pueden entrar en conflicto entre ellos. Muchas veces se habla de requerimientos en vez de requisitos; esto se debe a una mala traduccin del ingls. La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al ingls como request. El propsito de la ingeniera de requisitos es hacer que los mismos alcancen un estado ptimo antes de alcanzar la fase de diseo en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigedades o contradicciones, etc.

Contenido

[ocultar]

1 Implicaciones 2 Fases de implementacin 3 Tcnicas principales o 3.1 Entrevistas o 3.2 Talleres o 3.3 Forma de contrato o 3.4 Objetivos medibles o 3.5 Prototipos o 3.6 Casos de uso 4 Especificacin de requisitos del software 5 Identificacin de las personas involucradas 6 Problemas o 6.1 Relacionados con las personas involucradas o 6.2 Relacionados con los analistas o 6.3 Relacionados con los desarrolladores o 6.4 Soluciones aplicadas 7 Fuentes

[editar] Implicaciones
La Ingeniera de Requisitos implica todas las actividades del ciclo de vida dedicadas a:

La educcin (a veces llamada "elicitacin", debido a una mala traduccin de "elicitation") de los requisitos de usuario. El anlisis y negociacin de requisitos para derivar requisitos adicionales. La documentacin de los requisitos como especificacin. La validacin de los requisitos documentados contra las necesidades de usuario. As como los procesos que apoyan estas actividades.

[editar] Fases de implementacin

Desde un punto de vista conceptual, las actividades son de cinco clases.

Obtener requisitos: a travs de entrevistas o comunicacin con clientes o usuarios, para saber cules son sus expectativas. Analizar requisitos: detectar y corregir las falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados en el diseo. Documentar requisitos: igual que todas las etapas, los requisitos deben estar debidamente documentados. Verificar los requisitos: consiste en comprobar el correcto funcionamiento de un requisito en la aplicacin.

Validar los requisitos: comprobar que los requisitos implementados se corresponden con lo que inicialmente se pretenda.

[editar] Tcnicas principales

La ingeniera de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades psicolgicas. Los nuevos sistemas cambian el entorno y las relaciones entre la gente, as que es importante identificar a todos los actores involucrados, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias tcnicas para obtener los requisitos del cliente. Histricamente, esto ha incluido tcnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Tcnicas ms modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista emplear una combinacin de estos mtodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio.

[editar] Entrevistas
Las entrevistas son un mtodo comn. Por lo general no se entrevista a toda la gente que se relacionar con el sistema, sino a una seleccin de personas que represente a todos los sectores crticos de la organizacin, con el nfasis puesto en los sectores ms afectados o que harn un uso ms frecuente del nuevo sistema.

[editar] Talleres
Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es til la seleccin de un secretario dedicado a la documentacin de la discusin, liberando al analista del negocio para centrarse en el proceso de la definicin de los requisitos y para dirigir la discusin.

[editar] Forma de contrato

En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos stos pueden tener centenares de pginas.

[editar] Objetivos medibles

Los requisitos formulados por los usuarios se toman como objetivos generales, a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos crticos del funcionamiento interno que luego darn forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el

progreso en la construccin, para evaluar en cualquier momento qu tan avanzado se encuentra el proyecto.

[editar] Prototipos
Un prototipo es una pequea muestra, de funcionalidad limitada, de cmo sera el producto final una vez terminado. Ayudan a conocer la opinin de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado.

[editar] Casos de uso

Un caso de uso es una tcnica para documentar posibles requisitos, graficando la relacin del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y slo se representa su interaccin con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. El objetivo de esta prctica es mejorar la comunicacin entre los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales. Esta tcnica se enfrenta a los siguientes peligros potenciales.

A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseo final. Los diseadores tienden a reutilizar el cdigo de los prototipos por temor a perder el tiempo al comenzar otra vez. Los prototipos ayudan principalmente a las decisiones del diseo y de la interfaz de usuario. Sin embargo, no proporcionan explcitamente cules son los requisitos. Los diseadores y los usuarios finales pueden centrarse demasiado en el diseo de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.

Los prototipos pueden ser: diagramas, aplicaciones operativas con funcionalidades sintetizadas. Los diagramas, en los casos donde se espera que el software final tenga diseo grfico, se realizan en una variedad de documentos de diseo grficos y a menudo elimina todo el color del diseo del software (es decir utilizar una gama de grises). Esto ayuda a prevenir la confusin sobre la apariencia final de la aplicacin.

[editar] Especificacin de requisitos del software

Una especificacin de requisitos del software es una descripcin completa del comportamiento del sistema a desarrollar. Incluye un conjunto de casos de uso que describen todas las interacciones que se prevn que los usuarios tendrn con el software. Tambin contiene requisitos no funcionales (o suplementarios). Los requisitos no funcionales son los requisitos que imponen restricciones al diseo o funcionamiento del sistema (tal como requisitos de funcionamiento, estndares de calidad, o requisitos del diseo).

Las estrategias recomendadas para la especificacin de los requisitos del software estn descritas por IEEE 830-1998. Este estndar describe las estructuras posibles, contenido deseable, y calidades de una especificacin de requisitos del software. Los requisitos se dividen en tres:

Funcionales: son los que el usuario necesita que efecte el software. Ej: el sistema debe emitir un comprobante al asentar la entrega de mercadera. No funcionales: son los "recursos" para que trabaje el sistema de informacin (redes, tecnologa). Ej: el soporte de almacenamiento a usar debe ser MySQL. Empresariales u Organizacionales: son el marco contextual en el cual se implantar el sistema para conseguir un objetivo macro. Ej: abaratar costos de expedicin.

[editar] Identificacin de las personas involucradas

Debido a que los cambios que introduce un sistema nuevo tienden a afectar a ms de un tipo de usuario, los analistas de requisitos han de tomar en consideracin a todos los implicados para que se obtengan y depuren sus requisitos de la forma ms fidedigna posible. Entre las personas implicadas hay que considerar:

Organizaciones que integran la organizacin del analista que est diseando el sistema Organizaciones o sistemas de respaldo Direccin Usuarios

[editar] Problemas
[editar] Relacionados con las personas involucradas
Las vas que pueden dificultar la determinacin de los requisitos son:

Los usuarios no tienen claro lo que desean Los usuarios no se involucran en la elaboracin de requisitos escritos Los usuarios insisten en nuevos requisitos despus de que el coste y la programacin se hayan fijado. La comunicacin con los usuarios es lenta Los usuarios no participan en revisiones o son incapaces de hacerlo. Los usuarios no comprenden los problemas tcnicos Los usuarios no entienden el proceso del desarrollo

Esto puede conducir a la situacin donde las exigencias del consumidor cambian, incluso cuando el desarrollo del producto ya est en marcha.

[editar] Relacionados con los analistas

La correcta redaccin de las Especificaciones de requisitos del Software es imprescindible para el correcto desarrollo del proyecto. Por ello, en su redaccin hay que evitar:

Uso de terminologa ambigua en la redaccin de los documentos de requisitos Sobreespecificacin de los requisitos Escritura poco legible, voz pasiva, abuso de negaciones Uso de verbos en condicional, expresiones subjetivas Ausencia de trminos y verbos del dominio de la aplicacin

[editar] Relacionados con los desarrolladores

Los problemas posibles causados por los desarrolladores durante anlisis de requisitos son:

El personal tcnico y los usuarios finales pueden tener diversos vocabularios y pueden llegar a creer incorrectamente que estn de acuerdo, no dndose cuenta del desacuerdo hasta que se provee el producto final. Los desarrolladores pueden intentar encajar el sistema en un modelo existente, en vez de desarrollar un sistema adaptado a las necesidades del cliente. El anlisis de requisitos se puede realizar a menudo por los ingenieros o programadores, en vez de personal con las habilidades de relacin con la gente y el conocimiento apropiados para entender las necesidades de un cliente correctamente.

[editar] Soluciones aplicadas

Una solucin aplicada en los problemas de comunicaciones ha sido emplear a especialistas en anlisis del negocio o del sistema. Las tcnicas introducidas en los aos 90 tienden al uso de prototipos, lenguaje unificado de modelado, casos de uso, y el desarrollo gil de software. Otros tipos de herramientas aplicadas para salvar las diferencias entre los usuarios y las organizaciones de tecnologa de la informacin y que permiten la comprobacin de las aplicaciones son:

pizarras electrnicas para bosquejar los algoritmos y para probar alternativas capacidad de capturar la lgica del negocio y los datos necesarios capacidad de generar los prototipos que imitan fielmente el producto final interactividad la capacidad para agregar requisitos contextuales y otro comentarios capacidad para que usuarios remotos y distribuidos operen con el prototipo

Por ltimo, se requieren herramientas que permitan medir, de forma objetiva, la calidad de una especificacin de requisitos.

Modelo entidad-relacin

De Wikipedia, la enciclopedia libre Saltar a: navegacin, bsqueda Este artculo o seccin necesita referencias que aparezcan en una publicacin acreditada, como revistas especializadas, monografas, prensa diaria o pginas de Internet fidedignas. Puedes aadirlas as o avisar al autor principal del artculo en su pgina de discusin pegando:
{{subst:Aviso referencias|Modelo entidad-relacin}} ~~~~

Ejemplo de diagrama E-R.

Un diagrama o modelo entidad-relacin (a veces denominado por sus siglas en ingls, ER "Entity relationship", o del espaol DER "Diagrama de Entidad Relacin") es una herramienta para el modelado de datos que permite representar las entidades relevantes de un sistema de informacin as como sus interrelaciones y propiedades.

Contenido
[ocultar]

1 Modelado Entidad-Relacin 2 Base terica y conceptual o 2.1 Entidad o 2.2 Atributos o 2.3 Relacin o 2.4 Conjunto de relaciones 3 Restricciones o 3.1 Correspondencia de cardinalidades o 3.2 Restricciones de participacin 4 Claves 5 Diagrama entidad-relacin o 5.1 Entidades

5.2 Atributos 5.3 Relaciones 6 Diagramas extendidos o 6.1 Entidades fuertes y dbiles o 6.2 Cardinalidad de las relaciones o 6.3 Atributos en relaciones o 6.4 Herencia o 6.5 Agregacin 7 Vase tambin

o o

[editar] Modelado Entidad-Relacin

El Modelo Entidad-Relacin.
1. Se elabora el diagrama (o diagramas) entidad-relacin. 2. Se completa el modelo con listas de atributos y una descripcin de otras restricciones que no se pueden reflejar en el diagrama.

El modelado de datos no acaba con el uso de esta tcnica. Son necesarias otras tcnicas para lograr un modelo directamente implementable en una base de datos. Brevemente:

Transformacin de relaciones mltiples en binarias. Normalizacin de una base de datos de relaciones (algunas relaciones pueden transformarse en atributos y viceversa). Conversin en tablas (en caso de utilizar una base de datos relacional).

[editar] Base terica y conceptual

El modelo de datos entidad-relacin est basado en una percepcin del mundo real que consta de una coleccin de objetos bsicos, llamados entidades, y de relaciones entre esos objetos.

[editar] Entidad
Representa una cosa u "objeto" del mundo real con existencia independiente, es decir, se diferencia unvocamente de otro objeto o cosa, incluso siendo del mismo tipo, o una misma entidad. Algunos Ejemplos:

Una persona. (Se diferencia de cualquier otra persona, incluso siendo gemelos). Un automvil. (Aunque sean de la misma marca, el mismo modelo,..., tendrn atributos diferentes, por ejemplo, el nmero de chasis). Una casa (Aunque sea exactamente igual a otra, an se diferenciar en su direccin).

Una entidad puede ser un objeto con existencia fsica como: una persona, un animal, una casa, etc. (entidad concreta); o un objeto con existencia conceptual como: un puesto de trabajo, una asignatura de clases, un nombre,etc. (entidad abstracta). Una entidad est descrita y se representa por sus caractersticas o atributos. Por ejemplo, la entidad Persona las caractersticas: Nombre, Apellido, Gnero, Estatura, Peso, Fecha de nacimiento, etc...

[editar] Atributos
Los atributos son las caractersticas que definen o identifican a una entidad. Estas pueden ser muchas, y el diseador solo utiliza o implementa las que considere ms relevantes. Los atributos son las propiedades que describen a cada entidad en un conjunto de entidades. En un conjunto de entidades, cada entidad tiene valores especficos asignados para cada uno de sus atributos, de esta forma, es posible su identificacin unvoca. Ejemplos: A la coleccin de entidades alumnos, con el siguiente conjunto de atributos en comn, (id, nombre, edad, semestre), pertenecen las entidades:

(1, Sofa, 38 aos, 2) (2, Josefa, 19 aos, 5) (3, Carlos, 20 aos, 2) ...

Cada una de las entidades pertenecientes a este conjunto se diferencia de las dems por el valor de sus atributos. Ntese que dos o ms entidades diferentes pueden tener los mismos valores para algunos de sus atributos, pero nunca para todos. En particular, los atributos identificativos son aquellos que permiten diferenciar a una instancia de la entidad de otra distinta. Por ejemplo, el atributo identificativo que distingue a un alumno de otro es su nmero de id. Para cada atributo, existe un dominio del mismo, este hace referencia al tipo de datos que ser almacenado o a restricciones en los valores que el atributo puede tomar (cadenas de caracteres, nmeros, solo dos letras, solo nmeros mayores que cero, solo nmeros enteros...). Cuando algn atributo correspondiente a una entidad no tiene un valor determinado, recibe el valor nulo, bien sea porque no se conoce, porque no existe o porque no se sabe nada al respecto del mismo.

[editar] Relacin

Describe cierta dependencia entre entidades o permite la asociacin de las mismas.

Ejemplo: Dadas dos entidades "Habitacin 502" y "Henry Jonshon Mcfly Bogard", es posible relacionar que la habitacin 502 se encuentra ocupada por el husped de nombre Henry.

Una relacin tiene sentido al expresar las entidades que relaciona. En el ejemplo anterior, un husped (entidad), se aloja (relacin) en una habitacin (entidad).

[editar] Conjunto de relaciones

Consiste en una coleccin, o conjunto, de relaciones de la misma naturaleza. Ejemplo: Dados los conjuntos de entidades "Habitacin" y "Husped", todas las relaciones de la forma habitacin-husped, permiten obtener la informacin de los huspedes y sus respectivas habitaciones. La dependencia o asociacin entre los conjuntos de entidades es llamada participacin. En el ejemplo anterior los conjuntos de entidades "Habitacin" y "Husped" participan en el conjunto de relaciones habitacin-husped. Se llama grado del conjunto de relaciones a la cantidad de conjuntos de entidades participantes en la relacin.

[editar] Restricciones
Son reglas que deben mantener los datos almacenados en la base de datos.

[editar] Correspondencia de cardinalidades

Dado un conjunto de relaciones en el que participan dos o ms conjuntos de entidades, la correspondencia de cardinalidad indica el nmero de entidades con las que puede estar relacionada una entidad dada. Dado un conjunto de relaciones binarias y los conjuntos de entidades A y B, la correspondencia de cardinalidades puede ser:

Uno a Uno: Una entidad de A se relaciona nicamente con una entidad en B y viceversa (ejemplo relacin vehculo - matrcula: cada vehculo tiene una nica matrcula, y cada matrcula est asociada a un nico vehculo). Uno a varios: Una entidad en A se relaciona con cero o muchas entidades en B. Pero una entidad en B se relaciona con una nica entidad en A (ejemplo vendedor - ventas).

Varios a Uno: Una entidad en A se relaciona exclusivamente con una entidad en B. Pero una entidad en B se puede relacionar con 0 o muchas entidades en A (ejemplo empleadocentro de trabajo). Varios a Varios: Una entidad en A se puede relacionar con 0 o muchas entidades en B y viceversa (ejemplo asociaciones- ciudadanos, donde muchos ciudadanos pueden pertenecer a una misma asociacin, y cada ciudadano puede pertenecer a muchas asociaciones distintas).

[editar] Restricciones de participacin

Dado un conjunto de relaciones R en el cual participa un conjunto de entidades A, dicha participacin puede ser de dos tipos:

Total: Cuando cada entidad en A participa en al menos una relacin de R. Parcial: Cuando al menos una entidad en A NO participa en alguna relacin de R.

[editar] Claves
Es un subconjunto del conjunto de atributos comunes en una coleccin de entidades, que permite identificar unvocamente cada una de las entidades pertenecientes a dicha coleccin. Asimismo, permiten distinguir entre s las relaciones de un conjunto de relaciones. Dentro de los conjuntos de entidades existen los siguientes tipos de claves:

Superclave: Es un subconjunto de atributos que permite distinguir unvocamente cada una de las entidades de un conjunto de entidades. Si se aade un atributo al anterior subconjunto, el resultado seguir siendo una superclave. Clave candidata: Dada una superclave, si sta deja de serlo quitando nicamente uno de los atributos que la componen, entonces sta es una clave candidata. Clave primaria: Es una clave candidata, elegida por el diseador de la base de datos, para identificar unvocamente las entidades en un conjunto de entidades.

Los valores de los atributos de una clave, no pueden ser todos iguales para dos o ms instancias. Para poder distinguir unvocamente las relaciones en un conjunto de relaciones R, se deben considerar dos casos:

R NO tiene atributos asociados: En este caso, se usa como clave primaria de R la unin de las claves primarias de todos los conjuntos de entidades participantes.

R tiene atributos asociados: En este caso, se usa como clave primaria de R la unin de los atributos asociados y las claves primarias de todos los conjuntos de entidades participantes.

Si el conjunto de relaciones, R, sobre las que se pretende determinar la clave primaria est compuesto de relaciones binarias, con los conjuntos de entidades participantes A y B, se consideran los siguientes casos, segn sus cardinalidades:

R es de muchos a uno de A a B entonces slo se toma la clave primaria de A, como clave primaria de R. R es de uno a muchos de A a B entonces se toma slo la clave primaria de B, como clave primaria de R. R es de uno a uno de A a B entonces se toma cualquiera de las dos claves primarias, como clave primaria de R. R es de muchos a muchos de A a B entonces se toma la unin de los atributos que conforman las claves primarias de A y de B, como clave primaria de R.

[editar] Diagrama entidad-relacin

Anteriormente detallamos los conceptos relacionados al modelo ER, en esta seccin profundizaremos en como representarlos grficamente. Cabe destacar que para todo proceso de modelado, siempre hay que tener en claro los conceptos, estos nos brindan conocimiento necesario y adems fundamentan nuestro modelo al momento de presentarlo a terceros. Formalmente, los diagramas ER son un lenguaje grfico para describir conceptos. Informalmente, son simples dibujos o grficos que describen informacin que trata un sistema de informacin y el software que lo automatiza.

[editar] Entidades
Las entidades son el fundamento del modelo entidad relacin. Podemos adoptar como definicin de entidad cualquier cosa o parte del mundo que es distinguible del resto. Por ejemplo, en un sistema bancario, las personas y las cuentas bancarias se podran interpretar como entidades. Las entidades pueden representar entes concretos, como una persona o un avin, o abstractas, como por ejemplo un prstamo o una reserva. Se representan por medio de un rectngulo.

[editar] Atributos
Se representan mediante un crculo o elipse etiquetado mediante un nombre en su interior. Cuando un atributo es identificativo de la entidad se suele subrayar dicha etiqueta. Por motivos de legibilidad, los atributos suelen no aparecer representados en el diagrama entidad-relacin, sino descritos textualmente en otros documentos adjuntos.

[editar] Relaciones
Se representan mediante un rombo etiquetado en su interior con un verbo. Este rombo se debe unir mediante lneas con las entidades (rectngulos) que relaciona, para as saber cul es la relacin que lleva cada uno.

[editar] Diagramas extendidos

DER extendido

Los diagramas Entidad-Relacin no cumplen su propsito con eficacia debido a que tienen limitaciones semnticas. Por ese motivo se suelen utilizar los diagramas Entidad-Relacin extendidos que incorporan algunos elementos ms al lenguaje:

[editar] Entidades fuertes y dbiles

Cuando una entidad participa en una relacin puede adquirir un papel fuerte o dbil. Una entidad dbil es aquella que no puede existir sin participar en la relacin; es decir, aquella que no puede ser unvocamente identificada solamente por sus atributos. Una entidad fuerte (tambin conocida como entidad regular) es aquella que s puede ser identificada unvocamente. En los casos en que se requiera, se puede dar que una entidad fuerte "preste" algunos de sus atributos a una entidad dbil para que esta ltima se pueda identificar. Las entidades dbiles se representan- mediante un doble rectngulo; es decir, un rectngulo con doble lnea. Se puede hablar de la existencia de 2 tipos de dependencias en las entidades dbiles:

Dependencia por existencia.

Las ocurrencias de la entidad dbil pueden identificarse mediante un atributo identificador clave sin necesidad de identificar la entidad fuerte relacionada.

Dependencia por identificacin.

La entidad dbil no puede ser identificada sin la entidad fuerte relacionada. (Ejemplo: si tenemos una entidad LIBRO y otra relacionada EDICIN, para identificar una edicin necesitamos conocer el identificador del libro).

[editar] Cardinalidad de las relaciones

El tipo de cardinalidad se representa mediante una etiqueta en el exterior de la relacin, respectivamente: "1:1", "1:N" y "N:M", aunque la notacin depende del lenguaje utilizado, la que ms se usa actualmente es el unificado. Otra forma de expresar la cardinalidad es situando un smbolo cerca de la lnea que conecta una entidad con una relacin:

"0" si cada instancia de la entidad no est obligada a participar en la relacin. "1" si toda instancia de la entidad est obligada a participar en la relacin y, adems, solamente participa una vez. "N" , "M", "*" si cada instancia de la entidad no est obligada a participar en la relacin y puede hacerlo cualquier nmero de veces.

Ejemplos de relaciones que expresan cardinalidad:

Cada esposo (entidad) est casado (relacin) con una nica esposa (entidad) y viceversa. Es una relacin 1:1. Una factura (entidad) se emite (relacin) a una persona (entidad) y slo una, pero una persona puede tener varias facturas emitidas a su nombre. Todas las facturas se emiten a nombre de alguien. Es una relacin 1:N. Un cliente (entidad) puede comprar (relacin) varios servicios (entidad) y un servicio puede ser comprado por varios clientes distintos. Es una relacin N:M.

[editar] Atributos en relaciones

Las relaciones tambin pueden tener atributos asociados. Se representan igual que los atributos de las entidades. Un ejemplo tpico son las relaciones de tipo "histrico" donde debe constar una fecha o una hora. Por ejemplo, supongamos que es necesario hacer constar la fecha de emisin de una factura a un cliente, y que es posible emitir duplicados de la factura (con distinta fecha). En tal caso, el atributo "Fecha de emisin" de la factura debera colocarse en la relacin "se emite".

[editar] Herencia
La herencia es un intento de adaptacin de estos diagramas al paradigma orientado a objetos. La herencia es un tipo de relacin entre una entidad "padre" y una entidad "hijo". La entidad "hijo" hereda todos los atributos y relaciones de la entidad "padre". Por tanto, no

necesitan ser representadas dos veces en el diagrama. La relacin de herencia se representa mediante un tringulo interconectado por lneas a las entidades. La entidad conectada por el vrtice superior del tringulo es la entidad "padre". Solamente puede existir una entidad "padre" (herencia simple). Las entidades "hijo" se conectan por la base del tringulo.

[editar] Agregacin

Ejemplo agregacin

Es una abstraccin a travs de la cual las relaciones se tratan como entidades de un nivel ms alto. Se utiliza para expresar relaciones entre relaciones o entre entidades y relaciones. Se representa englobando la relacin abstrada y las entidades que participan en ella en un rectngulo. En la figura se muestra un ejemplo de agregacin en el que se representa la situacin en la que un profesor, cuando est impartiendo una clase, puede poner una incidencia ocurrida a lo largo de sta (se fue la luz, falta la configuracin de un determinado software, etc.).

[editar] Vase tambin

Ingeniera del software. Disciplina donde se encuadra el anlisis y diseo de datos. Modelo de datos. Es la visin esttica de un sistema de informacin. Base de datos. Es la implementacin de un modelo de datos. Modelo relacional. Una tcnica formal para describir modelos de datos. UML. Otro lenguaje que permite describir modelos de datos (entre otras cosas). Peter Chen. El autor del modelo entidad-relacin.

RESUMEN UNIDAD DE APRENDIZAJE I:

Una base de datos es un conjunto de objetos que se relacionan entre s para cumplir con los objetivos del negocio o rea funcional. El modelamiento de datos se encuentra en la etapa cuatro del diseo del ciclo de vida clsico de los sistemas de informacin. Para modelar correctamente una base de datos se necesita registrar los requisitos del cliente, para lograr esta meta, se utilizan preguntas clave en el momento de la entrevista, luego se documenta toda la informacin, y se elabora el modelo entidad relacin. El proceso de registrar correctamente los requerimientos del cliente se divide en 7 etapas: La etapa de Inicio representa el inicio del proyecto, identificando las necesidades del cliente. En Obtencin, capturars los requisitos del cliente alineados a los objetivos del negocio. En Negociacin la empresa desarrolladora negocia tiempos y costos, es posible que negocie hasta el alcance del proyecto, luego documenta o grafica las especificaciones del cliente, esta es la etapa de Especificaciones. En Validacin se verifica si lo conversado, documentado y graficado va de acuerdo con lo pensado por el cliente. En Gestin, se rastrea los requisitos y los cambios a estos en mientras se desarrolla el proyecto. El modelo entidad relacin es el modelo conceptual ms utilizado, est formado por entidades, atributos y relaciones. Actualmente se le conoce como el modelo entidad relacin extendido, al agregar elementos como la generalizacin y especializacin y la agregacin, aspectos que sern explicados ms adelante. Ya sea en un sistema de ventas o alquiler, el fin es describir en un diagrama entidad relacin el sistema de informacin, para ello debemos saber cmo se realizan las actividades del negocio, luego identificamos las entidades involucradas, agregamos los atributos necesarios para cada entidad y establecemos las relaciones entre entidades.

Para un sistema de venta las entidades principales son: Proveedor, clente, producto, factura. A diferencia, en el sistema de alquiler las entidades necesarias son: Pelcula, actor, socio, ejemplar y alquiler.

MODELO LOGICO

Introduccin
a)Presentacin y contextualizacin
En esta unidad aprender los conceptos y aplicaciones sobre el Modelo Lgico con relaciones de generalizacin o especializacin, relaciones entre muchos a muchos, la conversin de tabla en el modelo relacional. Le invito a tomar los valiosos conocimientos que contiene esta unidad, siguiendo detalladamente la metodologa planteada.

b)Competencia
Comprende los conceptos del modelo relacional y desarrollar casos prcticos.

c) Capacidades
1. Modela bases de datos utilizando especializacin-generalizacin cuando sea necesario. 2. Comprende y aplica los conceptos fundamentales del modelo relacional. 3. Transforma el modelo entidad relacin a modelo relacional. 4. Desarrolla casos prcticos utilizando el modelo relacional.

d)Actitudes
Analiza a conciencia los conceptos fundamentales sobre especializacin y generalizacin. Genera hbitos estudiando los conceptos sobre el modelo relacional. Responsable en la entrega de trabajos prcticos. Comparte sus conocimientos con su grupo de trabajo en cuanto a los casos sobre el modelo relacional.

e) Ideas bsicas y contenido esenciales de la Unidad:

La Unidad de Aprendizaje 02: Modelo Lgico comprende el desarrollo de los siguientes temas: TEMA 01: ESPECIALIZACIN Y GENERALIZACIN TEMA 02: MODELO RELACIONAL

TEMA 03: MAPEO DE TABLAS

TEMA 04: CASO VIDEO CLUBS

Tema 01: Especializacin y Generalizacin

La especializacin se forma cuando se incluyen subgrupos de entidades que se diferencian de alguna forma de las otras entidades del conjunto. Abraham Silberschatz

La especializacin se centra en agrupar entidades comunes, por ejemplo: la entidad cuenta se divide en cuenta de ahorros y cuenta corriente.

CUENTA_AHORRO
Nro_cuenta moneda Tipo_interes

CUENTA_CORRIENTE
Nro_cuenta Moneda Saldo_minimo

La especializacin quedara de la siguiente manera.

CUENTA_AHORRO Generalizacin Especializacin

Nro_cuenta moneda

CUENTA_AHORRO
Tipo_interes

CUENTA_CORRIENTE
Saldo_minimo

En cambio la Generalizacin se basa en entidades que tienen atributos comunes, se forma entonces una entidad super tipo con

atributos generales y otras entidades sub tipo con atributos diferentes, por ejemplo:

ALUMNO
Cdigo Nombre Paterno Materno Carrera facultad

PROFESOR
Cdigo Nombre Paterno Materno tipo pensin

Observamos que la entidad ALUMNO y PROFESOR tienen atributos comunes: cdigo, nombre, paterno, materno, estos atributos forman parte de la entidad super tipo, que llamaremos PERSONA.

PERSONA
Cdigo Nombre Paterno Materno El modelo terminado quedara de la siguiente manera:

PERSONA Generalizacin Especializacin

Cdigo Nombre Paterno Materno

ALUMNO
carrera facultad

PROFESOR
Tipo_pensin

IMPORTANTE
Si hay confusin en diferenciar la Generalizacin de la especializacin, hay que verlo de la siguiente manera, la generalizacin agrupa atributos comunes en diferentes entidades, en cambio la especializacin extiende entidades, como cuenta, la extendi a cuenta corriente y cuenta de ahorros.

AGREGACIN

Construccin que se utiliza principalmente cuando existen relaciones de muchos a muchos.

En el modelo entidad relacin no se rompe las relaciones de muchos a muchos, solamente se deja expresado, la agregacin se utiliza cuando existen entidades que se tienen que relacionar con la entidad resultante de la relacin de muchos a muchos, observe el siguiente ejemplo: En el caso alquiler de video, haba una relacin PELICULA ACTOR, donde un actor poda participar en muchas pelculas y en una pelcula participaban varios actores, pero la problemtica radica en cul de las dos entidades se debe colocar el atributo tipoactor(principal o secundario), cuyo propsito sera definir cules son actores principales y cuales son actores secundarios, observe la

solucin:

PELICULA
Titulo Nacionalidad Productora fecha director Cdigo tipo

ACTOR
Nombre Nacionalidad Sexo

TIPO_ACTOR

Con esta constru ccin si se podra contest ar quienes son los actores principa les y secund arios de

una pelcula en especial. En el captulo modelo relacional, se describe y explica la forma de transformar este modelo conceptual a relacional.

Tema 02: Modelo Relacional

Es el tipo de modelo lgico ms utilizado, sus principales componentes son las tablas, campos, datos y registros (tuplas), adems es empleado por casi todos los gestores de base de datos relacionales.

Modelo propuesto por E.F Cood en los laboratorios de IBM en California. Se trata de un modelo lgico que establece una estructura sobre los datos, aunque posteriormente estos puedan ser almacenados de mltiples formas.

TABLA
Es todo aquello que se le puede registrar datos o recoger informacin importante para la empresa. Una tabla contiene informacin y est compuesta por datos, a la vez estos datos tienen tipos de datos y

una longitud.

CAMPO
Caracterstica que describe a una tabla, adems los campos representan las propiedades bsicas de las tablas y sus relaciones.

DATO
Elementos conocidos que van dentro de los campos, por ejemplo: el campo nombre el dato Manuel, el campo telfono el dato 2700860, el campo edad el dato 25.

REGISTRO

Contiene una fila de datos en una tabla de informacin.

Para entender mejor los conceptos ver el siguiente grfico:

En

la

tabla

anterior

se

explica del

los

conceptos

fundamentales

modelo

relacional, como se observa la tabla est compuesta por campos como CODIGO,

PATERNO, MATERNO, NOMBRE, datos como 001, Arenas, Olivera, 002, etctera, registros o fila, como 001

MarengoCribilleros Mario, ese conjunto de datos forman un registro. Esa es una forma de representar a una tabla la otra forma es muy parecida a una entidad, con la diferencia que a los campos se le agrega tipos de dato, longitud y si el campo es nulo o no nulo. Antes de representar la otra forma de una tabla, echemos un vistazo a los tipos de datos ms comunes: Cuando el dato es un nmero numrico

Cuando el dato es cadena de caracteres, como un nombre Cuando el dato es fecha u hora hora Cuando el dato es imagen Cuando el tipo de dato tiene dos estados Otra forma de representar la tabla es la siguiente imagen booleano cadena fecha o

ALUMNO
Cdigo Nombre Paterno Materno IMPORTANTE Cundo colocar nulo a un campo?,Solamente se debe colocar nulo a un campo, si en algn caso, existiera un dato que se dejara en blanco, por ejemplo el campo telfono. CODIGO PATERNO MATERNO NOMBRE TELFONO cadena(3)no nulo cadena(40)no nulo cadena(40)no nulo cadena(40)no nulo

001 002 003 004

Marengo Daz Velarde De los palotes

Cribilleros Arenas Olivera Prez

Mario Carolina Jorge Perico

998998855 981186286

988889563

Se observa en la tabla anterior que el alumno Jorge no tiene nmero telefnico, entonces el campo telfono es de tipo nulo.

CLAVE CANDIDATA

Campos de la tabla a ser clave primaria, una de sus caractersticas es que sus datos no se repiten. Por lo general se debe seleccionar varios campos si los hubiera, aunque en la mayora de los casos solamente uno ser el primario. Observe el siguiente ejemplo: TABLA: AUTOMOVIL NMATRICULA CCA-341 OFG-851 XTV-657 WGB-959 NMOTOR 91123659802 53244659887 12236698988 50602233598 MARCA Toyota Fiat Ford Toyota MODELO Yaris Fiorino Mustang Avensis

En la tabla anterior el campo NMATRICULA y NMOTOR, sus datos no se repiten, por lo tanto son las claves candidatas, porque son las candidatas a ser primarias.

IMPORTANTE Finalmente las claves candidatas solamente sirven para seleccionar al campo primario. En el modelo relacional el campo primario y forneo son los nicos elementos que se contemplan.

CLAVE PRIMARIA
Es un campo cuyos datos no se repiten y sirven para las relaciones entre tablas. Observe la explicacin de clave primaria en el siguiente ejemplo: TABLA: AUTOMVIL NMATRICULA CCA-341 OFG-851 XTV-657 WGB-959 NMOTOR 91123659802 53244659887 12236698988 50602233598 MARCA Toyota Fiat Ford Toyota MODELO Yaris Fiorino Mustang Avensis

Realmente cualquiera de las dos claves candidatas puede ser clave primaria, para este caso se escoge al campo NMOTOR como clave principal. Observe la tabla con otro tipo de vista:

AUTOMOVIL
Nmatriculacadena(7) no nulo Nmotor(PK) cadcena(11)no nulo Marca cadena(40) no nulo Modelo cadena(40)no nulo

No siempre la clave primaria se encuentra entre los campos de una tabla sino se debe agregar un campo para definir la clave principal de la tabla. El motivo es por supuesto que tanto para el caso del campo NMOTOR y NMATRICULA, el usuario final ingresara los datos y estara latente el posible error de ingreso de datos.No se debe permitir que el usuario final ingrese los datos del campo clave principal, sino ms bien el sistema gestor o un algoritmo de programacin deben generarlo. Realmente cualquiera de las dos claves candidatas puede ser clave primaria, para este caso se escoge al campo NMOTOR como clave principal. Observe la tabla con otro tipo de vista:

AUTOMOVIL
Cdigo (PK) cadena(10)no nulo no nulo

Nmatricula cadena(7) Nmotor Marca Modelo

cadena(11)no nulo cadena(40)no nulo cadena(40)no nulo NMOTOR 91123659802 53244659887 12236698988 50602233598 MARCA Toyota Fiat Ford Toyota MODELO Yaris Fiorino Mustang Avensis

NMATRICULA CCA-341 OFG-851 XTV-657 WGB-959

Ahora la clave primaria de la tabla AUTOMOVIL, es cdigo, este campo cumple con las caractersticas de campo primario, porque sus datos no se repiten. Otra caracterstica importante es que los datos no sern ingresados por el usuario final, por lo tanto no existe la posibilidad de tener errores en el ingreso de

datos.

CLAVE FORNEA, AJENA O EXTERNA

Tiene varios nombres, no obstante alguna de sus caractersticas son las siguientes:

oConsta de un campo que es primario en la

tabla origen oPermite relacionar tablas afines oMecanismo para asegurar la integridad de los datos Observen el siguiente grfico:

CLIENTE

FACTURA

Codigocliente(PK) cadena(6) no nulo Apellido Codigofactura(PK) cadena(40) no nulo Nombre cadena(40 cadena(10 ) no nulo Codigocliente(FK) cadena(6) no nulo Fecha fecha no
La relacin entre CLIENTE y FACTURA es de uno a muchos, se identifica que la clave primaria de cliente es codigocliente y de FACTURA codigofactura.

Entonces se observa que la pata de gallo (relacin de muchos) se encuentra en factura, por lo tanto la clave primaria de CLIENTE se agrega como campo de la tabla FACTURA pero como clave fornea. Un aspecto clave a considerar es que el tipo de dato y la longitud debe ser el mismo tanto en la tabla CLIENTE como en la tabla FACTURA.
Para que quede claro, observe la relacin entre PELICULA a EJEMPLAR:

PELICULA
Idpelicula(PK) cadena(6) no

EJEMPLAR

nulo Titulo

cadena(60) no nulo

Nro(PK)

cadena(10)

no nulo Estado cadena(1)no nulo Idpelicula(FK) cadena(6) no nulo no

Nacionalidad cadena(50) no nulo Productora cadena(50) no nulo Fecha fecha

nulo Director cadena(60) no nulo La duda se encuentra en seleccionar la clave primaria de PELICULA o la clave primaria de EJEMPLAR, la respuesta es fcil, observe siempre donde se encuentra la pata de gallo (marcada con color rojo en esta ocasin), para este caso est en EJEMPLAR, entonces la clave primaria de PELICULA, se agrega como campo forneo en EJEMPLAR, con la misma longitud y tipo de dato. El nombre del campo clave no es necesario que sea el mismo, si se cambia no hay ningn error. Observe ahora el resultado pero con datos para ambas tablas: TABLA: PELICULA

idpelicula P00001 P00002

Titulo Las crnicas

nacionalidad productora fecha Inglesa Warner Bros Warner Bros

Director

15/10/2010 Michael Apted 10/02/2000 Luis Llosa

Anaconda Peruana

TABLA: EJEMPLAR Nro Estado idpelicula

0000000001 0000000002 0000000003

1 1 1

P00001 P00002 P00003

Solo para terminar la idea, existen dos ejemplares para las crnicas y un ejemplar para Anaconda.

INTEGRIDAD REFERENCIAL DE LOS DATOS

En la tabla ejemplar no pueden existir datos de pelculas que no existan en la tabla PELCULA, porque se romperan las reglas de integridad de los datos, es ms los gestores de base de datos validan esta regla. La integridad referencial de los datos se refiere a que los datos que se agregan en el campo forneo tienen que existir en el primario.

RELACIONES
En cuanto a las relaciones, son las mismas que se explicaron en el modelo entidad relacin, es decir de uno a muchos, de muchos a muchos y de uno a uno.

Tema 03: Mapeo de Tablas

QU ES EL MAPEO?
Es el proceso mediante el cual una entidad del modelo entidad relacin se convierte en tabla

del modelo relacional.

Observemos el caso matricula

Se observa la entidad ALUMNO relacionada con la entidad MATRICULA:

ALUMNO
idalumno Apellido Nombre direccion

MATRICULA
idmatricula mat_fecha mat_grado mat_seccion mat_nive El mapeo de estas dos tablas a modelo relacional, se representa de la siguiente forma.

ALUMNO

MATRICULA

Idalumno(PK) cadena(6) no nulo Apellido no nulo cadena(40)

Idmatricula(PK) cadena(10) no nulo mat_fechafechano nulo mat_gradocadena(15) no

Nombre no nulo

cadena(40)

nulo mat_seccion cadena(5) no

Direccincadena(60) no nulo

nulo mat_nivelcadena(15) no nulo

idalumno(FK)cadena(6)no nulo Como se observa el mapeo es cosa fcil, solamente consiste en lo siguiente:

oCambiar el nombre
de la entidad por tabla.

o Agregar el tipo de
dato a los campos de la tabla. o Agregar la longitud del campo. o Especificar si el campo es nulo o no nulo.

oAgregar la clave
primaria y fornea si existiera.

oSe cambia el
nombre atributo por campo.
La segunda forma de representar una tabla es la siguiente TABLA: ALUMNO

IDALUMNO
000001

APELLIDO
Daz Arenas

NOMBRE
Daniel

DIRECCION
Calle Moyobamba 425 Urb. La Primavera Jr. Los precursores 567 Urb. Los vicus Av. Los prncipes 678Urb. Los tallanes

000002

Vaca Toro

Pedro

000003

Velsquez Pesantes

Mara

TABLA: MATRICULA
IDMATRICULA MAT_FECHA MAT_GRADO MAT_SECCION MAT_NIVEL IDALUMNO

0000000001 10/02/2011 Primero 0000000002 10/02/2011 Segundo

A A

Secundaria Secundaria

000002 000001

En este tipo de vista se muestran adems de las

relaciones los datos de las tablas, por lo tanto es muy valioso, es una forma de comprobar si las relaciones del modelo entidad relacin son correctas.

El siguiente caso representa la relacin entre cliente y factura, veamos cmo queda con el modelo relacional.

CLIENTE

FACTURA

Codigo Apellido Nombre Dni ruc

Codigofactura Fecha Nroserie Total Subtotal igv El modelo Mapeado queda de la siguiente manera:

CLIENTE

FACTURA

Codigocliente(PK)cadena(6)no nulo Apellidocadena(40) no nulo Nombrecadena(40) no nulo Dnicadena(8)no nulo Ruccadena(11) no nulo

Codigofactura(PK) cadena(10) no nulo Codigocliente(FK)cadena(6)no nulo Fechafecha no nulo Nroserie numricono nulo Totaldecimalno nulo Subtotaldecimalno nulo Igv decimalno nulo

Si recordamos el modelo entidad relacin, cada vez que se encontraba una relacin de muchos a muchos, se dejaba sin desarrollar, aunque se sabe que este tipo de relaciones se rompe para formar otras tablas.
Estas acciones de formar nuevas tablas con las relaciones de muchos a muchos se desarrollan con el modelo relacional, veamos un ejemplo:

La relacin entre alumno y habilidad es de muchos a muchos como se ve expresada en el siguiente grfico:

Se agrega la tabla ALUMNO_HABILIDAD con las claves primarias correspondientes deALUMNO y

HABILIDAD,por este motivo las dos relaciones son de uno a muchos tanto de la tabla ALUMNO a ALUMNO_HABILIDAD y HABILIDAD a ALUMNO_HABILIDAD. Aplicando la lgica, se necesita una construccin de este tipo para almacenar los datos correspondientes a alumnos con sus respectivas habilidades, a continuacin se explica con el siguiente grfico. TABLA: ALUMNO

CODIGO
000001 000002

APELLIDO
Daz Arenas Marengo Cribilleros

NOMBRE
Daniel Karina

DNI
16791125 10544342

TABLA: HABILIDAD

CODIGOHABILIDAD
00001 00002 00003 TABLA: ALUMNO_HABILIDAD

NOMBRE_HABILIDAD
Cantar Lectura veloz Bailar

CODIGO
00001 00002

CODIGOHABILIDAD
00001 00002

00003

00003

De esta forma queda terminado el mapeo de una relacin de muchos a muchos.

MAPEO DE UNA GENERALIZACIN/ESPECIALIZACIN

La entidad supertipo PERSONA tiene dos entidades subtipo ALUMNO y PROFESOR. El modelo entidad relacin se expresa en el siguiente grfico

Generalizacin entidad PERSONA El mapeo se representa en el siguiente grfico:

La PK (primary key o clave primaria) de persona aparece tanto en la tabla ALUMNO como en PROFESOR, as se establece un nexo entre ALUMNO y PERSONA o PROFESOR o PERSONA. Es preciso recalcar que la clave primaria de PERSONA, sera fornea (FK) tanto en la tabla PROFESOR como en la tabla ALUMNO.

Tema 04: Caso Video Clubs

La cadena de Video Clubs Gusters ha decidido, para mejorar su

servicio, emplear una base de datos para almacenar referente a la las

informacin

pelculas que ofrece en alquiler. Esta informacin es la siguiente: Una pelcula se caracteriza por un titulo, nacionalidad, productora y fecha. En una pelcula pueden participar varios actores (nombre,

nacionalidad, sexo) algunos de ellos como actores principales. Una pelcula est dirigida por un director (nombre, nacionalidad). De cada pelcula se dispone de uno o varios ejemplares diferenciados por un nmero de ejemplar y caracterizados por su estado de conservacin. Un ejemplar se puede encontrar alquilado a algn socio (DNI, nombre, direccin, telfono). Se desea almacenar la fecha de comienzo del alquiler y la de devolucin. Un socio tiene que ser avalado por otro socio que responda de l en caso de tener problemas en el alquiler. Veamos el modelo entidad relacin del caso alquiler de video

El mapeo a modelo relacionar comienza cambiando las entidades a tablas. Primero se selecciona las tablas que tienen relaciones de muchos a muchos.

PELICULA
Idpelicula(PK)cadena(5) no nulo Titulocadena(40)no nulo Idactor nulo

ACTOR
(PK)cadena(5)no

Nombrecadena(60)no nulo Nacionalidadcadena(50)no

nulo Productoracadena(50)no nulo Fechacadena(50) no nulo Directorcadena(50)no nulo

Nacionalidadcadena(50)no nulo Sexocadena(1)no nulo Tipoactorcadena(15)no nulo

Una vez que las tablas han sido mapeadas, se rompen las relaciones de muchos a muchos, y se agrega una nueva tabla, en este caso PELICULA_ACTOR.

EJEMPLAR
Nro Estado Se mapea de la siguiente manera

ALQUILER
Fecha_inicio Fecha_final

En la tabla DETALLE_EJEMPLAR, la clave primaria es una clave compuesta formada por idejemplar y idalquiler. El modelo final quedara de la siguiente manera:

El modelo relacional.

EL MODELO RELACIONAL
En captulos anteriores hemos estudiado que existen distintos modelos segn los cuales la informacin puede ser almacenada y relacionada entre s. Actualmente, para la mayora de las aplicaciones de gestin que utilizan bases de datos, el modelo ms empleado es el modelo

relacional, por su gran versatilidad, potencia y por los formalismos matemticos sobre los que se basa. Este modelo permite representar la informacin del mundo real de una manera intuitiva, introduciendo conceptos cotidianos y fciles de entender por cualquier inexperto. Asimismo, mantiene informacin sobre las propias caractersticas de la base de datos (metadatos), que facilitan las modificaciones, disminuyendo los problemas ocasionados en las aplicaciones ya desarrolladas. Por otro lado, incorpora mecanismos de consulta muy potentes, totalmente independientes del S.G.B.D., e incluso de la organizacin fsica de los datos; el propio S.G.B.D. es el encargado de optimizar estas preguntas en formato estndar, a sus caractersticas propias de almacenamiento. El modelo relacional fue propuesto por E.F. Codd en los laboratorios de IBM en California. Se trata de un modelo lgico [Irene Luque Ruiz- Ed. Ra-ma], que establece una estructura sobre los datos, aunque posteriormente stos puedan ser almacenados de mltiples formas para aprovechar caractersticas fsicas concretas de la mquina sobre la que se implante la base de datos realmente. Es algo as como guardar unos libros en una biblioteca; dependiendo del nmero de salas de la biblioteca, del tamao y forma de cada una de ellas, su nmero de estanteras, y en definitiva, de las caractersticas fsicas del recinto, podremos disponer los libros de una forma u otra para hacer ms cmoda y fcil su consulta y acceso. Los libros son los mismos, pero pueden ubicarse de muy distintas formas. Vamos a estudiar entonces, las caractersticas concretas de este modelo de datos, sin entrar para nada en cmo los almacena fsicamente cada ordenador, o cada S.G.B.D.

Estructura general.
El nombre de modelo relacional viene de la estrecha relacin que existe entre el elemento bsico de este modelo, y el concepto matemtico de relacin. Podemos decir que una relacin R sobre los conjuntos D1, D2, .., Dn, se define como: R D1 D2 ... Dn donde los conjuntos D1, D2, .., Dn pueden ser cualesquiera, e incluso estar repetidos.
El modelo relacional.

2
Juan Antonio Pedro Cocinero 100 Botones 200 500 700 1200

Nombre Oficio Sueldo

- Juan Cocinero 100

- Pedro Botones 700 - Juan Cocinero 200 - Pedro Cocinero 700 - Juan Cocinero 1200
Esto e s una relacin.
Dado q ue se trata de un con ju nto n o pued e haber elemen to s repetid os.

Nombre Oficio Sueldo

Los conjuntos pueden ser cualesquiera, aunque en el momento en que se trabaja con ordenadores, hay que imponer ciertas restricciones de discretizacin. Si nos fijamos en el dibujo adjunto, podemos ver que una de estas relaciones no es ms que una lista de lneas, donde cada lnea est dividida en trozos. Para observar bien el porqu ha surgido el mtodo relacional, pensemos en cmo almacenaramos las lneas de la lista anterior, si los ordenadores no existiesen. Para almacenar estas lneas, tendramos que emplear papel, de manera que en un folio escribiramos todas las lneas de la lista, empezando por la primera y continuando en el folio secuencialmente; si el folio se acaba, cogemos otro, y hacemos la misma operacin, de forma que, al final, la lista est escrita o almacenada en varios folios. Este mtodo, que es el ms directo, tiene el problema de qu ocurre cuando se desean introducir nuevas lneas. Inicialmente, la tarea parece fcil, pues nos basta con seguir escribiendo lneas tras la ltima lnea de la ltima pgina, e ir tomando nuevos folios a mediada que las pginas se vayan llenando. No obstante, este mtodo slo es adecuado si las lneas no estn ordenadas segn un criterio. Si las lneas ya estn ordenadas, y deseamos introducir una nueva, cmo lo hacemos?, escribiendo una lnea por enmedio con letra ms pequea?, o bien escribiendo de nuevo todas las lneas, pero esta vez con la que se desea insertar? Est claro que ninguna de estas posibilidades es una solucin factible. Otra posibilidad de registrar esas lneas es utilizando una ficha de cartn para cada una de ellas. Cada ficha de cartn ser parecida a las que el alumno rellena para el profesor de cada asignatura a la que asiste, con la variante de que en lugar de poner el nombre, apellidos, direccin, etc. del alumno, se pondr la informacin que nos interese guardar. de esta manera cada lnea

queda almacenada en una ficha de cartn. Si se desea insertar una nueva ficha basta con rellenarla y meterla en su posicin adecuada. De la misma forma se puede proceder a la hora de eliminar alguna ficha. Pues bien, este ltimo mtodo es el que, a grandes rasgos, intenta utilizar el modelo relacional. El modelo relacional representa las listas de lneas mediante registros o fichas cada una de las cuales puede ser manejada individualmente y con independencia de las dems. No obstante, a efectos de facilitar la visualizacin, puede ser posible ver todas las lneas juntas como si de una
El modelo relacional.

3
Nombre: Juan Oficio: Cociner o Sueldo: 100 Nombre: Pedro Oficio: Botones Sueldo: 700 Nombre: Juan Oficio: Cociner o Sueldo: 200 Nombre: Pedro Oficio: Cociner o Sueldo: 700 Nombre: Juan Oficio: Cociner o Sueldo: 1200

Cdigo Nombre Precio Men

15 23 17 34 12 21 07 Solomillo a la pimienta Fondue Nechatel Migas con chocolate Ajo blanco con uva s Paella valenciana Mono a la cantonesa Sopa de aleta de tiburn 1000 1500 850 850 1100 7500 525 No No S S S No S

PLATOS

lista se tratase. Ver figura. De esta manera, tendremos varios tipos de fichas: fichas de clientes, de proveedores, de facturas, de albaranes, de reservas, de empleados, de apuntes contables, etc., cada una de las cuales podemos almacenar en un cajn o en un fichero independiente. De cada tipo de ficha tendremos un montn de fichas rellenas: 100 200 clientes, 4 5 proveedores, miles de facturas, etc. Por tanto, es interesante distinguir entre un tipo de ficha, que no hace referencia a ninguna ficha rellena en concreto (p.ej. una ficha de clientes), y una ficha concreta, rellena con unos datos concretos (la ficha de Juan el Cocinero). Pues bien, el modelo relacional plasma en un ordenador este mismo esquema, aprovechando las enormes caractersticas de computacin y almacenamiento de las mquinas actuales.

Concepto de tabla. Dominios y atributos.

Una tabla en el modelo relacional viene a ser como una de las listas descritas anteriormente. Una tabla o relacin es una matriz rectangular que almacena lneas con una estructura concreta: La primera lnea de una tabla, es una cabecera que indica el nombre de cada columna. O sea, cada columna tiene asignado un nombre nico, e indica que los temes almacenados en esa columna deben pertenecer a un conjunto de valores concreto: Nmeros, Letras, Frases, etc. Cada lnea (excepto la primera) recibe el nombre de tupla, y almacena temes concretos para cada columna. Todas las filas deben ser diferentes entre s. El orden de las filas y de las columnas carece de importancia a efectos del S.G.B.D. Este hecho es el que verdaderamente diferencia las tablas relacionales del concepto matemtico de relacin, en el que el orden de las columnas es fundamental. En la figura aparece una tabla de
El modelo relacional.

4 Platos. Toda tabla debe poseer al menos la primera lnea, que identifica el nombre de la columna. En este caso, nuestra tabla o relacin contiene las columnas Cdigo, Nombre, Precio y Men (que

indica si ese plato pertenece o no a las opciones del men del da). El grado de esta tabla es el nmero de campos que posee, en nuestro caso 4. La cardinalidad es el nmero de tuplas concretas que almacena: 7. Ntese que el grado de una tabla es independiente del momento en que observemos la tabla (el nmero de columnas es invariable, y queda definido en el momento en que se crea la tabla), mientras que la cardinalidad depende de la situacin real que represente la tabla y puede variar en el tiempo; p.ej., la lista de platos puede cambiar todos los meses, o segn la estacin del ao, para adecuarse a los gustos propios de cada una de ellas. La primera fila de una t abla es la ms importante, ya que nos da su estructura. Esta columna identifica los nombres de campo o atributos de que consta cada tabla. En otras palabras, cada tupla est formada por un conjunto de informacin estructurada en elementos ms simples llamados atributos. El nombre del atributo debe describir el significado de la informacin que representa. En la tabla Platos, el atributo Precio tendr como cometido almacenar el valor en pesetas con el que ese plato se vende al pblico. A menudo suele ser necesario aadir una pequea descripcin a cada atributo que aclare su naturaleza: el precio lleva I.V.A. o no? En el atributo Men no est claro que es lo que se almacena. Una descripcin del mismo aclarara ms las cosas: Indica si el cliente puede pedir este plato o no en el men del da. Por otro lado, est claro que un atributo en una tupla no puede tomar un valor cualquiera, p.ej., no tiene sentido que en el precio del Ajo blanco con uvas se guarde una palabra como pueda ser Gerente. Para evitar este tipo de situaciones anmalas en la medida de lo posible, obligaremos a que cada atributo slo pueda tomar los valores pertenecientes a un conjunto de valores previamente establecido, o sea, un atributo tiene asociado un dominio de valores. En el caso anterior se tiene que el atributo Precio slo puede tomar valores numricos, mientras que el Nombre slo puede contener frases textuales. Los dominios a que puede pertenecer un atributo, suelen depender de los que proporcione el S.G.B.D. que empleemos. Suelen ser comunes dominios como: TTeexxttoo,, Nmeerroo eenntteerroo,, Nmeerroo ddeecciimaall,, FFeecchhaa,, Hoorraa,, SS//Noo, etc. Por otro lado, un dominio como pueda ser Nmeerroo eenntteerroo, es un dominio cuyo conjunto de valores es infinito, y dado que trabajamos con ordenadores, es imprescindible poner un lmite que permita almacenar un valor concreto debido a las limitaciones de memoria, y sobre todo al

hecho de que toda tupla debe poseer el mismo tamao. Tomemos como ejemplo el Nombre del Plato, que es evidentemente del tipo TTeexxttoo; las limitaciones del ordenador nos impiden almacenar nombres ilimitadamente largos, como puedan ser Magret de pato al vinagre de grosella con guarnicin de higos malagueos al vino moscatel Pedro Ximnez. Es neces ario, p or tanto, establecer una cota al nmero mximo de letras que podemos teclear, por lo que el dominio del atributo Nombre puede ser TTeexxttoo ddee 2200 ccaarraacctteerreess.
El modelo relacional.

5 As, la estructura completa de la tabla Platos quedara como sigue: Platos: Cdigo. Nmeerroo eenntteerroo.. Nmero con el que el plato aparece en la carta. Nombre. TTeexxttoo ddee 2200 ccaarraacctteerreess.. Nombre del plato. Precio. Nmeerroo ddeecciimaall ssiimppllee.. Precio del plato. no incluye I.V.A. ni descuentos, etc. Men. SS//Noo.. Indica si ese plato puede ser consumido dentro del precio del men del da. La informacin anterior son los metadatos que definen la estructura de la tabla. Algunos S.G.B.D. simplifican la tarea de indicar el dominio de un atributo, asignando un dominio por defecto, o estableciendo una jerarqua de dominios. P.ej., M icrosoft Access toma como dominio por defecto el TTeexxttoo, y en concreto ddee 5500 ccaarraacctteerreess. Se pueden cambiar los dominios a uno cualquiera dentro de las siguientes posibilidades: TTeexxttoo,, Nuumrriiccoo,, FFeecchhaa//Hoorraa,, Moonneeddaa,, SS//Noo,, Meemoo,, Auuttoonnuumrriiccoo,, Obbjjeettoo OLLEE,, o Hiippeerrvvnnccuulloo. A su vez, cada uno de estos tipos se puede dividir en otras clases, una de las cuales es la que se toma por defecto; p.ej. el tipo Nuumrriiccoo tiene a su vez los subtipos: Byyttee,, EEnntteerroo,, EEnntteerroo llaarrggoo,, SSiimppllee y Doobbllee.. Si slo escogemos Nuumrriiccoo, por defecto se toma el subtipo EEnntteerroo llaarrggoo, que permite guardar nmeros enteros (sin parte decimal) desde el -2.147.483.648 hasta el 2.147.483.647. Si el subtipo por defecto no es el que se quiere puede especificarse otro. Independientemente del dominio a que pertenezca un atributo, cualquier atributo puede tomar un valor especial que designa la ausencia de dato; es el valor NULO (en ingls NULL o NIL). Cuando, por cualquier circunstancia, se desconoce el valor de un atributo, como p.ej. la

direccin de un cliente, o bien ese atributo carece de sentido (el atributo Telfono de un empleado que no tiene telfono en su casa), podemos asociar a dicho atributo este valor especial, comn a cualquier dominio. El equivalente en nuestro smil de las fichas de cartn sera dejar ese hueco en blanco. Hay que hacer notar la diferencia entre el valor NULO, y el valor espacios en blanco; el ordenador considera un espacio en blanco como cualquier otro carcter, por lo que a efectos computacionales, la introduccin de caracteres espacios en blanco es distinta al concepto de ausencia de informacin. Los espacios en blanco s son datos, y pertenecen al dominio TTeexxttoo.

Restricciones.
En el apartado anterior observamos que cada atributo est obligado a tomar un valor
El modelo relacional.

6 perteneciente a un dominio concreto, siendo imposible el que guarde otro distinto. Esto supone una restriccin sobre los atributos Otras restricciones ya comentadas son: La imposibilidad de repetir tuplas en una misma tabla. La imposibilidad de establecer un orden en las tuplas, aunque algunos S.G.B.D. relajen un poco esta restriccin. En este apartado vamos a introducir otras restricciones ms importantes que posee el modelo relacional, as como los conceptos implicados. Por ltimo veremos las posibilidades que tiene el usuario para definir restricciones en funcin de las caractersticas propias de su trabajo.

Reglas fundamentales. Claves.

El modelo relacional intenta representar con una tabla a un tipo de objetos de la vida real, como puedan ser Empleados, Clientes, etc., e incluso considera las relaciones entre estos objetos como objetos en s mismos. Para ello, designa cada tipo de objetos por un conjunto de atributos que son los que darn la forma particular a cada objeto. Volvamos al caso de nuestra tabla de Platos. Para representar a un Plato, hemos escogido los atributos: Cdigo, Nombre, Precio y Men. Un plato concreto puede ser p.ej., (17, Migas con chocolate, 850, S). Este plato concreto, como cualquier otro objeto distinguible del mundo real posee unas caractersticas que lo distinguen de los dems de su mismo tipo, tal y como lo hace el ADN de una persona. El ADN

conforma la esencia o clave de toda persona. Es ms, todo objeto posee algo concreto que lo hace diferente; incluso puede poseer ms de una cosa por la que se le puede diferenciar: una persona puede distinguirse tambin por su nacionalidad y su D.N.I., lo que conforma otra clave de esa persona. Como en una tabla, las tuplas pueden estar en cualquier orden, no podemos referenciar una tupla concret a mediante su posicin entre las dems, y necesitamos alguna forma de seleccionar una tupla concreta. La forma de hacerlo es mediante una clave. Una clave es un atributo o conjunto de atributos cuyo valor es nico y diferente para cada tupla. Cada tabla puede poseer ms de una clave. P.ej., en nuestro caso de la tabla Platos, la clave puede ser tanto el atributo Cdigo, como el atributo Nombre. Tenemos dos claves potenciales, tambin llamadas claves candidatas. De entre todas las claves candidatas, el administrador, cuando define la tabla, debe decidir cul de ellas va a ser la clave principal o clave primaria, mientras que el resto de las claves pasan a denominarse claves alternativas o claves alternas. La distincin entre clave principal y claves alternativas, es slo a efectos de acceso interno a los datos, y para que el S.G.B.D. adopte ciertas decisiones sobre cmo almacenar esos datos en los sistemas de almacenamiento masivos.
El modelo relacional.

7 Por otro lado, la clave de una tabla debe ser propia, o sea, ninguno de los atributos que la forman debe ser superfluo. Siguiendo con la tabla de Platos, si tomamos el grupo de atributos (Cdigo, Precio), vemos que posee todas las caractersticas necesarias para considerarlo como una clave candidata. sin embargo, el atributo Cdigo por s slo ya es una clave candidata, con lo cual el hecho de aadir el atributo Precio y crear una clave nueva, no aporta informacin de identificacin, ya que el resto de los atributos (el Cdigo en este caso) identifica por s slo a una tupla de la tabla de Platos. As pues, el atributo Precio es superfluo en el grupo de atributos (Cdigo, Precio), con lo que dicho grupo no es una clave candidata. Para distinguir cuando un grupo de atributos es clave o no, basta con probar con ir eliminando uno a uno cada uno de los atributos del grupo; si los atributos restantes s iguen poseyendo las propiedades de clave, el atributo eliminado es superfluo, por lo que el grupo de atributos de partida no es clave propia. Ms adelante veremos como esta situacin se deriva del hecho de que el valor del atributo

que sobra (el superfluo) viene determinado por los valores de los otros atributos (la clave propia), en lo que se ha dado en llamar dependencia funcional. El concepto de clave es t an importante, que da lugar a una serie de restricciones fundamentales sobre la base de datos. Son la regla de identificacin nica y la regla de integridad referencial. Regla de identificacin nica. Esta restriccin ya fue estudiada en el tema de los diagramas E-R. En esencia, los conceptos de clave de una entidad en el diagrama E-R, y de clave de una tabla coinciden plenamente. As pues, al igual que en aquel momento, podemos enunciar esta regla de la misma forma: En ninguna tupla de una tabla, ninguno de los atributos que formen parte de la clave primaria de una relacin podr tomar un valor nulo. El valor de la clave ser nico para cada tupla de la tabla. Esta regla nos dice que una vez escogida la clave primaria de una tabla, y dado que ninguno de los atributos que la componen es superfluo, no podemos dejar de lado el valor de ninguno de ellos para identificar unvocamente a una tupla. O sea, el que todos los atributos de la tabla sean necesarios est en contradiccin con que alguno de ellos pueda carecer de valor. Ningn atributo de la clave puede ser vaco porque en tal caso no sera una caracterstica identificativa propia del objeto a que pertenece. Regla de integridad referencial. Esta otra regla, aunque tambin tiene una relacin directa con el concepto de clave, est quizs ms vinculada a la forma en que un diagrama E-R se convierte en un esquema relacional,
El modelo relacional.

8 por lo que puede no ser bien comprendida en este punto. No obstante, por completitud se da aqu su enunciado, aunque su explicacin la dejaremos para ms adelante. Si una tupla de una tabla A posee atributos (a1..an) que hacen referencia a la clave primaria de otra tupla de una tabla B, dichos atributos poseen, o bien valores nulos, o bien valores (v1..vn) que se corresponden con la clave de una tupla concreta de B. Restricciones en la base de datos. Las restricciones que hemos visto hasta ahora, son restricciones de clave aplicables a todas las bases de datos que siguen el modelo relacional, con independencia de su rango de aplicacin o los datos que contengan. Restricciones de este tipo son tambin las que restringen los valores

que puede contener una tupla, la imposibilidad de repetir tuplas o incluso de establecer un orden entre las tuplas de una tabla. En este punto vamos a estudiar las reglas que el administrador impone a los datos que debe contener la base de datos. Son restricciones propias de la base de datos, y de la informacin que se pretende representar como por ejemplo que no haya pedidos que servir cuya fecha lmite sea ant erior a la fecha actual, que el total debido por un cliente no supere el riesgo mximo permitido, etc. Son restricciones que en general limitan la estructura de la informacin almacenada en la base de datos, suministrando por tanto informacin sobre las caractersticas que respetan los datos guardados. Este tipo de restricciones podemos dividirlas en tres grupos principales: Restricciones de atributo. Restricciones de tupla. Restricciones de tabla. Restricciones de base de datos. Restricciones por usuario. Antes de hablar de las res tricciones, es interesante echar un vistazo a conceptos importantes propios de la lgica matemtica, y su aplicacin a la informtica. Expresiones. Operadores relacionales. Predicados. Cuando hablamos de restricciones, tenemos en mente una serie normas o reglas que deben cumplir los datos, ya sea por s solos, o en relacin con los dems. El problema reside en como expresar esas normas de manera que el ordenador pueda comprenderlas. Para solucionar este problema, es necesario que bajemos un poco al nivel de la mquina, para convertir nuestras ideas en una secuencia de smbolos (sumas, restas, preguntas sobre si fulano es mayor que zutano, etc.) que dan lugar a una expresin final que slo puede tomar dos
El modelo relacional.

9 valores: o es verdad o es falso. Esta expresin final es lo que se llama predicado, que no tiene nada que ver con el anlisis sintctico de una frase en lingstica (sujeto, predicado, y esas cosas). El predicado ms simple que se puede formar es mediante la comparacin entre dos cosas. Podemos comparar nmeros para saber si son iguales, o uno es may or que ot ro, podemos comparar frases (slo desde el punto de vista lexicogrfico, ya que el ordenador no comprende el significado que nosotros le damos a dichas frases) para saber si contienen palabras repetidas, si una frase subsume a otra, o simplemente para saber si una precede a otra o no segn el orden alfabtico. De esta forma aparecen los operadores relacionales, que fundamentalmente son:

> Mayor que < Menor que = Igual que <= Menor o igual que () >= Mayor o igual que () <> Distinto a () Con estos operadores podemos preguntar si un nmero es mayor que otro o no, p.ej.: 6>8 a lo que el ordenador nos responder: NO, o lo que es lo mismo FALSO. En el ejemplo anterior hemos empleado tan slo cons t antes: el 6 y el 8 son valores constantes. La verdadera potencia de este tipo de consultas se produce en el momento en que intervienen tambin variables o, en nuestro caso, atributos. P.ej.: Descuento < 100 En este caso, el ordenador responder VERDADERO o FALSO segn el valor que en ese moment o represente el atributo Descuento. En este caso, el atributo Descuento almacena el porcentaje de descuento a aplicar sobre una factura que posee una determinada Base Imponible en pesetas. Si en una tupla, el atributo Descuento tiene el valor 80, el predicado anterior tendr como valor VERDADERO; pero si en otra tupla Descuento vale 120, el predicado valdr FALSO. As, a las constantes, y a las variables o atributos, las llamamos expresiones. An ms interesante es el hecho de poder emplear expresiones matemticas ms complejas, como por ejemplo, si queremos que el Descuento nunca sea mayor que la mitad del IVA aplicado, supuesto que ambos atributos almacenan un porcentaje, se empleara el siguiente predicado: Descuento < IVA / 2 Las expresiones empleados pueden llegar a ser muy complejas, pudiendo involucrar a varios atributos a la vez. Si por ejemplo tenemos adems del descuento normal, un atributo DPP (Descuento por Pronto Pago), que no almacena un porcentaje si no una cantidad en pesetas, si queremos que este descuento no supere nunca al Descuento normal a que hacemos referencia desde elprincipio, nos encontramos con el problema de que Descuento posee un porcentaje mientras que DPP posee una cantidad en p eset as: NO SON DIRECTAMENTE COMPARABLES. Para solucionar el problema, es necesario convertir alguno de los dos a la magnitud del
El modelo relacional.

10 otro: o convertimos Descuento a una cantidad en pesetas o pasamos DPP a un porcentaje. En cualquiera de los dos casos, intervendr el atributo Base Imponible imprescindible para esta conversin. Para convertir el Descuento en una cantidad concreta en pesetas, usaremos la expresin: (Descuento / 100) * Base Imponible, con lo que el predicado quedar:

DPP <= (Descuento / 100) * Base Imponible Por otro lado, para convertir el DPP en un porcentaje, emplearemos la expresin: (DPP / Base Imponible) * 100, con lo que el predicado quedar: (DPP / Base Imponible) * 100 <= Descuento Como vemos, estos predicados expresan reglas que pueden cumplirse o no en una determinada tupla de una tabla. Cuando exigimos que dicho predicado se cumpla siempre estamos hablando de una restriccin. Hay algunas situaciones en las que estos predicados s imples no son suficiente para expresar la restriccin que queremos imponer. P.ej., cmo expresar que el IVA slo puede tomar los valores 3, 7, 16 33? Con lo que hemos visto hasta ahora, podemos expresar por separado esta situacin: IVA = 3, IVA = 7, IVA = 16, e IVA = 33. El problema radica en cmo expresar que deben cumplirse varios predicados simples simultneamente. Otra situacin distinta aparece cuando, en lugar de exigir que se cumpla todo a la vez, queremos que se cumpla al menos una de ellas. P.ej. cmo expresar que uno de llos dos descuentos debe ser menor que el iva aplicado; por separado tenemos que DPP < IVA, Descuento < IVA. El problema radica en cmo expresar que debe cumplirse al menos un predicado simple. Para solucionar estos problemas se emplean las conectivas u operadores lgicos. Cuando queremos que un predicado P1 se cumpla a la vez que otro P2, se emplea la conectiva Y (en ingls AND), dando lugar a P1 AND P2. Esta conectiva es asociativa, por lo que siguiendo el ejemplo anterior quedara: IVA = 3 AND IVA = 7 AND IVA = 16 AND IVA = 33 Cuando queremos que se cumpla al menos uno de los predicados P1 o P2 se emplea la conectiva O (en ingls OR), dando lugar a P1 OR P2. Esta conectiva es asociativa, y siguiendo con el segundo ejemplo quedara: DPP < IVA OR Descuento < IVA Un tercer tipo de conect iva menos empleada es aquella que permite indicar que un p redicado NO debe cumplirse; es la conectiva NO (en ingls NOT), y se aplica a un slo predicado (al igual que un signo menos para indicar que un nmero es negativo). Por ejemplo, si queremos indicar que el Descuento nunca puede ser del 23% se hara algo as como: NOT (Descuento = 23) lo que puede conseguirse de forma similar mediante Descuento <> 23 Por ltimo, otra conectiva muy interesent a es la que obliga a que un predicado sea verdadero s iemp re y cuando se verifique otro previo. Es la conectiva IMPLICA (en ingls IMPLIES). P.ej., si no queremos aplicar descuentos superiores al 40% en facturas cuya base

El modelo relacional.

11 imponible sea menor de 1000 ptas. crearemos el siguiente predicado: Base Imponible < 1000 IMPLIES Descuento <= 40 lo que podemos leer como: Si la Base Imponible es menor de 1000 entonces el Descuento no puede ser mayor de 40. Si la Base Imponible fuese mayor de 1000, entonces da igual el valor del Descuento: el predicado tomar el valor VERDADERO. Este predicado slo se incumple (toma el valor de FALSO), cuando el primer predicado se cumple y el segundo no. Un predicado que emplea cualquiera de estas conectivas recibe el nombre de predicado complejo. Las conectivas anteriores pueden mezclarse entre s utilizando parntesis para dejar bien claro la forma en que los predicados simples deben agruparse entre s. De esta forma, de aqu en adelante, una restriccin es ni ms ni menos un predicado que debe tomar siempre el valor VERDADERO. NOTA: Ms adelante sera interesante hablar del concepto de funcin: Mes(), Hora(), etc. Restricciones de atributo. Hemos hablado del concepto de dominio, que se corresponde con los valores que puede tomar un atributo de una tabla. Normalmente, los dominios de que se dispone en cualquier S.G.B.D. son dominios muy generales, y que abarcan un conjunto de valores muy amplio que en la mayora de los casos puede satisfacer las necesidades del administrador. No obstante, hay situaciones en las que se desea restringir an ms el conjunto de estos valores. P.ej., si en una tabla de Albaranes deseamos guardar un atributo Descuento que contendr el porcentaje de dscuento a aplicar, est claro que Descuento no puede poseer un valor superior al 100%. Si el S.G.B.D. slo permite decir si un atributo posee un valor entero o dcimal, cmo indicar esta restriccin sobre el campo Descuento? La solucin viene dada a travs de las restricciones de atributo. Una restriccin de atributo es un predicado en el que slo pueden intervenir constantes y, por supuesto, dicho atributo. De esta forma, la restriccin del ejemplo anterior, quedara: Descuento < 100 Por supuesto, podemos emplear predicador ms comp lejos. Si tenemos una tabla de Clientes, y deseamos saber su sexo para poder mandarles cartas personalizadas, emplearemos un atributo Sexo cuyo tipo ser TTeexxttoo ddee 11 ccaarrcctteerr. Est claro que los nicos valores que vamos a permitir sern V (Varn) y M (Mujer). Esto puede conseguirse con el siguiente predicado: Sexo = "V" OR Sexo = "M" Hay algunos S.G.B.D. en los este tipo de restricciones puede indicarse de una forma ms

intuitiva. Dado que el nico atributo que puede intervenir es aqul al que se refiere la propia restriccin, podemos quitarlo de la expresin, dndolo por implcito: = "V" OR = "M"
El modelo relacional.

12
Alumno Fe cha Inic io Final Ana Bernal Gra cia Jua n Y ez Pi Jua n Y ez Pi Jua n Y ez Pi Jua n Y ez Pi Jua n Y ez Pi Jua n Y ez Pi Jua n Y ez Pi Ana Bernal Gra cia Ana Bernal Gra cia Ana Bernal Gra cia Ana Bernal Gra cia Ana Bernal Gra cia Jua n Y ez Pi Jua n Y ez Pi Ana Bernal Gra cia 12/2/98 13/2/98 14/2/98 19/2/98 14/2/98 26/2/98 22/2/98 3/3/98 10/3/98 10/3/98 15/3/98 22/3/98 23/3/98 30/3/98 7/4/98 7/4/98 12:00 8:00 17:00 18:00 12:00 12:00 12:00 12:00 12:00 17:00 17:00 17:00 17:00 18:00 18:00 18:00 18:00 18:00 18:00 18:00 18:00 18:00 17:00 8:00 8:00 8:00 8:00 8:00 8:00 8:00 8:00 8:00 Lugar Rte. Eurogallo H. Esturin Rte. La Pla ta H. Mlaga H. Mar Az ul H. Valhala

H. Estigia Rte . Odn Rte. Baco H. Esturin H. Mlaga H. Mlaga Rte. Eurogallo Rte. Eurogallo Rte. Eurogallo Rte . Odn

Restricciones de tupla. En el caso anterior, los valores que poda tomar un determinado atribut o, dependen exclusivamente de su propia condicin, o sea, con independencia del resto de los atributos de la tupla a que pertenece. No siempre ocurre as, sino que a veces, los valores de ciertos atributos de una tupla deben poseer valores consistentes entre s, y no de forma independiente. P.ej., si tenemos una tabla de Clientes y queremos almacenar datos de cada uno de ellos para hacerles la nmina, podemos incluir entre otros, los atributos de Nmero de Hijos y de Retencin IRPF. Est claro que existe una relacin entre ambos valores, de manera que si alguien no tiene hijos, su retencin de IRPF no puede ser menor que un porcentaje mnimo establecido por ley, pongamos el 10%. No podemos considerar esta restriccin como una restriccin de atributo, ya que existe una dualidad a la hora de considerar a qu atributo pertenece la restriccin. Podemos verlo como una restriccin de Retencin IRPF que no puede ser menor de 10 si Nmero de hijos es igual a 0. Pero, por qu no verlo como una restriccin de Nmero de Hijos? Nmero de Hijos no puede ser 0 si Retencin IRPF es menor de 10. Esta dualidad, producida por una restriccin mutua entre dos o ms atributos de una misma tupla es lo que da lugar a una restriccin de tupla. El predicado que soluciona este problema sera: Nmero de hijos = 0 IMPLIES Retencin IRPF > 10 Restricciones de tabla. En otras situaciones, no es el valor de un atributo el que depende de los de los dems de la tupla a que pertenece, sino que es la tabla en s la que depe preservar unas propiedades globales para que la informacin que posee sea consistente. Por ejemplo, supongamos que estamos gestionando las prct icas que los alumnos de Hostelera deben realizar en distintos hoteles y rstaurantes de la costa. Estas prcticas vienen determinadas mediante una serie de turnos que cada alumno tiene asignado en distintas empresas. Para conseguir una enseanza de calidad deseamos que cada alumno efecte prcticas por al menos 50 horas , y por supuesto, no debe darse la circunstancia de

que ningn alumno tenga turnos coincidentes, esto es, en lo que coincidan fecha y hora de la prctica en distintos lugares. La figura siguiente representa una
El modelo relacional.

13
Nombre Destino Comienzo Duracin Plazas Alpinismo Aventura Disney Zares Katmand Nairobi Paris Mosc 23/7/98 15/4/98 10/9/98 7/8/98 25 12 5 7 3 5 15 11 Paquetes

situacin que no queremos que ocurra. En esta tabla hemos representado tan slo los datos referentes a dos de nuestros alumnos. Uno de ellos, Juan Yez Pi tiene asignadas 86 horas de prcticas, mientras que Ana Bernal Gracia tan slo tiene 44 horas asignadas, incumpliendo la restriccin que queremos imponer. Pero an hay ms, las tupla marcadas con una flecha entran en contradiccin, pues nos indican que de 12:00 a 18:00 Juan Yez Pi debe realizar prcticas en dos sitios distintos: el restaurante La Plata, y el restaurante Baco, lo cual es igualmente inadmisible. Con objeto de evitar este tipo de situaciones, aparecen las restricciones de tabla. Una restriccin de tabla es un predicado que engloba todas o parte de las tuplas de una misma tabla. su valor de VERDAD o FALSEDAD no puede ser encontrado si no es con el examen de dichas tuplas. La forma de expresar este tipo de restricciones implica la utilizacin de expresiones y consultas que, por ahora, quedan fuera de nuestra visin. Baste decir que ser necesario utilizar toda una batera de mtodos de consulta que veremos ms adelante en el apartado de SQL. Restricciones de base de datos. Las restricciones de base de datos son a las restricciones de tablas, lo que las de tupla son a las de atributo. Si en una restriccin de

atributo slo poda intervenir un atributo, y en las de tupla podan intervenir varios (siempre de la misma tupla), las rest ricciones de base de datos son iguales que las de tabla con la salvedad de que pueden intervenir ms de una tabla (de la misma base de datos, evidentemente). Supongamos p.ej. que trabajamos en una agencia de viajes en la que ofertamos paquetes de viajes; de cada paquete de viajes el nmero de plazas es limitado. As, podemos almacenar informacin de los paquetes disponibles en una tabla como la de la figura. A medida que vamos vendiendo los paquetes, iremos guardando en otra tabla el cliente que ha comprado el paquete, y el nombre del paquete comprado. De manera que tras algn tiempo, podemos tener la siguiente tabla de ventas. A poco que observemos esta tabla, vemos que hemos vendido cuatro paquetes de Alpinismo, cuando el nmero de plazas disponibles es tan slo de tres. Estamos infringiendo una restriccin de la base de
El modelo relacional.

14 datos, y lo que es ms, para darnos cuenta de ello hemos tenido que inspeccionar los datos de ms de una tabla. Para poder detectar automticamente a travs del S.G.B.D. este tipo de situaciones hemos de indicar una restriccin de base de datos. Al igual que ocurra en el caso anterior, el predicado correspondiente a esta restriccin es complejo de especificar, y su estudio est supeditado al conocimiento de SQL, que veremos ms adelante. Restricciones de usuario. Es t as restricciones son muy diferentes a las anteriores, y suelen estar referidas a la insercin de datos pr parte de un usuario concreto. Como veremos ms adelante, cuando se crea una gran base de datos, su manejo y gestin no suele realizarlo una sola persona, sino que sobre ella trabajan muchas personas a la vez, cada una de las cuales suele efectuar unas operaciones concretas: el recepcionista suele dar entrada a los clientes (check in), les hace la factura cuando se marchan (check out), etc., mientras que el contable se centra exclusivamente en los asientos contables y no necesita saber nada de los clientes. De esta forma, podemos hacer incluso que el S.G.B.D. sepa QUIN est manejando la

base de datos en cada momento, mediante un sistema en el que antes de acceder a la base de datos, el S.G.B.D. solicita una identificacin al usuario. En funcin del perfil que tenga asignado cada usuario (privilegios), podemos hacer que los datos que introduzca en la base de datos estn restringidos en todos los sentidos. Por ejemplo, podemos permitir que cualquier persona haga un apunte en la factura de un cliente de un hotel. Sin embargo, si este apunte supera las 100000 ptas., slo puede hacerse con el consentimiento de algn usuario especial como pueda ser p.ej. el gerente. De esta forma, el valor de un apunte en una factura est condicionado a quien es el usuario que inserta dicho apunte. Este tipo de reglas suele ser muy complejo de manejar a travs del S.G.B.D., y suelen sustituirse mediante los llamados permisos de usuario.

Conversin de diagramas E-R a esquemas relacionales.

En el tema 2 estudiamos un modelo conceptual de datos que nos permita describir la informacin que se desea almacenar en una base de datos cualquiera: el modelo EntidadRelacin. La ventaja de este modelo es que es independiente del modelo lgico sobre el que se vaya a implantar finalmente dicha base de datos. Por otro lado, cuando dicho modelo lgico es el modelo relacional, resulta bastante sencillo pasar del diagrama E-R al esquema relacional mediante unas cuantas reglas sencillas y fciles de aplicar. Antes de comenzar es necesario resaltar las diferencias existentes entre estos dos modelos.
El modelo relacional.

15
Nombre Apellidos Direccin NIF Telfonos Sexo Riesgo Riesgo acumulado

Clientes
Nombre Apellidos Direccin NIF Nmero de Telfono Sexo Riesgo Riesgo acumulado Telfonos 1..1 Cont acto 0..n Clientes

De una parte, el modelo E-R trabaja a nivel conceptual, estableciendo cules son las entidades fuertes y dbiles que intervienen en nuestra base de datos, y las relaciones existentes entre ellas; sin embargo, no hace referencia alguna a la forma en que estos objetos se almacenan en ninguna

base de datos, entre otras cosas por se trata slo de un modelo conceptual. Por contra, el modelo relacional lo que trata es de representar la informacin en la forma en que se va a almacenar en la memoria del ordenador (o al menos en la forma en que el usuario la ve). Para ello se vale casi nicamente del concepto de tabla. Por tanto, lo que se pretende con este apartado es pasar de describir conceptualmente el mundo mediante entidades y relaciones, a describirlo lgicamente mediante tablas. Utilizacin de atributos atmicos. El modelo relacional impone una condicin sobre las caractersticas que debe poseer cada columna de una tabla relacional. De hecho, el lector habr notado que todas las columnas poseen datos simples, tambin llamados atmicos, de manera que cada uno de ellos representa una informacin unitaria y que no puede descomponerse en bloques de informacin ms pequeos, (al menos desde el punto de vista del S.G.B.D.). Por otro lado, el modelo E-R no impone esta restriccin, sino que no dice nada sobre las caractersticas de los atributos, de manera que estos pueden contener informacin compuesta, o mltiple. En el ejemplo adjunto, podemos observar una entidad Clientes que posee varios atributos, entre ellos Telfonos; nada impide en el modelo E-R que Telfonos almacene un solo nmero de telfono, sino que podra almacenar varios segn las necesidades con que se haya concebido la entidad. Sin embargo, este atributo (llamado atributo mltiple, pues consiste en un mismo atributo atmico Telfono, duplicado un nmero indeterminado de veces), no tiene repres ent acin correspondiente en el modelo relacional, por lo que es necesario algn tipo de transformacin que convierta atributos mltiples en atributos atmicos. Esta transformacin es muy sencilla, y consiste nicamente en crear una entidad dbil llamada Telfonos, y relacionarla con Clientes a travs de una relacin dbil. Esta nueva entidad poseer un nico atributo atmico Nmero de Telfono. As, el atributo mltiple se convierte en una entidad, ahora ya con atributos atmicos, de manera que cada Cliente se relacionar con
El modelo relacional.

16
Nombre Apellidos Dire cc in NIF Se xo Rie sgo Riesgo a cumula do

Clientes

0, 1 muchas instancias de esta nueva entidad, con lo que el resultado es el mismo, con la salvedad de que en este nuevo diagrama slo intervienen atributos atmicos.

Si el atributo mltiple pertenece a una relacin, la solucin es la misma, excepto por el hecho de que no es necesario crear una nueva relacin, sino que la que posea el atributo mltiple nos sirve adems para conectar con la nueva entidad dbil creada. Algo parecido ocurre con los llamados atributos compuestos. Un atributo compuesto es aqul que puede dividirse en bloques de informacin ms pequeos, pero a diferencia de los mltiples, estos bloques pequeos no son homogneos, sino diferentes entre s. El caso ms comn es el del atributos Domicilio de algunas entidades. Normalmente en el Domicilio de un Cliente o de un Proveedor, no es necesario distinguir entre calle, nmero, portal, planta, etc. Si en nuestro diseo deseamos distinguir efectivamente entre todos esos componentes del Domicilio entonces la nica solucin es crear atributos atmicos para cada uno de ellos. Esta situacin suele presentarse en raras ocasiones, y normalmente el diseo suele hacerse directamente en base a los atributos atmicos que pretenden distinguirse. Conversin de entidades y relaciones a tablas. Una vez preparados los atributos de las entidades y relaciones, la conversin del diagrama E-R al modelo relacional pasa por dos etapas: una en la que se convierten las entidades, y otra en la que se convierten las relaciones. No obstante, las tablas que se van obteniendo no adoptan su forma definitva hasta que se ha acabado el proceso. Conversin de entidades a tablas. Una entidad A con atributos a1..an se convierte en una tabla de nombre A, y nombres de columna o atributos a1..an. Si la clave de la entidad A est formada por los atributos ai..ai+k, la clave de la tabla correspondiente estar formada por dichos atributos. En definitiva, podemos decir que existe una correspondencia directa entre el concepto de entidad del diagrama E-R (una vez eliminados los atributos mltiples y los comp uestos), y el concepto de tabla relacional. P.ej., siguiendo con el caso anterior, la entidad Clientes se convertira en la tabla adjunta, en la que no hay ningn dato insertado. Si la entidad es dbil, ser necesario incluir tambin los atributos correspondientes a su entidad fuerte, indispensables para poder establecer una clave identificativa en la tabla as
El modelo relacional.

17
Facturas Lneas de Detalle detalle
Nmero Fecha Cliente Base Imponible Descuento IVA Nmero de lnea Cdigo Artculo

Cantidad Importe 1 ..n 1 ..1

Nmero de Lne a Cdigo Art culo Cantidad Importe

Lneas de Detalle
Nme ro Fe cha Cliente Ba se Imponible Descuento

Facturas
IVA Nmero de Fac tura

formada. Conversin de relaciones binarias a tablas. Conversin de relaciones es-un y relaciones dbiles. La conversin de relaciones es-un y relaciones binarias dbiles en general, no conlleva realmente la aplicacin de ninguna regla, ya que la propia conversin de la entidad dbil en tabla convierte automtica e implcitamente la relacin dbil tambin. Supongamos por ejemplo el diagrama que nospermite representar las facturas propias de cualquier negocio. Dado que el nmero de lneas de detalle de una factura es indeterminado, es necesario crear una relacin dbil que relacione cada factura con los detalles que en ella se facturan, tal y como se ve en el diagrama adjunto. Cuando convertimos las entidades Facturas y Lneas de Detalle en sus tablas correspondientes, obtenemos las de la figura, en la que se observa quela tabla de Lneas de Detalle hereda los atributos que forman la clave de Facturas. Con este mtodo est claro cuales son las instancias de Lneas de Detalle que se relacionan con cada Factura concreta, ya que partiendo del Nmero de la Factura buscamos todas las tuplas de Lneas de Detalle en las que coincida su atributo Nmero de Factura. Por otro lado, averiguar a qu Factura pertenece una Lnea de Detalle es trivial, todo caso que se conoce la clave de dicha Factura a travs de Nmero de Factura. De esta forma, la relacin dbil Detalle queda representada en el modelo relacional por la inclusin de la clave de la relacin fuerte en la tabla de la dbil. Una relacin es-un se trata de la misma forma que cualquier ot ra relacin binaria de debilidad. Conversin de relaciones uno a uno. La conversin de una relacin uno a uno, no da lugar a una tabla nueva, sino que modifica una de las dos tablas correspondientes a las entidades que relaciona. Una relacin R del tipo uno a uno con atributos r1..rn que relaciona entidades A y B de claves ai..ai+k y bj..bj+m, modifica la tabla de la entidad A, aadindole como atributos los de la clave de B, y los suyos propios, esto es bj..bj+m y r1..rn.
El modelo relacional.

18
Nombre Ape llidos NIF Direcc in Nmero Situac in Fec ha alquiler Duracin

Clientes Alquila Taquillas 1..1 0..1 Nombre Apellidos NIF Direccin Nmero Situacin

Clientes Taquillas
Nombre Apellidos NIF Direccin Nmero

Clientes
Fecha alquile r Dura cin

Por ejemplo, supongamos el diagrama E-R de la figura que representa a una entidad Clientes y a una entidad Taquillas, en un sistema en el que queremos representar parte de un gimnasio, de manera que un cliente alquila una taquilla, y una taquilla slo puede pertenecer como mucho a un cliente. Esta situacin se representa mediante la relacin Alquila, que en tal caso es del tipo uno a uno. Tras convertir las entidades Clientes y Taquillas en tablas, se obtienen las de la figura adjunta. Si ahora ap licamos la regla dada anteriormente, nos damos cuenta de su ambigedad, en el sentido de que hace referencia a una entidad A y otra B. En nuestro caso, da lo mismo cual consideremos como entidad A (si a Clientes o a Taquillas), ya que el proceso a seguir es idntico escojamos la que escojamos. Supongamos que la entidad A es Clientes. en tal caso para convertir la relacin Alquila con at ribut os Fecha alquiler y Duracin, ampliaremos la tabla de Clientes con la clave de Taquillas, o sea Nmero, y los atributos de la relacin, dando lugar a la figura siguiente. Como resultado de esta conversin, hemos transformado una tabla aadindole atributos que permiten seguir la relacin existente entre un Cliente y una Taquilla. Podemos saber directamente qu Taquilla tiene asignada un Cliente sin ms que consultar su clave, en este caso el atributo Nmero, que, por el hecho de ser clave, identifica de forma nica una tupla en la tabla de Taquillas. Asimismo, acompaamos la adicin de esta clave con la adicin de los atributos

propios de la relacin, con lo que podemos saber qu Taquilla ha alquilado cada Cliente, en qu Fecha alquiler y por cunta Duracin. Por otro lado, para saber a partir de un Nmero de Taquilla, qu Cliente la ha alquilado, basta con insp eccionar todas las tuplas de Clientes en busca de uno cuyo atributo Nmero coincida con el que estamos buscando. Por tanto, lo que en el diagrama E-R no era ms que un dibujo que relacionaba instancias de una entidad, lo hemos convertido en tablas y atributos insertados en ellas que nos permiten seguir el hilo de las instancias relacionadas. Esta operacin, en la que la clave de una tabla emigra a otra, da lugar a lo que se llama clave fornea, que no es ms que el conjunto de atributos que conforman la clave migrada.
El modelo relacional.

19
Compaas Vuelos
Fe cha sa lida Luga r sa lida Destino Duracin Desc riptor Nombre Domicilio social Naciona lidad

Realizar
1..n 1..1

Nombre Domicilio social Nacionalidad DescriptorFecha salida

Compaas Vuelos
Lugar salida Duracin Destino
Nombre Domicilio social Nacionalidad DescriptorFecha salida

Compaas Vuelos
Lugar salida Duracin Destino Nombre

Conversin de relaciones uno a muchos. Cuando la relacin que se desea convertir es del tipo uno a muchos, la solucin es muy parecida a la del punto anterior, y consiste en migrar una de las claves a la tabla correspondiente a la otra entidad. Una relacin R del tipo uno a muchos con atributos r1..rn que relaciona entidades A y B de claves ai..ai+k y bj..bj+m de manera que una instancia de A se puede relacionar con muchas de B, modifica la tabla de la entidad B, aadindole como atributos los de la clave de A, y los suyos propios, esto es ai..ai+k y r1..rn. Tpico ejemplo de esta situacin es el diagrama E-R que representa la relacin entre una lista de vuelos comerciales y las compaas areas que los realizan. Esto puede verse en la figura adjunta.

Tras haber convertido las entidades en tablas se obtienen las de la figura siguiente. En esta situacin, para convertir la relacin Realizar al modelo relacional, observamos que una Compaa se relaciona con muchos Vuelos, por lo que siguiendo la regla anterior, Compaa hace las veces de entidad A, y Vuelos hace las veces de entidad B. Por tanto, para convertir la relacin, basta con incluir la clave de Compaas en la tabla de Vuelos, dando lugar al siguiente esquema. En este caso, la relacin Realizar carece de atributos propios por lo que no se aaden ms atributos a la tabla de Vuelos. En este punto es int eresante hacer not ar que en el diagrama E-R existe la posibilidad de tener entidades distintas con atributos distintos pero con el mismo nombre; p.ej., puede ser comn tener la entidad Clientes con un at ribut o NIF, y a la vez tener la entidad Empleados con un atributo tambin llamdo NIF. Esto es posible porque cuando se hace referencia a NIF, es necesario tambin indicar la entidad a que nos referimos: Clientes o Empleados. Sin embargo, en el momento de efectuar la conversin del diagrama a las tablas relacionales, vemos que en ciertas situaciones es necesario migrar las claves de unas entidades a otras, lo cual puede dar conflictos de nombres. Por ejemplo, qu ocurrira si el atributo que forma la clave (destinado a guardar el cdigo del vuelo: IB-713, AV-098, etc.), en lugar de llamarse Descriptor se llamase Nombre? Est claro que cuando se migrase la clave de la Compaa a la tabla de Vuelos habra un problema, pues tendramos dos atributos con el mismo nombre.
El modelo relacional.

20
Nombre de Compaa Domicilio social Na cionalidad DescriptorFecha salida

Compaas Vuelos
Lugar salida Duracin Destino Nombre

Pues bien, tanto si se produce esa situacin como si no, cuando se migra la clave de una tabla a otra, nada nos impide renombrar los atributos en su nueva ubicacin. Por ejemplo, en el caso anterior, la tabla Vuelos podra haber quedado como se ve en la figura: el at ributo Nombre ha pasado a llamarse Nombre de

Compaa. Lo que s est claro, en cualquier caso, es que el atributo Nombre de Compaa sigue siendo clave fornea, aunque tenga distinto nombre. Conversin de relaciones muchos a muchos. Este es el caso ms general de conversin de relaciones, pudiendo incluso aplicarse en las relaciones uno a uno y uno a muchos. El nico motivo por el que no se da esta regla como nica regla general es la eficiencia, ya que como veremos implica la creacin de tablas nuevas y la duplicacin de informacin en gran cantidad. De hecho, tambin las reglas anteriores pueden ser refinadas con objeto de conseguir tablas ms compactas y menos redundantes, pero a costa de enrarecer la comprensin de las mismas, razn por la que no las inclumos aqu. Una relacin R del tipo muchos a muchos con atributos r1..rn que relaciona entidades A y B de claves ai..ai+k y bj..bj+m respectivamente, se convierte en una tabla llamada R y compuesta por los atributos de las claves de A y B, as como por los atributos propios de la relacin R, esto es ai..ai+k, bj..bj+m, y r1..rn. Los atributos ai..ai+k, bj..bj+m forman la clave de la nueva tabla. En los casos anteriores hemos visto como para convertir una relacin uno a muchos (entre A y B) ampliamos una de las tablas correspondientes a una de las entidades que intervienen: la de B. Esto se puede hacer as porque cada instancia de B slo puede relacionarse con una instancia de A, lo que en el esquema relacional puede plasmarse con la insercin de una sola clave fornea entre los atributos de la tabla asociada a B. Esta decisin no es simtrica, como ocurre en las relaciones uno a uno, o sea, no podemos ampliar la tabla de A con la clave fornea de B, ya que una instancia de A se puede relacionar con muchas de B, y necesitaramos un nmero indeterminado de claves forneas en A, lo cual no es lcito en el modelo relacional. En el caso de las relaciones muchos a muchos ocurre lo mismo, pero esta vez respecto a las dos entidades A y B. No podemos ampliar ninguna de las tablas asociadas porque necesitaramos un nmero indeterminado de claves forneas. Por tanto, la solucin pasa por crear una nueva tabla con el nico objetivo de contener los pares de instancias que se relacionan; evidentemente, en lugar de repetir toda la informacin de cada instancia, se almacena tan slo la informacin identificativa: la clave.
El modelo relacional.

21
Nombre Apellidos NIF Ao Nacimiento Cdigo Nombre Veces Matriculado

Convocatorias Agotadas

Alumnos Matrculas Asignaturas

1..n 0..n
Veces Mat riculado NIF Ao Nac imiento Cdigo de Asignatura

Alumnos Matrculas
Convoca toria s A gotadas Nombre Apellidos Cdigo

Asignaturas
Nombre NIF del Alumno

Para ilustrar esto, supongamos que queremos representar la informacin relativa a los alumnos de una Facultad y las asignaturas en que se halan matriculados. El diagrama E-R que rep resenta esto puede verse en la figura. Dado que la relacin Matrculas es muchos a muchos, segn la regla anterior, la conversin implica crear una nueva tabla con el mismo nombre, o sea Matrculas, y con los atributos Veces Matriculado y Convocatorias Agotadas, as como las claves de Alumnos y Asignaturas, o sea, NIF y Cdigo, que podemos renombrar como NIF del Alumno y Cdigo de Asignatura, quedando las tablas de la figura siguiente. Con este esquema de tablas, para saber en qu asignaturas se ha matriculado un alumno concreto, basta con buscar todas las veces que aparezca su NIF en la tabla Matrculas; cada tupla en la que aparezca contendr adems la clave de una de las asignaturas en la que est matriculado. Para saber el nombre de cada asigntura utilizaremos el Cdigo de Asignatura como clave para buscar el nombre en la tabla Asignaturas. Es interesante hacer notar la necesidad de los atributos asociados a la relacin, tal y como explicbamos en el captulo de diagramas E-R. Conversin de relaciones no binarias a tablas. Hasta ahora hemos visto la forma de proceder para convertir slo relaciones binarias. Muchos autores se quedan slo aqu, ya que es posible convertir cualquier relacin no binaria en varias binarias. No obstante, el mtodo ms general es permitir la existencia de relaciones que aglutinen a ms de dos entidades, por lo que veremos aqu el mtodo para convertirlas en tablas. Una relacin R no binaria con atributos que relaciona entidades E1, E2..En r de claves 1..r n e , , .. respectivamente, se convierte en una tabla llamada R y i1 ..ei1

 k1

ei2 ..ei2
k2

ein ..ein
kn

compuesta por los atributos de las claves de E1, E2..En, as como por los atributos propios de la relacin R, esto es e , , .. y . Los atributos , , i1 ..ei1
k1

ei2 ..ei2
k2

ein ..ein
kn

r1..r n ei1 ..ei1

k1

ei2 ..ei2
k2

..e forman la clave de la nueva tabla. in ..ein

kn

El modelo relacional.

22
Nombre Apel lidos NIF Experiencia Ao Nacimiento Nombre Provincia Cdigo Postal Ao Compra Matrc ula ltima Rev isin Telev isin Estreo Seguridad Fe cha Sal ida Durac in Garaje

Conductores Autobuses Paradas Trayectos 1..n

1..n 1..n 1..n Fecha Sal ida NIF Ao Nacimie nto Matrc ula

Cond uctores Trayectos

Durac in Nombre Ape llidos Matrc ula

Autobuses
Ao Compra

CP O ri gen Ex periencia

Paradas
ltim a Re visin Nombre Cdigo Postal Estreo Se guridad Provincia Garaje Tele visin CP Destino NIF Conduc tor Nombre Apel lidos NIF Direcc in Fec ha inicio Durac in Nombre Cdigo Categora Direcc in N Habitaci ones Desc ri pc in Desc ri pc in

Clientes Hoteles Reservas Reservar 1..n

0..n 0..n

Esta regla es igual que la de conversin de relaciones binarias muchos a muchos, slo que extendida a relaciones no binarias. Supongamos una Agencia de Transporte de Pasajeros por Carretera en la que tenemos varias delegaciones repartidas por todo el territorio nacional, y deseamos llevar un registro de cada viaje efectuado: Origen, Destino, Conductor y Autobs. Para ello, disponemos de las entidades Conductores, Autobuses, y Paradas. El registro que queremos viene dado por la relacin Trayectos, tal y como vemos en la figura. En este diagrama vemos que la entidad Paradas interviene dos veces en Trayectos, una como origen, y otra como dest ino. Asimismo vemos que la multiplicidad de todas las entidades en Trayectos es a muchos, aunque este hecho es indiferente a la hora de proceder a convertir Trayectos en una tabla relacional. Despus de aplicar las reglas de conversin de entidades, y la regla que nos ocupa en este punto, obtenemos las tablas de la figura. Ntese que cuando una entidad interviene ms de una vez en una relacin que se convierte en tabla, es obligat oriamente necesario renombrar su clave fornea, ya que de otra forma tendramos atributos con nombres duplicados. Es lo que ocurre con la entidad Paradas, cuya clave pasa a llamarse CP Origen o CP Destino segn como participe en el Trayecto.

Conversin de relaciones dbiles. Como hemos visto, hay situaciones en las que una entidad dbil no slo depende de una fuerte, sino que puede depender de dos o ms. Supongamos por ejemplo que manejamos una cadena de hoteles, y que deseamos tener registradas las reservas efectuadas por los clientes. Esta necesidad queda solucionada por el diagrama E-R de la figura. Puede observarse como la entidad Reservas no puede sustituirse por la inclusin en Reservar de todos sus
El modelo relacional.

23
De scripc in NIF Direcc in NIF de Cliente

Clientes Reserva s
Durac in Nombre Apel lidos Cdigo

Hoteles
Categora Cdi go de Hotel Nombre Direcc in N Habi taci ones De scripc in Fec ha Inicio

atributos, ya que en tal caso un Cliente no podra efectuar dos reservas en el mismo Hotel en fechas distintas. Estando as las cosas, las tablas correspondientes a las entidades Clientes, Hoteles y Reservas, seran como las de la figura siguiente, en la que podemosver como Reservas ha heredado los atributos de las claves de Clientes y Hoteles. De esta forma, estamos representando implcitamente la relacin Reservar, ya que las claves heredadas por Reservas nos permiten seguir el hilo hasta las instancias de Clientes y de hoteles a que pertenecen. Igualmente podemos emplear estas claves forneas para saber las reservadas efectuadas en un Hotel determinado o por un Cliente concreto. Normalizacin de esquemas relacionales. Como se ha podido comprobar a lo largo de este estudio sobre los diagramas E-R y sobre el modelo relacional, la creacin de un conjunto de tablas a partir de unas necesidades dadas no es ni mucho menos una labor algortmica en la que slo existe una solucin posible. De hecho,

distintos administradores expertos pueden proponer distintos conjuntos de tablas como solucin almismo problema, sin que ninguna de ellas tenga que primar sobre las dems como mejor aproximacin. Simplemente cada esquema propuesto se centrar en mejorar el comportamiento respecto a determinadas caractersticas del problema, solucionando el resto con una eficiencia aceptable aunque, aquizs, no ptima en todos los casos. En cualquier caso, y a pesar de que el proceso no es ni m ucho menos automtico, existen una serie de reglas generales, que aplicadas a cualquier esquema relacional, sea cual sea el problema que intente solucionar, aumentan la legibilidad y la potencia de las tablas, a la vez que disminuyen la redundancia, y los posibles problemas de concordancia entre los datos, incrementando tambin la utilidad de la base de dat os , y la confianza que podemos depositar en la informacin representada. La aplicacin de estas reglas a las tablas relacionales, y su transformacin en un nuevo conjunto de tablas que, aunque representan lo mismo, posee propiedades de mayor calidad, es lo que se ha dado en llamar Normalizacin. La normalizacin se fundamenta en dos conceptos principales: las dependencias funcionales (en todas sus variedades), y los determinantes. En cualquier texto que trate sobre el tema, podemos encontrar fundamentalmente seis reglas a aplicar sobre las tablas, de forma que la aplicacin de cada una de ellas hace que el esquema pase a estar en una forma normal concreta. As, la aplicacin de la 1 reglas hara que las tablas se hallen en 1 forma normal; la aplicacin de las reglas 1 y 2, pasan a 2 forma normal, y as sucesivamente. Por tanto, cada forma normal asegura una caractersticas de mayor calidad en las tablas obtenidas.
El modelo relacional.

24 Sin embargo, nosotros slo trabajaremos con dos de estas reglas: la que da lugar a la 1 forma normal, y la llamada forma normal de Boyce-Codd. a partir de aqu podemos aplicar todava la 4 y 5 formas normales, pero ello est fuera de nuestros objetivos, ya que implica conceptos de mayor nivel innecesarios para nuestros propsitos. Comenzaremos, por tanto con los conceptos de dependencias funcionales y de determinantes.

Dependencias funcionales.
Las dependencias funcionales son de primordial importancia a la hora de encontrar y eliminar la redundancia de los datos almacenados en las tablas de una base de datos relacional.

aunque existen varios tipos de dd. ff., nosotros slo vamos a trabajar con el tipo bsico, que es el que nos permitir llegar hasta la forma normal de Boyce-Codd. Podemos definir una dependencia funcional de la siguiente manera: Determinantes. 1 Forma Normal. Forma Normal de Boyce-Codd.

Sistemas de Informacin II

Tema 5. El modelo relacional

Carlos Castillo UPF 2008 Bibliografa: Elmasri y Navathe: Fundamentos de Sistemas de Bases de Datos 3 edicin, 2002 (Captulo 7). Garcia-Molina, Ullman y Widom: Database systems: the complete book. Prentice-Hall (Captulo 3).

UNIDAD 3

NORMALIZACION, USO DE HERRAMIENTAS CASE Y MODELO FISICO

INTRODUCCIN
a) Presentacin y contextualizacin
En esta unidad aprender los conceptos principales sobre la normalizacin de base de datos, la primera forma normal, la segunda forma normal y la tercera forma normal. Para poder entender y aplicar los conceptos de la normalizacin, se desarrolla un caso prctico, Alquiler de video, caso utilizado en la primera unidad, se aplicar toda la teora de normalizacin, tabla por tabla, hasta concluir con el modelo de base de datos. Para disear bases de datos ms giles, se necesita software que ayude a disearlas de una manera rpida pero eficaz, en nuestro caso se utiliza la herramientas case Erwin, herramienta que permite modelar bases de datos lgicas y fsicas. Para terminar el modelamiento de datos, se necesita volcar todo el diseo de la base de datos a un modelo fsico, escoger un gestor de base de datos relacional para nuestro caso Mysql. Aprender a manejar mysql, a crear bases de datos y relacionarlas, as como a gestionar datos de una realidad empresarial. Le invito a tomar los valiosos conocimientos que contiene esta unidad, siguiendo detalladamente la metodologa planteada.

b)Competencia
Disea bases de datos efectivas y eficaces aplicando la normalizacin y utilizando el mnimo de tiempo para su construccin y seleccionando las herramientas necesarias.

c) Capacidades
1. Comprende y aplica los conceptos fundamentales de normalizacin 2. Aplica la normalizacin en diferentes tipos de casos 3. Disea bases de datos utilizando herramientas CASE 4. Comprende la importancia de los gestores de bases de datos relacional

d)Actitudes
Comparte sus conocimientos de normalizacin con sus compaeros de clase Se esfuerza por comprender la importancia de las herramientas CASE Es puntual en el desarrollo de casos prcticos donde debe aplicar la normalizacin Estudia a conciencia los elementos de instalacin del mysql

e) Ideas bsicas y contenido esenciales de la Unidad:

La Unidad de Aprendizaje 03: Normalizacin, uso de herramientas CASE y modelo fsico comprende el desarrollo de los siguientes temas: TEMA 01: NORMALIZACIN TEMA 02: NORMALIZACIN APLICACIONES TEMA 03: USO DE HERRAMIENTAS CASE

TEMA 04: MODELO FSICO.

Tema 01: Normalizacin

Es el proceso mediante el cual se aplican una serie de reglas a las tablas del modelo relacional, para evitar que exista redundancia de datos y proteger la integridad de los mismos. Se definen principalmente 3 formas normales, para las tablas del modelo relacional, las que se analizan a continuacin.

PRIMERA FORMA NORMAL (1FN)

Tiene una clave primaria

Todas las tablas del modelo tienen que tener una clave principal, sino fuera el caso se le agrega una. No existen campos duplicados

No debe haber campos con el mismo Nombre como por ejemplo direccion1 direccion2, si fuera el caso ese
campo Forma su propia tabla.

Crea una tabla separada por cada campo Duplicado Por ejemplo la tabla ACTOR se encuentra en forma normal 0, es decir sin normalizacin.

ACTOR
Nombrecadena(60) no nulo Nacionalidadcadena(50)no nulo Sexocadena(1)no nulo Direccin1cadena(60) no nulo Direccin2cadena(60) no nulo

Primero revisamos si tiene clave primaria, como no tiene se la proporcionamos, entonces la tabla queda as.

ACTOR
Nombrecadena(60)no nulo Nacionalidadcadena(50)no nulo Sexocadena(1)no nulo Direccin1cadena(60)no nulo Direccin2cadena(60)no nulo Idactor(PK) cadena(6)no nulo La segunda regla es que no tienen que existir campos duplicados, como los

campos direccion1 y direccin 2, se forma por lo tanto otra tabla con esos campos, y quedara as.

ACTOR
Nombrecadena(60)no nulo Nacionalidadcadena(50)no nulo Sexocadena(1)no nulo Idactor(PK) cadena(6)no nulo

DIRECCION
Direccincadena(50)no nulo Idactor(FK)cadena(6) nonulo Iddireccion(PK)cadena(60)no nulo

SEGUNDA FORMA NORMAL (2FN)

oNo existen datos duplicados en las filas de los campos de la tabla, si

ese fuera el caso, crear una tabla separada.

oRelacionar estas nuevas tablas mediante una clave fornea y agregarle su

propia clave primaria

La tabla ACTOR ya se encuentra en primera forma normal, pero no en segunda forma normal, analicemos.

DIRECCION
Nombrecadena(60)no nulo Nacionalidadcadena(50)no nulo Sexocadena(1)no nulo Idactor(PK) cadena(6)no nulo Para analizar mejor la segunda forma normal, es preciso agregarle datos a la tabla ACTOR.

ACTOR

IDACTOR
A00001 A00002 A00003

NOMBRE
Cornelio Arenas Manuel Armas Mara Valenzuela

NACIONALIDAD
Per Per Ecuador M M F

SEXO

Observe el campo NACIONALIDAD, el dato Per se repite en dos filas, esto quebranta las reglas de segunda forma normal, la solucin es crear una nueva tabla con el nombre NACIONALIDAD y relacionarla con la tabla ACTOR.

ACTOR
Idactor(PK) cadena(6)no nulo Nombrecadena(60)no

NACIONALIDAD
Idnacionalidad(PK)cadena(30)n o nulo Nac_descripcioncadena(50)no nulo

TERCERA FORMA NORMAL (3FN)

Eliminar los campos que no dependan de la clave primaria

Buscar en el modelo relacional, si estos campos eliminados pertenecen a alguna tabla del modelo y agregarlos. Crear una nueva tabla con los campos eliminados. La tabla ACTOR ya se encuentra en segunda forma normal y en tercera forma normal, pero para explicar la tercera forma, se agregar algunos campos en la tabla.

ACTOR
Idactor(PK) cadena(6)no nulo Nombrecadena(60)no nulo Sexocadena(1)no nulo Idnacionalidad(FK) cadena(30)no nulo Preciopeliculadecimalno nulo

Observe

la

tabla

anterior,

el

campo

preciopeliculano tiene nada que ver con la clave

primaria de ACTOR, por lo tanto se aplica la tercera forma normal, y se elimina ese campo.

La tabla queda de la siguiente forma.

ACTOR
Idactor(PK) cadena(6) no nulo Nombrecadena(60) no nulo Sexocadena(1)no nulo
Idnacionalidad(FK)cadena(30)no nulo

Tema 02: Normalizacin de Aplicaciones

CASO: ALQUILER DE VIDEO
Modelo relacional del caso alquiler de video

Aplicar las tres formas normales a todas las tablas del diagrama, una por una, comenzado por la tabla PELICULA.

PELICULA
Idpelicula(PK) cadena(5) no nulo Titulo Nacionalidad nulo Productora nulo cadena(50) no cadena(40) no nulo no

cadena(50)

Fecha Director nulo

cadena(50) no nulo cadena(50) no

1 Forma Normal
Cuenta con una clave primaria y no tiene campos repetidos por lo tanto se encuentra en primera forma normal.

2 Forma Normal
idpelicul a 00001 titulo Mi pobre angelito Madagasca r Escorpin Rojo Paloma de papel Roqui I nacionalida d EUA productor a Warner Bros Warner Bros Warner Bros Columbiam picture Columbiam picture fecha 01/01/200 1 01/01/201 0 01/01/200 2 01/02/200 0 05/05/199 5 Directo r Peter Chun Walter Perez Peter Chun Walter Perez Peter Chun

00002

EUA

00003

EUA

00004

Per

00005

EUA

El campo nacionalidad, productora y director tiene datos repetidos por lo tanto forman parte de sus propias tablas.

NACIONALIDAD
Idnacionalidad(PK) cadena(5) no nulo Nac_descripcion cadena(40) no nulo

DIRECTOR
Iddirector(PK) cadena(5) no nulo dir_director cadena(40) no nulo

PRODUCTORA

Idproductora(PK) cadena(3) no nulo pro_descripcion cadena(40) no nulo

PELICULA
Idpelicula(PK) cadena(5) no nulo Titulo cadena(40) no nulo Idnacionalidad(FK) cadena(5) no nulo Idproductora(FK) cadena(3) no nulo Fecha cadena(50) no nulo Iddirector(FK) cadena(5) no nulo

La tabla PELICULA se encuentra en segunda y tercera forma normal.

Tabla ACTOR La tabla ACTOR esta en primera forma normal, pero el campo nacionalidad tiene datos repetidos, al normalizar la tabla en segunda forma queda de la siguiente manera:

ACTOR
Idactor(PK) cadena(6) no nulo Nombre cadena(60) no nulo Sexo cadena(1) no nulo Idnacionalidad(FK) cadena(30) no nulo

Tabla PELICULA_ACTOR 1 Forma Normal La tabla se encuentra en primera forma normal 2 Forma Normal

idpelicula 00001 00001 00001

idactor 00001 00002 00003

Tipoactor Principal Principal Secundario

El campo tipoactor tiene datos repetidos, por lo tanto se crea la tabla TIPOACTOR.

PELICULA_ACTOR
Idactor(PK) cadena(6) no nulo Nombre cadena(60) no nulo Sexo cadena(1) no nulo Idnacionalidad(FK) cadena(30) no nulo

TIPO_ACTOR
Idtipo(PK) cadena(3) no
nulo Tip_descripcion cadena(40) no nulo

Tabla EJEMPLAR

1 Forma Normal
La tabla se encuentra en primera forma normal

2 Forma normal

Idejemplar 0000000001 0000000002 0000000003

nro Ejemplar 01 Ejemplar 02 Ejemplar 03

estado Bueno Regular Bueno

Idpelicula 00001 00001 00001

El campo estado cuenta con datos redundantes o repetidos, entonces por segunda forma normal se crea la tabla ESTADO y se relaciona con

EJEMPLAR.

ESTADO
Idestado(PK) cadena(2) no nulo Est_descripcion cadena(30) no nulo 3 Forma Normal La tabla se encuentra en tercera forma normal

EJEMPLAR
Idejemplar(PK) cadena(10) no nulo Nro entero no nulo Idestado(FK) cadena(2) no nulo Idpelicula(FK) cadena(5) no nulo

ESTADO
Idestado(PK) cadena(2) no nulo Est_descripcion cadena(30) no nulo

Tabla SOCIO 1 Forma Normal La tabla se encuentra en primera forma normal

2 Forma Normal La tabla se encuentra en segunda forma normal 3 Forma Normal La tabla se encuentra en tercera forma normal

SOCIO
Idsocio(PK) cadena(5) no nulo Dni cadena(8) no nulo Nombre cadena(40) no nulo Direccin cadena(40) no nulo Telfono cadena(20) no nulo Aval cadena(5) no nulo

El aval es tambin un socio; a este tipo de relaciones se le conoce como recursivas.

idsocio 00001

00002

00003

direccion telefono Aval Av. Los Pedro 16791158 geranios 990994403 00002 Picapiedra 340 Jr. Conde Carla 10544348 de nieva 9026933658 00001 Mantilla 895 Av. Julio Manuel 12356987 C. Tello 879699652 00001 Cabezas 122

dni

nombre

SOCIO
Idsocio(PK) cadena(5) no nulo Dni cadena(8) no nulo Nombre cadena(40) no nulo Direccin cadena(40) no nulo Telfono cadena(20) no nulo

Como se observa en la tabla un socio puede ser aval de varias personas.

Tabla ALQUILER 1 Forma Normal Se encuentra en primera forma normal 2 Forma Normal No existe redundancia de datos 3 Forma Normal No hay ningn campo que no tenga nada que ver con la clave principal.

La tabla DETALLE_ALQUILER tambin se encuentra normalizada. Para finalizar, el modelo relacional del caso alquiler de video se encuentra normalizado y preparado para implementarse en un gestor de base de datos relacional.

Tema 03: Uso de Herramientas CASE

Las siglas de herramientas CASE en espaol es, Ingeniera de Software Asistida por Computador, estas herramientas ayudan a reducir el tiempo en el diseo de bases de datos.

Algunas Caractersticas

oReducir el tiempo en el modelamiento de datos oAyudan a la reutilizacin de las bases de datos

oAumentan la calidad del modelamiento

Es muy importante mencionar que las herramientas CASE, no pertenecen a ninguna de las cuatro etapas del modelamiento de datos, requisitos, modelo conceptual, modelo lgico y modelo fsico.

Terminado el modelo lgico (modelo relacional) con la normalizacin, el diseo de la base de datos, est preparado para ser puesto en produccin en el gestor de base de datos elegido (modelo fsico).

Ahora bien, las herramientas CASE para nuestro caso Erwin, son un nexo entre el modelo lgico y el fsico, su funcin principal, es reducir el tiempo en la transicin de modelo relacional (modelo lgico) al gestor de base de datos (modelo fsico), mas no una etapa ms en el modelamiento.

ERWIN
Herramientas CASE que sirve para el modelamiento de datos y la exportacin (ingeniera hacia adelante) de base de datos a diferentes gestores. Otra de sus funciones es la importacin (ingeniera hacia atrs) de una base de datos hacia Erwin.

INSTALACIN
Inserta el CD de instalacin y busque el archivo que tiene extensin exe o ejecutable.

Aparece la siguiente pantalla, click en siguiente

Aceptamos o clik en el botn I Agree

Se instala la aplicacin y al finalizar click en Next

Finalizada la instalacin click en si

Se ingresa la serie del producto y verificacin de la licencia

Luego click en continue. Como observas la instalacin es muy sencilla, a continuacin se explica el manejo de la herramienta. La barra de herramientas de Erwin

Barra de herramientas Lgica

Disear modelos de datos en Erwin Para comenzar click en File(archivo), new

Aparecen tres tipos de modelo Logical, Physical y logical/physical, seleccione la tercera.

Importante
Los modelos que usa Erwin lgico y fsico, no son los mismos que hemos utilizado para construir modelos de datos.Por ejemplo el modelo lgico de Erwin crea tablas sin tipos de datos y el fsico crea tablas con opcin de agregar tipos de dato, segn el gestor seleccionado.

Agregar dos entidades, pulsando clic en entidad:

Observe que existen dos tipos de relaciones identificatorias y no identificatorias (Relacin Punteada). Las no identificatorias se usan cuando la clave fornea, va a ser un campo de la tabla, en cambio las identificatorias, son parte de la clave primaria.

Idcliente es la clave primaria de la tabla CLIENTE

Relacin No identificatoria
El campo primario de la tabla CLIENTE pasa a la tabla FACTURA como un campo cualquiera de la tabla.

Relacin Identificatoria El campo primario de la tabla FACTURA, se convierte en campo primario de la tabla DETALLE_FACTURA, eso sucede cuando utilizamos relaciones identificatorias. El mismo caso ocurre con la tabla PRODUCTO al relacionarse con la tabla DETALLE_FACTURA.

Tema 04: Modelo Fsico

GESTOR DE BASE DE DATOS

Software que permite almacenar los datos relevantes de un rea o de toda la organizacin en tablas de informacin relacionadas.

Mysql

Gestor de base de datos relacional con amplia aceptacin en el mercado nacional e internacional, dentro de sus principales caractersticas se encuentran las siguientes:

Caractersticas

o Escrito en C y en C++ o Funciona en diferentes plataformas o Pueden usarse en mltiples CPU si estaran disponibles o Proporciona sistemas de almacenamiento transaccionales y no
transaccionales o Tiene un sistema de reserva de memoria basado en hilos. o Compresin de ndices para mayor rapidez o Joins muy rpidos

Instalacin de Mysql

Se utiliza AppServer para instalar mysql, es un paquete comprimido que contiene php, mysql y apache.

Veamos cmo se instala Para poder descargar este paquete podemos empezar buscando en google: bajar appserver, una pgina web recomendada es: http://www.freewarexp.com/descarga_gratis-3712-AppServ_2_5_7.html

Terminada la descarga hacemos doble click en el icono del instalador y pulsamos next.

Leer el acuerdo y click en el botn I Agree

Elegir el disco duro donde se instalar la aplicacin, caso contrario dejarlo por defecto c:\appserver. Luego click en siguiente (next).

Elegir los componentes que se van a instalar, sugiero que dejen todo como est.

Indicar el nombre del servidor y el correo electrnico del administrador, como es un ambiente de prueba, el servidor colocar localhost y el correo

root@estudiamucho.com

Agregar la clave del administrador de la base de datos, para nuestro caso root. Adems marcar la opcin Innodb para utilizar integridad referencial.

Para terminar la instalacin click en el botn Finish.

Para probar escribe en el navegador web http://localhost

El mysql es un gestor de base de datos relacional de lnea de comandos, y no tiene una interface grfica amigable para el usuario final. No obstante existen varios IDEs grficos para el mysql, como por ejemplo el SQLYog programa que tiene una interface grfica muy amigable.

Instalacin del SQLYog

Este software libre se baja de internet muy fcilmente; terminada la descarga, clicar en el archivo SQLyog despus hacer click en Next y escoger la opcin I accept in the Licence Agreement, pulsar Next, pulsar Next, y para finalizar pulsar Install, Next y Finish Al iniciar SQLYog pulsar New y donde dice Mysql host address, colocar localhost, en User Name, root y en password, la constrasea que escribieron al momento de instalar el appserver, en la parte de mysql.

Para finalizar en el campo database dejar en blanco para que aparezcan todas las bases de datos que se encuentran registradas en el mysql. Pgina electrnica para descargar Sqlyog (licencia por 30 dias) http://www.webyog.com/en/download_form.php?url=http%3A%2F%2Fwww.webyog.com%2F downloads%2FSQLyog-8.8.2-0Trial.exe&category_tier=SQLyog%20Trial

Vistas principales del SQLYog

Barras de Men
Conjuntos de opciones que sirven para gestionar el mysql(SQLYog)

Barras de Herramientas
Son parte de las opciones que se encuentran en la barra de men pero de forma grfica (iconos).

IMPORTANTE Ahora crearemos una base de datos, usando el administrador del mysql.

Crear una nueva base de datos

1. Click derecho en root@localhost y click en Create Database

2. Como ya tenemos el modelo relacional de la BD VIDEO, es el momento para utilizar un gestor, entonces escribir el nombre VIDEO y click en create.

3. Desplegar la base de datos VIDEO y click derecho en tables.

4. Agregamos la tabla PRODUCTORA, esta tabla solo tiene campos propios, no forneos, por ese motivo se agrega primero. Si observa con atencin, es prcticamente lo mismo que en el modelo relacional, no obstante hay que tener en cuenta las siguientes consideraciones.

Tipos de datos Modelo relacional Modelo fsico (mysql) cadena Char, varchar numerico Int, tinyint real Double, decimal fecha Date, datetime

Tipos char y varchar

Los tipos char utilizan longitud fija y varchar variable, un ejemplo para entenderlo mejor, si registro nombres de alumnos, no todos los alumnos tienen el nombre con el

mismo tamao, por lo tanto es variable, si decido utilizar char(40) como tipo de dato, aunque existan nombres de 20 dgitos el mysql completar lo que le falta para llegar a 40 con espacios en blanco. Sugiero que solamente utilicen char cuando la longitud es fija caso el dni, ruc, numero de boleta, numero de factura, otros.

Tipo doubl y int

El tipo doubl utiliza datos con decimales mientras que int solamente utiliza nmeros enteros positivos.

Tipos fecha Date

Almacena solo fecha. El rango de valores de fecha comprende desde el 1 de enero del 1001 al 31 de diciembre de 9999. Es importante recalcar que el formato almacenado es ao-mes-da.

DateTime

Combinacin de fecha y hora.El rango de valores comprende desde el 1 de enero de 1001 a la 0 horas, 0 minutos y 0 segundos, al 31 de diciembre de 9999 a las 23 horas, 59 minutos, 59 segundos.

Continuamos con la creacin de la tabla PRODUCTORA

No olvidarse de marcar el campo idproductora como clave primaria, solamente se checkea la columna PK. 2. Terminamos con el llenado de la tabla y click en Create Tabla.

Colocar el nombre PRODUCTORA y para finalizar esta parte click en OK. 3. La siguiente opcin sirve en caso queremos continuar agregando tablas al diagrama, click en no.

4. Click en tables y observar la tabla PRODUCTORA.

5. Pasamos al llenado de datos, la razn de ser del modelo. Click derecho en PRODUCTORA, click en Open Table.

6. Llenar datos de productoras reales.

7. Para grabar los datos click en Save Changes(Disco)

Contine con el resto de tablas, hasta completar todo el modelo relacional del caso Alquiler de video

Eliminar y modificar tablas

Para modificar campos de la tabla en caso se equivoc en escribir, click derecho en la tabla, Alter table.

Realizar los cambios necesarios y pulsar el botn Alter.

Para eliminar una tabla, click derecho sobre la tabla y click en la opcin drop table.

UNIDAD 4 MODELO FISICO Y LENGUAJE ESTRUCTURADO DE CONSULTAS

INTRODUCCIN
a)Presentacin y contextualizacin Es importante conocer todas las formas de creacin de bases de datos que existen, en esta unidad aprender a Construir bases de datos utilizando sentencias sql de definicin de datos. Escribir sentencias SQL para crear bases de datos, tablas y constrains, as como la modificacin y eliminacin de estas. Establecer relaciones de clave fornea entre tablas, manejo del motor de almacenamiento MyIsam y innodb. En el tema 2 manejo de operadores aritmticos, de comparacin y lgicos, que servirn como base para las sentencias de recuperacin de resultados, agrupamiento y ordenacin, adems de la insercin, modificacin y eliminacin de datos de la base de datos. En el tema 3 uso de joins para recuperar informacin de varias tablas y agrupamiento a un nivel avanzado Por ltimo, cuando existan situaciones que no se pueden elaborar con los joins, el uso de sub consultas es la solucin, adems de sentencias IF y manejo de fechas. b)Competencia Construye scripts de bases de datos utilizando instrucciones SQL y elabora consultas SQL bsicas y avanzadas. c)Capacidades 1. Aplica sentencias SQL para crear bases de datos. 2. Aplica sentencias SQL para obtener resultados. 3. Usa y aplica sentencias SQL para recuperar y extraer informacin de varias tablas. 4. Elabora consultas SQL utilizando instrucciones IF y funciones para fechas. d)Actitudes Prctica a conciencia, sentencias para crear bases de datos mediante cdigo Lee con dedicacin material adicional sobre consultas SQL bsicas y avanzadas. Se esfuerza por investigar ms sobre sentencias SQL avanzadas y las comparte con sus compaeros de grupo. e)Presentacin de Ideas bsicas y contenido esenciales de la Unidad: La Unidad de Aprendizaje 4: Modelo Fsico y Lenguaje Estructurado de consultas, comprende el desarrollo de los siguientes temas:

TEMA 01: CONSTRUCCIN DE BASES DE DATOS UTILIZANDO INSTRUCCIONES SQL TEMA 02: USO DE SENTENCIAS SQL PARA OBTENER RESULTADOS TEMA 03: USO DE SENTENCIAS SQL PARA RECUPERAR Y EXTRAER INFORMACIN DE VARIAS TABLAS TEMA 04: SENTENCIAS SQL AVANZADAS

Tema 01: Construccin de bases de datos utilizando instrucciones SQL

La razn principal de una instruccin SQL, es recuperar informacin de una o varias tablas del modelo relacional. Por sus siglas en Ingles el Lenguaje SQL significa, Structured query language, es un estndar que se utiliza en todos los gestores de base de datos relacional, con algunos cambios menores.

SENTENCIAS DE DEFINICIN DE DATOS

Sirven para crear, eliminar y modificar modelos relacionales de base de datos, algunas de las sentencias que estudiaremos sern: o CREATE DATABASE o CREATE TABLE o ALTER TABLE o DROP DATABASE o DROP TABLE

CREATE DATABASE: Sentencia que sirve para crear bases de datos Sintaxis: create database nombre_base_de_datos Para ejecutar la sentencia pulsar F9 y en la vista de base de datos, ir al directorio raz (root@localhost) y actualizar la lista de bases de datos con F5.

DROP DATABASE Elimina una base de datos del mysql Sintaxis: Drop database nombre_base_de_datos Primero seleccionar information_schema, escribir la sentencia drop database y el nombre de la base de datos, pulsar F9, seleccionar el directorio raz y pulsar F5.

CREATE TABLE

Sentencia que permite crear tablas y campos de una base de datos.

Sintaxis: Create table nombre_tabla ( nombre_campo1 tipo_de_dato(tamao), Nombre_campo2 tipo_de_dato(tamao) . );

Es muy fcil escribir sentencias SQL, slo algunas consideraciones que es preciso tener en cuenta: en el ltimo campo de la tabla no se coloca coma, adems no se ha definido la clave primaria y fornea, veamos cmo se definen.

MOTOR DE ALMACENAMIENTO INNODB

Sirve para agregar integridad referencial al modelo de datos del mysql, cada tabla tiene que tener el motor de almacenamiento INNODB. Otra caracterstica es permitir relaciones entre tablas mediante claves forneas y constraint.

Por defecto las tablas del mysql, pertenecen al motor de almacenamiento MyISAM, el cual no permite la integridad referencial.

CREATE CONSTRAINT

Sirven para forzar la integridad referencial entre tablas, en la relacin ACTOR NACIONALIDAD, sino agrego constraint el mysql permitir agregar nacionalidades en la tabla ACTOR que no estn registradas en la tabla NACIONALIDAD, esto rompe las reglas de integridad referencial de los datos.

En este caso se trabaja con dos tipos de constraints, para clave primaria y fornea, hay otras formas para definir las claves primarias, pero el mtodo ms seguro es utilizando constraints. Antes de explicar los ejemplos con constraints se necesita aprender el concepto de la sentencia ALTER TABLE. ALTER TABLE
Permite la modificacin de los campos de una tabla como son: cambiar el nombre a un campo, agregar campos, cambiar el tipo de dato y la longitud, aplicar constraints.

Continuando con el ejemplo, se agrega claves primarias y forneas, utilizando constraints y alter table.

Tema 02: Uso de sentencias SQL para obtener resultados

OPERADORES Se utilizan para realizar comparaciones entre datos entre otros aspectos se me mencionan a continuacin. Se dividen en aritmticos, relacionales,lgicos y concatenacin.

1. Mostrar la lista de pelculas con su titulo y fecha SELECT titulo, fecha FROM PELICULA 2. Mostrar un listado de todas las pelculas SELECT * FROM PELICULA 3. Mostrar una lista de actores con su nombre y sexo, cuyo sexo sea masculino SELECT nombre sexo FROM ACTOR WHERE sexo=M 4. Mostrar las pelculas que se han registrado el 15/10/2006 SELECT * FROM PELICULA WHERE fecha=15/10/2006 5. Mostrar las pelculas que se han registrado entre el 15/05/2000 y el 20/05/2000. SELECT * FROM PELICULA WHERE fecha=15/05/2000 and fecha=20/05/2000 Sentencias SQL como AVG, COUNT, MIN, MAX, SUM, son muy tiles para trabajar con agrupaciones: AVG Sentencia que sirve para calcular el promedio de un conjunto de

resultados COUNT Muestra la cantidad de elementos de una tabla MIN Muestra el mnimo datos de un conjunto de registros MAX Muestra el mximo dato de un conjunto de registros SUM Muestra la suma total de un conjunto de registros o un grupo ALQUILER Idalquiler (PK) cadena(10) no nulo Fecha_inicio fecha no nulo Fecha_final fecha no nulo Total decimal no nulo Idsocio(FK) cadena(5) no nulo 1. Mostrar la suma de total de pelculas alquiladas del socio con codio 00001 SELECT SUM(total) FROM ALQUILER WHERE idsocio=00001 2. Mostrar el promedio de pelculas alquiladas SELECT AVG (total) FROM ALQUILER 3. Mostrar la cantidad de socios registrados SELECT COUNT(idsocio) FROM SOCIO 4. Mostrar el mximo y mnimo alquiler registrado SELECT MAX(total) FROM ALQUILER SELECT MIN(total) FROM ALQUILER Consultas con predicado BETTWEENAND > Comprueba si un valor esta dentro de un intervalo, es semejante a AND. LIKE > Comprar un campo con un carcter y permite el uso de comodines. IN > Comprueba si un dato de un campo se encuentra dentro de un determinado rango

INSERT INTO Sirve para insertar datos a la base de datos. Sintaxis INSERT INTO nombre_tabla(campo1, campo2,..)VALUES(valor1,valor2,..)

La primera parte de la sentencia es el nombre de la tabla con sus campos, en la segunda parte son los datos a insertar.

Tema 03: Uso de sentencias para recuperar y extraer informacin de varias tablas

JOINS Permite recuperar informacin de varias tablas

INNER JOIN Recupera informacin de dos a ms tablas. Sintaxis: SELECT campos FROM tabla1 INNER JOIN tabla2 ON tabla1.campo=tabla2.cmpo INNER JOIN > Clusula para definir la tabla a relacionar. ON > Permite establecer la relacin con el campo similar en las dos tablas, por lo general la clave primaria. Relacionando las tablas AUTOR y NACIONALIDAD, del caso alquiler de video, establecer una consulta SQL que muestre un listado de actores con sus respectivas nacionalidades.

Observe que tanto la tabla NACIONALIDAD y AUTOR, ha cambiado el nombre AUTOR por a y NACIONALIDAD por n. Estos nombres cortos se conocen como alias, sirven para tener nombres ms reducidos, tanto de tablas como de campos. Elaborar una consulta SQL que muestre las pelculas con sus respectivos directores

Ejemplo:

Listar todas las pelculas registradas en la base de datos con sus respectivos PRODUCTOR, DIRECTOR, NACIONALIDAD Antes de desarrollar la consulta SQL, considere algunos consejos, tener el grfico del modelo relacional o modelo fsico impreso, y pegarlo cerca a donde est trabajando. Recuerde que no importa con cual tabla comience la consulta SQL.

SELECT PE.TITULO,N.NAC_DESCRIPCION,D.DIR_DIRECTOR,P.PRO_DESCRIPCION FROM PELICULA PE INNER JOIN PRODUCTORA P ON P.IDPRODUCTORA=PE.IDPRODUCTORA INNER JOIN DIRECTOR D ON D.IDDIRECTOR=PE.IDDIRECTOR INNER JOIN NACIONALIDAD N ON N.IDNACIONALIDAD=PE.IDNACIONALIDAD Otro aspecto importante es el campo para relacionar las tablas, por lo general, es el campo que se repite en las dos tablas, en la tabla PRODUCTORA y PELICULA, se repite idproductora, entonces este campo es el que se relaciona. Siguiendo este modelo se relacionan las dems tablas.

LEFT JOIN Es prcticamente lo mismo que INNER JOIN, con la diferencia que LEFT JOIN, compara todos los datos de la izquierda con los de la derecha, pero si no existen coincidencias en la derecha, los coloca como NULL y muestra los resultados sin importar que existan coincidencias. Ejemplo: Listar todas las pelculas con sus directores

CROSS JOIN Producto cartesiano de todos los registros de las dos tablas, no incluye ON para filtrar los resultados. Ejemplo: Mostrar los actores por nacionalidad. SELECT * FROM ACTOR CROSS JOIN NACIONALIDAD

CLAUSULAS GROUP BY Y HAVING Permite obtener grupos de resultados, en la relacin con varias tablas. Ejemplo: Mostrar un listado de pases y cantidad de pelculas de ese pas.

De la consulta anterior, mostrar los pases que tengan ms de 6 pelculas producidas. SELECT

N.NAC_DESCRIPCION,COUNT(P.idpelicula) FROM PELICULA P INNER JOIN NACIONALIDAD N ON N.IDNACIONALIDAD=P.IDNACIONALIDAD GROUP BY N.NAC_DESCRIPCION HAVING COUNT(P.idpelicula)>6 Cuando se trabaja con grupos, se utiliza la sentencia HAVING y no WHERE.

Tema 04: Sentencias SQL Avanzadas

SUB CONSULTAS Las sub consultas son construcciones especiales que difcilmente se podran realizar con JOINS. Es una sentencia dentro de otra sentencia, por lo general se utiliza dentro del WHERE o inclusive dentro de la lista de seleccin. En una base de datos comercial, se pide mostrar los pedidos del cliente 000001, cuyo monto sea mayor al promedio de pedidos general.

La tabla de la cual se evalan los resultados es

Como se observa el campo total se compara con el total general en cada registro, para el primer caso el total es 100, y se dice 100>133.333333, no, como no cumple ese registro no se toma en cuenta.

USO DE IF CON CONSULTAS SQL Sirve para establecer condiciones dentro de una sentencia SELECT Sintaxis SELECT IF(condicin, verdad, falso)as alias FROM nombre_tabla

Ejemplo: Elaborar una consulta SQL, para calcular el nmero correlativo en la tabla CLIENTE de la base de datos COMERCIAL.

Otro ejemplo: Elaborar una consulta SQL que muestre un mensaje Existe, cuando encuentre el nmero de DNI pedido, y No existe cuando no lo encuentre. Observar la tabla CLIENTE: