Profesores: Barriento Herminia, Bracho Damelys, Bracho Javier, Daz Wilfredo, Gutirrez Aniger, Smith Edith, Zavala Reina

UNIVERSIDAD NACIONAL EXPERIMENTAL "FRANCISCO DE MIRANDA" COMPLEJO ACADEMICO EL SABINO DEPARTAMENTO DE GERENCIA

PROGRAMACION DIGITAL
UNIDAD 2: BASE DE DATOS CONTENIDO:
1) BASES DE DATOS Definicin. Objetivos. Caractersticas. Desventajas. Sistema Manejador de Bases de Datos. Modelos de Base de Datos. Base de Datos Relacional. 2) MODELO ENTIDAD-RELACION Definicin. Elementos. Diagrama Entidad-Relacin. Simbologa. Tipos De Relaciones. Modelo Relacional. Pasos Del Modelo Entidad Relacin Al Modelo Relacional. 3) NORMALIZACION Definicin. Conceptos Bsicos. Formas Normales.

Profesores: Barriento Herminia, Bracho Damelys, Bracho Javier, Daz Wilfredo, Gutirrez Aniger, Smith Edith, Zavala Reina

UNIDAD II: BASES DE DATOS Las bases de datos se idearon gracias a la necesidad de las grandes empresas de almacenar grandes cantidades de informacin de una forma rpida, sencilla y fiable, y que a su vez pudieran acceder a ella en cualquier momento sin necesidad de desplazarse a salas dedicadas a archivar documentacin, como hasta hace poco se vena haciendo. Cuando comenz el despliegue de los programas informticos se empezaron a almacenar datos en los archivos de los programas, lo cual era ms cmodo pero aun as tenan grandes dificultades a la hora de querer modificar registros, estructuras o simplemente buscar informacin. A finales de los aos sesenta nacen las bases de datos. DEFINICION Puede definirse como un conjunto de datos pertenecientes a un mismo contexto organizados para un uso determinado de tal modo que resulte fcil acceder a ellos para gestionarlos y actualizarlos. Es una fuente central de datos que est pensada para que pueda ser compartida por muchos usuarios con una diversidad de aplicaciones. Permite almacenar datos de forma organizada y obtener informacin acerca de esos datos. Ejemplos: Base de Datos de estudiantes en la universidad, pacientes en un hospital, clientes de un supermercado. OBJETIVOS Mantener datos precisos y consistentes. Asegurar que todos los datos requeridos para las aplicaciones actuales y futuras estn disponibles. Permitir que la base de datos evolucione. CARACTERSTICAS Control Centralizado de los Datos. Mnima Redundancia. Acceso concurrente por parte de mltiples usuarios. Integridad de los datos. Consistencia de Datos. Consultas complejas optimizadas. Seguridad de acceso. Respaldo y recuperacin.

Profesores: Barriento Herminia, Bracho Damelys, Bracho Javier, Daz Wilfredo, Gutirrez Aniger, Smith Edith, Zavala Reina

SISTEMA MANEJADOR DE BASES DE DATOS (SMBD) Son programas que permiten la creacin, modificacin y actualizacin de la base de Datos, la recuperacin de datos y la generacin de reportes. Ejemplo: MySql, PostgreSql, Microsoft SQL Server, Microsoft Access, Oracle, Informix, Paradox, DB2. Los sistemas manejadores de bases de datos son un tipo de software muy especfico, dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan.

MODELOS DE BASE DE DATOS Un modelo es una representacin del mundo real, por lo que un modelo de datos es una coleccin de herramientas conceptuales que se emplean para especificar datos, las relaciones entre ellos, la semntica asociada y las restricciones de integridad. Un modelo de datos est orientado a describir una Base de Datos. Tpicamente un modelo de datos permite describir: Las estructuras de datos de la base: El tipo de los datos que hay en la base y la forma en que se relacionan. Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los datos para reflejar correctamente la realidad deseada. Operaciones de manipulacin de los datos: tpicamente, operaciones de agregado, borrado, modificacin y recuperacin de los datos de la base. CLASIFICACION DE LOS MODELOS DE DATOS De acuerdo al nivel de abstraccin que presentan pueden emplearse: Modelos de Datos Conceptuales: Se usan fundamentalmente durante la etapa de Anlisis de un problema dado y estn orientados a representar los elementos que intervienen en ese problema y sus relaciones. El ejemplo ms tpico es el Modelo Entidad-Relacin. Modelos de Datos Lgicos: Son orientados a las operaciones ms que a la descripcin de una realidad. Usualmente estn implementados en algn Manejador de Base de Datos. Los ms comunes son: a) Modelo Jerrquico: utiliza rboles para la representacin lgica de los datos. Un rbol est compuesto por una jerarqua de elementos llamados nodos. El nivel ms alto de la jerarqua tiene un solo nodo que se llama raz. Cada nodo representa un tipo de registro llamado segmento con sus correspondientes campos. La principal deficiencia de este modelo radica en que no implementa ningn control sobre los propios datos por lo que existe duplicidad de los mismos, de igual forma no existe garanta de que un registro hijo est relacionado con un registro padre vlido por lo que en

Profesores: Barriento Herminia, Bracho Damelys, Bracho Javier, Daz Wilfredo, Gutirrez Aniger, Smith Edith, Zavala Reina

ocasiones se infringe la integridad referencial. Por ejemplo, es posible borrar un nodo padre sin eliminar antes los nodos hijo, de manera que stos ltimos estn relacionados con un registro invlido o inexistente. b) Modelo Red: utiliza estructura de datos en red donde las entidades se representan como nodos, y las relaciones como lneas que unen a los nodos. En una estructura de red cualquier componente puede vincularse con cualquier otro. Es posible describirla en trminos de padres e hijos, pero, a diferencia del modelo jerrquico, un nodo hijo puede tener varios padres. c) Modelo Relacional: ste es el modelo utilizado en la actualidad para modelar problemas reales y administrar datos dinmicamente. Su idea fundamental es el uso de "relaciones" donde cada ente del mundo real (tabla) se almacena en un lugar diferente y posteriormente se establecen relaciones entre dichos entes (tablas). Las bases de datos relacionales estn constituidas por una o ms tablas que contienen la informacin ordenada de una forma organizada BASE DE DATOS RELACIONALES Las bases de datos relacionales se basan en el uso de tablas. Las tablas se representan grficamente como una estructura rectangular formada por filas y columnas. Cada columna almacena informacin sobre una propiedad determinada de la tabla (se le llama tambin atributo) ej: nombre, CI, apellidos, edad. Cada fila posee una registro de la relacin representada por la tabla (a las filas se las llama tambin tuplas). Terminologa Relacional Clave Principal: atributo o conjunto de atributos que identifican de manera exclusiva un asunto guardado en una tabla o relacin. Tupla: Cada fila de la tabla. Atributo: Cada columna de la tabla. Grado: Nmero de atributos de la tabla. Cardinalidad: Nmero de tuplas de una tabla. Dominio: Conjunto vlido de valores representables por un atributo.

Profesores: Barriento Herminia, Bracho Damelys, Bracho Javier, Daz Wilfredo, Gutirrez Aniger, Smith Edith, Zavala Reina

REPRESENTACION GRAFICA DE UNA TABLA O RELACION

CLAVE PRINCIPAL Venezuela Mxico Chile DOMINIO DEL ATRIBUTO PAIS

Cdula 19.455.555 15.555.555 12.555.333

Nombre Mara Jos Pedro

Apellido Prez Puerta Gonzlez

Edad 22 21 1

Pas Venezuela Mxico Chile

FILAS (Tuplas)

Cardinalidad=3 Grado=5
COLUMNAS: Cdula, Nombre, Apellido, Edad, Pas Atributos

MODELO ENTIDAD RELACIN. (M E-R) El modelo entidad-relacin se basa en una percepcin de un mundo real que consiste en un conjunto de objetos bsicos llamados entidades y de relaciones entre estos objetos. ELEMENTOS DE UN MODELO ENTIDAD RELACION Entidad: Es un objeto que existe y es distinguible de otros objetos. Puede ser concreta (persona, libro, carro, casa) o abstracta como un concepto (prstamo, vacaciones, vuelo). En otras palabras, es un objeto del mundo real que tiene existencia por s mismo y se puede identificar y describir de manera clara y precisa. Atributos: definen cada una de las propiedades o caractersticas propias de una entidad o de una relacin. Relacin: Una relacin es una asociacin entre varias entidades. Puede haber ms de un vnculo entre dos entidades. Una relacin tambin puede tener atributos de relacin, o atributos descriptivos, los cuales representan caractersticas propias de la asociacin entre varias entidades. (comn en tipos de relacin muchos a muchos ) Clave de Entidad: Atributo o conjunto de atributos que identifican de forma nica cada entidad.

Profesores: Barriento Herminia, Bracho Damelys, Bracho Javier, Daz Wilfredo, Gutirrez Aniger, Smith Edith, Zavala Reina

SIMBOLOGA UTILIZADA EN EL MODELO ENTIDAD / RELACIN DESCRIPCIN SMBOLO EJEMPLO Entidad Rectngulos: representan conjuntos de Entidades.
CLIENTE

Elipses: representan atributos Lneas: conectan los atributos a los conjuntos de entidades, y los conjuntos de relaciones Rombos: representan relaciones.

Atributo
Nombre

Conexin
Nombre CI Apellido

Cliente

Relacin
cliente asigna Producto

PASOS PARA ELABORAR UN DIAGRAMA ENTIDAD RELACION 1. Se parte de una descripcin textual del problema o sistema de informacin a automatizar (los requisitos). 2. Se hace una lista de los sustantivos y verbos que aparecen; los cuales sern posibles entidades o atributos. 3. Los verbos son posibles relaciones. 4. Analizando las frases se determina la cardinalidad (tipo de relacin) y otros detalles. 5. Se elabora el diagrama entidad-relacin. 6. Se completa el modelo con listas de atributos. TIPOS DE RELACIONES: MODELO ENTIDAD RELACIN RELACIN Relacin uno a uno (1:1, 1/1): Una entidad del tipo A solo se puede relacionar con un registro de la entidad del tipo B, y viceversa. A Relacin uno a Muchos (1:n, 1/): Significa que una entidad del tipo A puede relacionarse con cualquier cantidad de registros de la entidad B, y una entidad del tipo B solo puede estar relacionada con un registro de la entidad del tipo A. SMBOLOGA

Profesores: Barriento Herminia, Bracho Damelys, Bracho Javier, Daz Wilfredo, Gutirrez Aniger, Smith Edith, Zavala Reina

Relacin Muchos a Muchos (n:n, /): Establece que cualquier cantidad de registros de la entidad A pueden estar relacionados con cualquier cantidad de registros de la entidad B y viceversa.

EJEMPLOS DE LOS DISTINTOS TIPOS DE RELACIONES Relacin Uno a Uno: Disear el modelo E-R, para la relacin Registro de automvil que consiste en obtener la tarjeta de circulacin de un automvil con los siguientes datos:Automvil- Modelo, Placas, Color / Tarjeta de circulacin -Propietario, No_serie, Tipo.
Propietario Modelo Placa Color No Serie Tipo

Automvil

Registra

Tarjeta de Circulacin

En este ejemplo existe una relacin de pertenencia de uno a uno, ya que existe una tarjeta de circulacin registrada por cada automvil. Relacin Uno a muchos: El siguiente ejemplo indica que un cliente puede tener muchas cuentas, pero que una cuenta puede llegar a pertenecer a un solo cliente (Se indica que puede, ya que existen cuentas registradas a favor de ms de una persona En este caso).
TipoCuenta Nombre CI Direccin No Cta Saldo

Cliente

Apertura

Cuenta

Relacin Muchos a Muchos: Un estudiante puede cursar muchas materias, y una materia puede ser cursada por muchos estudiantes
CI Nombre Direccin Materia Cod Mate UC

Estudiante

cursa

Materia

Profesores: Barriento Herminia, Bracho Damelys, Bracho Javier, Daz Wilfredo, Gutirrez Aniger, Smith Edith, Zavala Reina

EJERCICIOS RESUELTOS DE MODELO ENTIDAD RELACIN 1.- Una empresa vende productos a varios clientes. Se necesita conocer los datos personales de los clientes (nombre, apellidos, ci, direccin y fecha de nacimiento). Cada producto tiene un nombre y un cdigo, as como un precio unitario. Un cliente puede comprar varios productos a la empresa, y un mismo producto puede ser comprado por varios clientes. Los productos son suministrados por diferentes proveedores. Se debe tener en cuenta que un producto slo puede ser suministrado por un proveedor, y que un proveedor puede suministrar diferentes productos. De cada proveedor se desea conocer el RIF, nombre y direccin.
Apellido Nombre Precio ci Nombre Cdigo

Direccin

Cliente

compra

Producto

Fecha Nac suministra

Proveedor

RIF

Nombre

Direccin

Profesores: Barriento Herminia, Bracho Damelys, Bracho Javier, Daz Wilfredo, Gutirrez Aniger, Smith Edith, Zavala Reina

2.- Se desea informatizar la gestin de una empresa de transportes que reparte paquetes por toda Venezuela. Los encargados de llevar los paquetes son los camioneros, de los que se quiere guardar la cedula, nombre, telfono, direccin, salario y poblacin en la que vive. De los paquetes transportados interesa conocer el cdigo de paquete, descripcin, destinatario y direccin del destinatario. Un camionero distribuye muchos paquetes, y un paquete slo puede ser distribuido por un camionero. De las provincias a las que llegan los paquetes interesa guardar el cdigo de provincia y el nombre. Un paquete slo puede llegar a una provincia. Sin embargo, a una provincia pueden llegar varios paquetes. De los camiones que llevan los camioneros, interesa conocer la matrcula, modelo, tipo y potencia. Un camionero puede conducir diferentes camiones, y un camin puede ser conducido por varios camioneros.

Telfono Nombre

cedula

Modelo

Matricula Tipo

Direccin

Camionero

conduce

Camin

Potencia

Salario llevan

Poblacin cdigo Nombre

Cdigo

Paquete

compra

Provincia

Descripcin

Destinatario

Direccin del destinatario

Profesores: Barriento Herminia, Bracho Damelys, Bracho Javier, Daz Wilfredo, Gutirrez Aniger, Smith Edith, Zavala Reina

3.- Representar el diagrama entidad-relacin para las gestiones de un instituto. En la base de datos se desea guardar los datos de los profesores del instituto (CI, nombre, direccin, telfono). Los profesores imparten mdulos y cada modulo tiene un cdigo y un nombre. Cada alumno est matriculado en uno o varios mdulos y en un mdulo puede haber ms de un alumno. De cada alumno se desea guardar el nro. de expediente, nombre, apellido y fecha de nacimiento. Los profesores pueden impartir varios mdulos pero un modulo solo puede ser impartido por un profesor.

Cod_modul o

Nombre

MODULO

Imparte

est

PROFESOR ALUMNO telfono CI Nroexpe nombre direccin nombre apellidos Fecha _nac

4.- Una empresa desea disear una base de datos para almacenar en ella toda la informacin generada en cada uno de los proyectos que sta realiza. De cada uno de los proyectos realizados interesa almacenar el cdigo, descripcin, monto del proyecto, fecha de inicio y fecha de fin. Los proyectos son realizados por clientes de los que se desea guardar el cdigo, telfono, domicilio y razn social. Un cliente puede realizar varios proyectos, pero un solo proyecto es realizado por un nico cliente. En los proyectos participan colaboradores de los que se dispone la siguiente informacin: rif, nombre domicilio, telfono, banco y nmero de cuenta. Un colaborador puede participar en varios proyectos. Los proyectos son realizados por uno o ms colaboradores. Un colaborador de proyecto puede recibir varios pagos. De los pagos realizados se requiere guardar el nmero de pago, concepto, cantidad y fecha de pago. Tambin interesa almacenar los diferentes tipos de pago que puede realizar la empresa. De cada uno de los tipos de pagos se desea guardar el cdigo y descripcin. Un tipo de pago pude pertenecer a varios pagos. 10

Profesores: Barriento Herminia, Bracho Damelys, Bracho Javier, Daz Wilfredo, Gutirrez Aniger, Smith Edith, Zavala Reina

Fecha Fin Fecha Ini

Cdigo

Descripcin Cantidad Concepto

Cdigo

Descripcin

monto

TIPO DE PAGO PROYECTO

Nro pago

Fecha

Pertenece

PAGO
Participa

Puede Realizar

Reciben

COLABORADOR
Nro Cuenta rif

CLIENTE

Nombre Banco Telfono

Domicilio

Cdigo

Telfono

Domicilio Razon Soc

11

Profesores: Barriento Herminia, Bracho Damelys, Bracho Javier, Daz Wilfredo, Gutirrez Aniger, Smith Edith, Zavala Reina

5. La Clnica San Andrs, necesita llevar un control informatizado de su gestin de pacientes y mdicos. De cada paciente se desea guardar el cdigo, nombre, apellidos, direccin, poblacin, provincia, cdigo postal, telfono, fecha de nacimiento. De cada mdico se desea guardar el cdigo, nombre, apellido, telfono y especialidad. Se desea llevar el control de cada uno de los ingresos que el paciente hace en el hospital. Cada ingreso que realiza el paciente queda registrado en la base de datos. De cada ingreso se guarda el cdigo de ingreso (que se incrementa automticamente cada vez que el paciente realice un ingreso), el nmero de habitacin y cama en el que el paciente realiza el ingreso y la fecha de ingreso. Un mdico puede atender varios ingresos, pero el ingreso del paciente solo puede ser atendido por un nico mdico. Un paciente puede realizar varios ingresos al hospital.
apellido Direccion nombre Poblacion Telefono CodigoPa FechaNac Provincia CodigoPostal

PACIENTE

Realiza
NroCama FechaIngreso NumHab Apellido Nombre Codigo Especialidad Telfono

CodigoIngreso

INGRESO

atiende

MEDICO

6. Una agencia de viajes desea informatizar toda la gestin de los viajeros que acuden a la agencia y los viajes que estos realizan. Tras ponernos en contacto con la agencia, sta nos proporciona la siguiente informacin. La agencia desea guardar la siguiente informacin de los viajeros: ci, nombre, direccin y telfono. De cada uno de los viajes que maneja la agencia interesa guardar el cdigo de viaje, nmero de plazas, fecha en la que se realiza el viaje y otros datos. Un viajero puede realizar tantos viajes como desee con la agencia. Un viaje determinado slo puede ser cubierto por un viajero. Cada viaje realizado tiene un destino y un lugar de origen. De cada uno de ellos se quiere almacenar el cdigo, nombre. Un viaje tiene un nico lugar de destino y un nico lugar de origen. De un origen pueden partir varios viajes y a un destino pueden llegar varios viajes.

12

Profesores: Barriento Herminia, Bracho Damelys, Bracho Javier, Daz Wilfredo, Gutirrez Aniger, Smith Edith, Zavala Reina

CI

Nombre Direccin

VIAJERO
Telfono

Realiza
Num_plaza
COD_VIAJE

Fecha

Cod_origen

VIAJE
Cod_destino
COD_DESTINO

Nombre Num_pasajero

Hora_llegada

DESTINO
Duracin

Tiene

Tiene

ORIGEN
COD_ORIGEN

Nombre

Hora_Salida

EJERCICIOS PROPUESTOS 1) A un concesionario de autos llegan clientes para comprar automviles. De cada auto interesa saber la matrcula, modelo, marca y color. Un cliente puede comprar varios autos en el concesionario. Cuando un cliente compra un auto, se le hace una ficha en el concesionario con la siguiente informacin: ci, nombre, apellidos, direccin y telfono. El concesionario tambin dispone de un taller en el que los mecnicos reparan los autos que llevan los clientes. Un mecnico repara varios autos a lo largo del da, y un auto puede ser reparado por varios mecnicos. Los mecnicos tienen un ci, nombre, apellidos, fecha de contratacin y salario. 2) Una empresa necesita organizar la siguiente informacin referente a su organizacin interna. La empresa est organizada en una serie de departamentos. Cada departamento 13

Profesores: Barriento Herminia, Bracho Damelys, Bracho Javier, Daz Wilfredo, Gutirrez Aniger, Smith Edith, Zavala Reina

tiene un cdigo, nombre y presupuesto anual. Cada departamento est ubicado en un centro de trabajo. La informacin que se desea guardar del centro de trabajo es el cdigo de centro, nombre, poblacin y direccin del centro. La empresa tiene una serie de empleados. Cada empleado tiene un telfono, RIF, nombre y salario. A esta empresa tambin le interesa tener guardada informacin sobre los hijos de los empleados. Cada hijo de un empleado tendr un cdigo, nombre y fecha de nacimiento. Se desea mantener tambin informacin sobre las habilidades de los empleados (por ejemplo, mercadotecnia, trato con el cliente, fresador, operador de telefona, etc). Cada habilidad tendr una descripcin y un cdigo. Sobre este supuesto disear el modelo E/R y el modelo relacional teniendo en cuenta los siguientes aspectos. Un empleado est asignado a un nico departamento. Un departamento estar compuesto por uno o ms empleados. Cada departamento se ubica en un nico centro de trabajo. Estos se componen de uno o ms departamentos. Un empleado puede tener varios hijos. Un empleado puede tener varias habilidades, y una misma habilidad puede ser poseda por empleados diferentes. Un centro de trabajo es dirigido por un empleado. Un mismo empleado puede dirigir centros de trabajo distintos. 3) Una empresa vende productos a varios clientes. Se necesita conocer los datos personales de los clientes (nombre, apellidos, ci, direccin y fecha de nacimiento). Cada producto tiene un nombre y un cdigo, as como un precio unitario. Un cliente puede comprar varios productos a la empresa, y un mismo producto puede ser comprado por varios clientes. Los productos son suministrados por diferentes proveedores. Se debe tener en cuenta que un producto slo puede ser suministrado por un proveedor, y que un proveedor puede suministrar diferentes productos. De cada proveedor se desea conocer el RIF, nombre y direccin. 4) Se desea informatizar la gestin de un centro de enseanza para llevar el control de los alumnos matriculados y los profesores que imparten clases en ese centro. De cada profesor y cada alumno se desea recoger el nombre, apellidos, direccin, poblacin, ci, fecha de nacimiento, cdigo postal y telfono. Los alumnos se matriculan en una o ms asignaturas, y de ellas se desea almacenar el cdigo de asignatura, nombre y nmero de horas que se imparten a la semana. Un profesor del centro puede impartir varias asignaturas, pero una asignatura slo es impartida por un nico profesor. 14

Profesores: Barriento Herminia, Bracho Damelys, Bracho Javier, Daz Wilfredo, Gutirrez Aniger, Smith Edith, Zavala Reina

Adems, se desea llevar un control de los cursos que se imparten en el centro de enseanza. De cada curso se guardar el cdigo y el nombre. En un curso se imparten varias asignaturas, y una asignatura slo puede ser impartida en un nico curso. Las asignaturas se imparten en diferentes aulas del centro. De cada aula se quiere almacenar el cdigo, piso del centro en el que se encuentra y nmero de pupitres de que dispone. Una asignatura se puede dar en diferentes aulas, y en un aula se pueden impartir varias asignaturas. Para ello se anotar el mes, da y hora en el que se imparten cada una de las asignaturas en las distintas aulas. La direccin del centro tambin designa a varios profesores como tutores en cada uno de los cursos. Un profesor es tutor tan slo de un curso. Un curso tiene un nico tutor. MODELO RELACIONAL Est basado en la teora de conjuntos y en el concepto matemtico de relacin La estructura lgica principal son tablas o relaciones. Cada relacin tiene un nmero fijo de columnas o atributos (esquema o intensin) y un nmero variable de filas. Una BD relacional est compuesta por varias tablas o relaciones REGLAS DE INTEGRIDAD Son restricciones que definen los estados de consistencia de la base de datos. Los conceptos bsicos de integridad en el modelo relacional son: Llave primaria: Es uno o un conjunto de atributos que permiten identificar a las filas de una manera nica en cualquier momento. Esta definicin determina que para un valor llave primaria slo existir una fila o registro en la tabla. Esta a situacin garantiza que no tendr informacin repetida o discordante. Llave Fornea: Es un atributo de una tabla que hace referencia a una llave primaria de otra tabla; esto origina que una relacin pueda tener varias llaves forneas. Regla de Entidad: Esta regla parte del hecho que toda tabla posee una llave primaria y establece adems que una clave primaria no puede contener un valor nulo. Regla de integridad Referencial: Involucra dos tablas e impone la restriccin que un grupo de atributos en una tabla es clave primaria en otras tablas, por lo tanto impide ingresar valores en algunos atributos de filas que no tengan su correspondencia en la tabla relacionada. Ejemplo: - Impedir facturar a un cliente que no est previamente creado en la tabla cliente - Impedir borrar de la lista de cliente un registro cuyo cdigo est incluido en la relacin de cuentas por cobrar. PASOS DEL MODELO ENTIDAD RELACIN AL MODELO RELACIONAL 1. Por cada entidad, definir una tabla cuyo nombre es el mismo que el nombre de la entidad y cuyas columnas corresponden a los atributos de la entidad. 2. La clave principal de cada tabla correspondiente clave principal de la entidad proveniente.

15

Profesores: Barriento Herminia, Bracho Damelys, Bracho Javier, Daz Wilfredo, Gutirrez Aniger, Smith Edith, Zavala Reina

3. Por cada relacin uno a muchos, agregar a la tabla del lado muchos una clave fornea, correspondiente a la clave principal de la entidad uno. 4. Por cada relacin uno a uno en la cual las claves principales de las entidades relacionadas son diferentes, agregar a la tabla correspondiente a una de las entidades una llave fornea asociada con la clave principal de la otra entidad; estableciendo la propiedad Sin Duplicados. 5. Por cada relacin muchos a muchos definir una tabla adicional (tabla de enlace, tabla de unin o tabla puente), cuyos atributos corresponden a las claves primarias de cada entidad involucrada en esa asociacin o relacin. Agregar tambin los atributos de la relacin, si existen. La clave principal de la nueva tabla es la suma de las dos claves primarias. EJEMPLO Se desea mantener informacin actualizada en una base de datos para lo cual se cuenta con la siguiente informacin: 1. Se sabe que una editorial puede publicar varios libros, teniendo la exclusividad de la publicacin. De la editorial se tiene RIF, Nombre, direccin, ciudad, nombre de la persona Contacto, nmero de Telfono, Nmero de Fax y correo 2. Por cada autor se desea conocer sus datos personales (Nombre. Apellido, CI, direccin, telefono, fecha Nac). Un autor puede escribir varios Libros, pero un libro slo est escrito por un autor. 3. Las libreras tienen muchos libros y un libro puede estar en muchas libreras. 4. Las libreras tiene un nombre nico, direccin, un encargado, nmero de telfono y nmero de Fax. 5. De cada libro se tiene Ttulo, Autor, ao de publicacin, precio, y el ISBN (Nmero de Identificacin Estndar) el cual es nico. Disear el diagrama de Entidad-Relacin (E-R) para el enunciado anterior. Solucin: 1. Realizar una lectura de la descripcin del problema. 2. Busquemos en la descripcin anterior los sustantivos presentes para identificar los objetos reales o Abstractos (Entidad)

CANDIDATOS A ENTIDAD editorial libro publicacin autor librera ventas

3. De las candidatas a entidades busquemos los atributos de cada uno EDITORIAL (RIF, Nombre, direccin, ciudad, PerContacto, nmTelf, NmFax, email) LIBRO (Ttulo, Autor, aopublic, precio, ISBN ) AUTOR ( Nombre. Apellido, CI, direccin, telefono, fecha Nac) 16

Profesores: Barriento Herminia, Bracho Damelys, Bracho Javier, Daz Wilfredo, Gutirrez Aniger, Smith Edith, Zavala Reina

LIBRERA

(nombreLibro, direc, encargado, nmtelf, nmFax )

4. Busquemos las claves principales de Cada Entidad potencial

EDITORIAL LIBRO AUTOR LIBRERA

(RIF, NomEdit, direccin, ciudad, PerContacto, nmTelf, NmFax, e-mail) (Ttulo, Autor, aopublic, precio, ISBN ) ( Nombre. Apellido, CI, direccin, telefono, fecha Nac) (nomLibrera, direc, encargado, nmtelf, nmFax )

5. Construyamos el Modelo Entidad-Relacin inicial

Direc NomLibrera

RIF Encargado

NumTelef NumFaxf

LIBRERA

tiene

Direccion Precio ISBN

PerContacto E-Mail

Ttulo

AoPublic

NomEdit

RIF

NumTelef NumFaxf

LIBRO

publica

EDITORIAL

Escrito
Telfono Nombre Apellido CI Direccin FechaNac

AUTOR

17

Profesores: Barriento Herminia, Bracho Damelys, Bracho Javier, Daz Wilfredo, Gutirrez Aniger, Smith Edith, Zavala Reina

6. Conversin del Modelo Entidad Relacin al Modelo Relacional. LIBRERA

1

NomLibrera Direc Encargado Nmtelf nmFax

LIBRERA/LIBRO NomLibrera ISBN CantLibro

EDITORIAL
1

AUTOR
1

LIBRO ISBN Ttulo Autor Aopublic Precio RIF CI CantPulicada

Nombre Apellido CI Direccin Telefono fecha Nac

RIF NomEdit Direccin Ciudad Precontacto NmTelf NmFax e-mail

NORMALIZACIN Es una tcnica para disear la estructura lgica de los datos de un sistema de informacin en el modelo relacional. Desarrollado por Edgar Codd en 1972. Es una estrategia de diseo de abajo hacia arriba, se parte de los atributos y estos se van agrupando en relaciones (Tablas) segn su afinidad. Es el proceso mediante el cual se analizan los datos y se organizan los atributos agrupndolos entre s para formar las entidades que intervienen en un sistema. Un mal diseo de la base de datos puede afectar una aplicacin, produciendo problemas con la redundancia, inexactitud, consistencia, y concurrencia de sus datos. La normalizacin es un proceso que sirve para reducir, si no eliminar, estos problemas con los datos. Para que Normalizar? Para disear base de datos sin redundancia, flexibles, adaptables y fciles de mantener. Para proteger la integridad de los datos. Permitir la recuperacin sencilla de los datos en respuesta a las solicitudes de consultas y reportes. 18

Profesores: Barriento Herminia, Bracho Damelys, Bracho Javier, Daz Wilfredo, Gutirrez Aniger, Smith Edith, Zavala Reina

Para aplicar algunos procesos de normalizacin es conveniente conocer algunos conceptos. FORMAS NORMALES. a) Primera Forma Normal. (1FN): Una relacin est en 1FN si y solo si cada uno de los atributos contiene un nico valor para una tupla determinada (valor atmico), es decir, cuando est formada por una estructura plana, en la que no existen grupos repetitivos, en la que cada dato toma un solo valor. Se alcanza cuando: Se eliminan todos los grupos repetidos, y se colocan en una tabla aparte. Se eliminan todos los campos que pueden ser generados a partir de otros ( campos calculados) Todos los atributos son atmicos, es decir, no se pueden seguir dividiendo. Se identifican las claves primarias. b) Segunda Forma Normal (2FN): Una relacin est en 2FN si y solo si est en 1FN y adems todos sus atributos que no son clave primaria tienen una dependencia funcional completa con la clave definida (asegurar que todos los atributos que no son clave sean completamente dependientes de la clave primaria) Todas las dependencias parciales son eliminadas y puestas en otra relacin. c) Tercera Forma Normal (3FN): Una relacin est en 3FN si y solo si es una relacin que est en 2FN y en la que todo atributo que no pertenece a la clave primaria no depende de un atributo que no es clave. En esta forma se eliminan cualquier dependencia transitiva, es decir, aquello en lo cual atributos que no son claves son dependientes de otros atributos que no son clave. EJEMPLO 1: EJERCICIO PLANILLA DE INCRIPCIN INGENERIA Se listan todos los campos presentes en la planilla y se escoge una clave primaria. N Planilla Clave Primaria Apellidos y Nombres C.I. NRO. Codigo1 Materia1 UCR1 Seccin1 Codigo2 Materia2 UCR2 Seccin2 Total UC Fecha 1. Aplicando la 1FN. Se elimina el campo Total UC por ser un campo calculado, se separa en cuatro campos apellidos y nombres atendiendo la premisa de que los datos deben ser atmicos. Se separan en una tabla aparte los datos repetidos, en este caso cdigo, materia, UCR, seccin, La clave primaria de esta nueva tabla est conformada, numero de

19

Profesores: Barriento Herminia, Bracho Damelys, Bracho Javier, Daz Wilfredo, Gutirrez Aniger, Smith Edith, Zavala Reina

planilla y cdigo para poder darle una identificacin nica ya que en una sola planilla de inscripcin los alumnos pueden inscribir varias materias y una misma materia puede tener varias secciones. Quedando de la siguiente manera: Alumno Materia N Planilla N Planilla Apellido1 Cdigo Apellido2 Materia Nombre1 UCR Nombre2 Seccin C.I. NRO. Fecha 2. Aplicando la 2FN, se verifica que est en Primera forma Normal (1FN) y que todos los atributos dependan funcionalmente de la Llave primaria Completa. As en la tabla alumno, verificamos que todos los campos dependen funcionalmente de la clave primaria porque para cada valor de N de planilla solo existe un valor tanto de CI, apellido1, apellido2, nombre1, nombre2 y fecha. No as con la tabla Materia cuyos atributos materia y UCR no dependen de la clave primaria completa sino solo de cdigo, por lo tanto estos deben ser separados en una tabla aparte. El atributo Seccin si depende de la llave completa ya que la misma depende tanto de la planilla que un determinado alumno realice de acuerdo a la seccin que quiera inscribir. Quedando de la siguiente manera: Alumno Materia/Planilla Materia N Planilla N Planilla Cdigo Apellido1 Cdigo Materia Apellido2 Seccin UCR Nombre1 Nombre2 C.I. NRO. Fecha 3. Aplicando la 3FN, donde verificamos que est en 2FN y donde adems verificamos si existen atributos que no son claves que son dependientes de otros atributos que tampoco son clave. Alli nos encontramos que los atributos apellido1, apellido2, nombre1 y nombre2, dependen del atributo C.I. NRO., por lo tanto estos campos se separan en una tabla aparte. Quedando el modelo de la siguiente manera: Planilla N Planilla Fecha C.I. NRO. Alumno C.I. NRO. Apellido1 Apellido2 Nombre1 Nombre2 Materia/Planilla N Planilla Cdigo Seccin Materia Cdigo Materia UCR

20

Profesores: Barriento Herminia, Bracho Damelys, Bracho Javier, Daz Wilfredo, Gutirrez Aniger, Smith Edith, Zavala Reina

EJEMPLO 2:Supongamos que, en una Base de Datos de una empresa de venta de computadoras, la informacin sobre la facturacin se encuentra almacenada de la siguiente forma:
Nro. Factura 1 1 1 2 2 Fecha 10/01/01 10/01/01 10/01/01 20/02/01 20/02/01 Cdigo cliente 10 10 10 36 03 Nombre cliente Juan Prez Juan Prez Juan Prez Julin Ail Julin Ail Cdigo de producto 25 22 01 12 99 Descripcin Mouse Teclado CPU Pad Monitor Cantidad 5 10 2 10 3 Precio unitario 10 15 650 2 200 620 Total factura

1500

A simple vista podemos observar que existen datos almacenados de forma redundante. Por qu debemos guardar por cada rengln el nmero o el nombre del cliente, si existe la posibilidad de tenerlo almacenado una sola vez? Como el descripto existe gran cantidad de inconvenientes almacenando nuestra informacin de esta manera. Apliquemos las formas normales: 1. La 1 FN dice que deben eliminarse los grupos repetitivos. Un grupo repetitivo es un dato que puede repetirse en una estructura determinada, en nuestro ejemplo para el nmero de factura. Si por cada factura almacenamos todos los artculos vendidos en la misma tabla o archivo, deberemos repetir en el archivo los datos generales de la factura tantas veces como artculos se vendan dentro de la misma. Entonces los artculos vendidos constituyen un grupo repetitivo que producen redundancia innecesaria sobre los datos que no forman parte de ese grupo repetitivo. Deberemos armar otra tabla que contenga dichos grupos y le agregaremos el campo nmero de factura (que es la clave de la primera tabla)
Nro. Factura 1 2 Ventas Cdigo cliente 10/01/01 10 20/02/01 36 Fecha ITEMS DE VENTAS Descripcin Mouse Teclado CPU Pad Monitor Nombre cliente Juan Prez Julin Ail

Nro. Factura 1 1 1 2 2

Cdigo de producto 25 22 01 12 99

Cantidad 5 10 2 10 3

Precio unitario 10 15 650 2 200

El resultado de este primer paso son dos tablas en primera forma normal (observemos que en la primera de ellas el nmero de factura aparece una sola vez). Los campos resaltados en negrita en cada una de las tablas constituyen la clave primaria de las mismas. La clave primaria es un campo o conjunto de campos (en cuyo caso constituye una clave primaria compuesta) que identifica unvocamente a cada registro. En el primer caso nos basta con el nmero de factura para identificar de forma nica a cada 21

Profesores: Barriento Herminia, Bracho Damelys, Bracho Javier, Daz Wilfredo, Gutirrez Aniger, Smith Edith, Zavala Reina

registro, pero en la segunda tabla ese nmero no alcanza ya que puede haber ms de un artculo vendido por factura (por lo que incluimos el campo cdigo de producto como parte integrante de la clave primaria). Podra haber ocurrido que dudramos acerca del campo que sera la clave primaria de una tabla. Ante una situacin de este tipo, y si tenemos ms de un campo con posibilidad de convertirse en clave primaria, como sera un cdigo de cliente o el cuit del mismo, debemos optar por uno de ellos como clave primaria, siendo denominados el o los restantes clave candidata. Notemos que dentro de la primera tabla ha sido eliminado el campo total factura. La razn por la que no se encuentra en la nueva tabla es porque el total de la factura puede obtenerse multiplicando las cantidades por los precios unitarios. El total de la factura es un campo calculado y la normalizacin nos dice que no es necesario almacenar campos calculados. La informacin de ambas tablas contina relacionada (recordemos que la normalizacin es parte del modelo Relacional de Base de Datos) a travs del campo nmero de factura. Llamaremos clave fornea a un campo de una tabla que es clave primaria en otra tabla (en este caso el campo nmero de factura de la tabla ITEMS DE VENTAS es en esa tabla clave fornea porque es clave primaria en la tabla VENTAS). Por ltimo cabe mencionar que cada tabla debe poseer un nombre, lo ms representativo de la informacin en ella almacenada. Las tablas resultantes (VENTAS e ITEMS DE VENTAS), se encuentran en 1 FN 3. Para que una tabla est en 2 FN, debe estar en 1 FN y adems todos los campos de la tabla deben depender totalmente de la clave primaria. En la tabla ITEMS DE VENTAS, la descripcin del producto: depende de toda la clave primaria (nro. de factura + cod. de producto), o solo de una parte de ella (Cod. de producto)? La respuesta es que depende de una parte de la clave primaria y no de toda la clave (depende del Cod. de producto). Entonces deberemos colocar ese campo de dependencia parcial ms el campo de cual depende en una nueva tabla. El resultado de este proceso es el siguiente:
Nro. Factura 1 2 Nro. Factura 1 1 VENTAS Cdigo Nombre cliente cliente 10/01/01 10 Juan Prez 20/02/01 36 Julin Ail ITEMS DE VENTAS Cdigo de Cantidad Precio unitario producto 25 5 10 22 10 15 Fecha

22

Profesores: Barriento Herminia, Bracho Damelys, Bracho Javier, Daz Wilfredo, Gutirrez Aniger, Smith Edith, Zavala Reina
1 2 2 Cdigo de producto 25 22 01 12 99 01 12 99 2 10 3 PRODUCTOS Descripcin Mouse Teclado CPU Pad Monitor 650 2 200

Las tablas obtenidas estn en 2 FN. La clave primaria de la tabla PRODUCTOS es sin duda el cdigo de producto. Adems, dicho campo es clave fornea en la tabla ITEMS DE VENTAS (por los motivos expuestos ms arriba acerca de las claves forneas). 3. Para que una tabla se encuentre en 3 FN, debe estar en 2 FN y no deben existir dependencias transitivas en la misma. Si miramos con detenimiento la tabla VENTAS, podremos deducir que el campo nombre del cliente no depende directamente de la clave primaria (nro. de factura), sino que depende del cdigo de cliente, por lo que existe una dependencia transitiva entre el nombre y el nmero de factura a travs del cdigo de cliente. Nuevamente deberemos colocar ese campo en otra tabla adicionndole el campo del cual depende totalmente. As obtenemos:
Nro. Factura 1 2 VENTAS Fecha 10/01/01 20/02/01 Cdigo cliente 10 36

Nro. Factura 1 1 1 2 2

ITEMS DE VENTAS Cdigo de Cantidad producto 25 5 22 10 01 2 12 10 99 3

Precio unitario 10 15 650 2 200

PRODUCTOS Cdigo de producto Descripcin 25 Mouse 22 Teclado 01 CPU 12 Pad 99 Monitor CLIENTES Cdigo cliente Nombre cliente 10 Juan Prez 36 Julin Ail

23

Profesores: Barriento Herminia, Bracho Damelys, Bracho Javier, Daz Wilfredo, Gutirrez Aniger, Smith Edith, Zavala Reina

Las tablas obtenidas estn en 3 FN. La clave primaria de la tabla CLIENTES es el cdigo de cliente. Adems, dicho campo es clave fornea en la tabla VENTAS (por ser clave primaria en la tabla CLIENTES).

24